Re: I strongly dislike Python 3

Discussion in 'Python' started by Stephen Hansen, Jun 26, 2010.

  1. On 6/26/10 10:59 AM, Stefan Reich wrote:
    >> There's no "as long as" -- its done. Python 2 is over with 2.7.

    > Well, then it is NOT done yet. And of course there is an "as long as".


    Yes, it is. 2.7 is in its release candidate phase right now. That means
    there are no more features, new development on it is complete, finished.

    There will be bugfixes only-- and for an extended period of time-- but
    that's it.

    > It really seems to me that you are an intellectually aggressive

    person that is not much worth talking to.

    Oookaaay, you're reflecting your own aggression (as shown in your
    original post) -- that entire response is entirely neutral and 'attempt
    to be helpful' tone, with maybe two tongue-in-cheek mild teases --
    mostly because your original message was so aggressive it was a tad
    off-putting.

    >> The incompatibilities with Python 3 are intentional,

    > What? For what reason? It seems that this is a pure power grabbing
    > attempt. Forcing people to decide where, with proper project management,
    > no hard decision of that kind would be necessary.


    There were various serious problems with Python 2 which could not be
    fixed in a backwards compatible way; we've been living with them for
    years and years now, and it was decided that a single break to go back
    and correct them would be preferable to keeping them forever.

    From the fact that "strings" in Python 2 ended up doing double-duty as
    both octet sequences and arrays of character text, to yes the
    syntactical bizarreness of print >>, to a number of API's not returning
    lists as copies but instead views of the internal data structures, to
    making truncating integer division an option and not a default, and then
    various fun things in addition.

    There's quite a bit of documentation out there you know.

    A few of those things would have been possible in a compatible upgrade,
    but in several places the wart had no ready way to be solved without
    breaking compatibility.

    Since there was more then one, they decided to go in and do them all at
    once as a one-time breakage. Even considering that, they were really
    conservative and rejected many things as gratuitous breakage. It had to
    simplify the language, clean up its expressiveness, and provide some
    solid utility to qualify.

    I can't quite figure out what you define as a "power grab" -- you're
    free to continue using Python 2 forever if you'd like. If you would like
    to take advantage of the new features and capabilities, the cleaner and
    better designed language of Python 3, then you'll switch eventually.

    >> Not that Python 2.7 will then die completely, I'm sure.

    > Oh, so you are once again contradicting your earlier statement that "it
    > is done". Seems to me you are trying to kill Python 2 a bit too fast.


    No, "I'm" not trying to kill Python 2 at all. My current estimation is
    that I'll be using it for at least the next three years -- library
    conversion momentum is there, but its happening faster in the pure
    Python libraries then a few critical C extensions I rely upon.

    But I am not contradicting anything: it *is* done. Finished. No further
    development will be done on it. There will be an extended period of
    support (I think I heard something like twice the normal period of 2(1?)
    years? I don't know for sure, though) where bug fix releases will be
    made. But that's it.

    "Done" is not the same thing as "dead".

    Done means finished: complete, not going to be advanced any further.

    "Dead", in this context, means that no one actually uses it for anything
    even remotely serious. At least that's what it means when I said 'dead'
    above.

    >> The pydev's have even stated it'll have a longer then usual bugfix
    >> maintenance period, recognizing some people will be on the Python 2
    >> platform for years still.

    > Hear hear! So we do exist, and we're not going away so quickly either.


    Yes, and?

    As I said, it is acknowledged that it will be a long migration and they
    are supporting that migration with tools, syntax, forwards-compatibility
    features (such as from __future__ import print_function and such like)
    and an extended bugfix cycle.

    And I'm sure that some people will never migrate. I rather suspect that
    will be a minority, though. Either way, what's your point?

    Also, I find it *really* amusing you call *me* the aggressive one. Okay,
    sure man. The entire previ


    >> P.S. Am I the only one who has never, ever, even *seen* a 'print'
    >> statement in non-toy or non-bash-script-style code in any application
    >> or even third-party library I looked at? Except, on occasion, for
    >> quick and dirty debugging. Perhaps because I'm more used to
    >> cross-platform to windows development, where a stray print can
    >> actually break the entire application (depending on contexts, if one
    >> is run under a service or sometimes even pythonw)

    > God man, you need to stop bashing a perfectly good statement in an
    > attempt to make you look like a "smart programmer" who "doesn't use
    > print" in his "serious applications".


    The question, though an afterthought, was serious.

    I never use print except in quick and dirty debugging, and using it
    often bites me on the ass: as I said it can lead to programs completely
    crashing out if you leave a stray one in certain areas of development.

    In the third-party libraries I use, and I use quite a lot of them (thank
    you, community), I periodically scan around inside just for curiosity
    sake, and sometimes to tweak something. I don't ever see prints that
    aren't commented out: invariably, someone either has rolled their own
    little private logging framework, uses Python's logging framework, or
    ends up writing to some file-like object which gets passed in or around.

    I *really* don't ever use print. Not because its some damn, horrible
    thing, and all you print-users are imbeciles who need to grow up and do
    some *real* programming (alert: this is one of those tongue-in-cheek
    comments filled with some sarcasm), but because I find it basically
    almost never suitable to any sort of task I want to do when outputting.

    As Thomas put it:

    On 6/26/10 9:33 AM, Thomas Jollans wrote:
    > Also, do you use print *that* much? Really?


    It was genuine surprise. Oh, I know people do use print, and I know
    there's bound to be someone who finds the conversion a bit complicated
    (though 2to3 does it well). But the level of wrath you're showing over
    this particular change implied a level of usage which just seemed strange.

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
     
    Stephen Hansen, Jun 26, 2010
    #1
    1. Advertising

  2. Stephen Hansen

    John Bokma Guest

    Stephen Hansen <me+list/> writes:

    > No, "I'm" not trying to kill Python 2 at all. My current estimation is
    > that I'll be using it for at least the next three years -- library
    > conversion momentum is there, but its happening faster in the pure
    > Python libraries then a few critical C extensions I rely upon.


    Based on my experience with Perl usage [1] I guess that Python 2 will be not
    dead for 5 - 10 years.

    > Done means finished: complete, not going to be advanced any further.


    I think that's not true. If enough people want to support Python 2 it
    might be possible to advance Python 2.

    Personally I think it's good to clean up the closet now and then. But
    probably has also to do with me being "new" to the language and not
    having to port 101 Python programs to 3 :-D.

    [1] I know several people who're still on Perl 5.0xxx (!)

    --
    John Bokma j3b

    Hacking & Hiking in Mexico - http://johnbokma.com/
    http://castleamber.com/ - Perl & Python Development
     
    John Bokma, Jun 26, 2010
    #2
    1. Advertising

  3. Stephen Hansen schreef op de 26e dag van de zomermaand van het jaar 2010:

    > There were various serious problems with Python 2 which could not be fixed in
    > a backwards compatible way; we've been living with them for years and years
    > now, and it was decided that a single break to go back and correct them would
    > be preferable to keeping them forever.
    >
    > From the fact that "strings" in Python 2 ended up doing double-duty as both
    > octet sequences and arrays of character text, to yes the syntactical


    I have been using Python 3 for quite some time now, and this
    string thing in Python 3 has caused me more headaches than it
    ever did in Python 2. Though it seems nice in theory to know
    exactly what type of bytes or string you have, you're working
    with a standard library that often doesn't know how to handle
    this distinction. The e-mail module is broken, as well as the
    cgi module. When I read a file from a zip archive, I can't open
    it as a binary stream, but I get binary anyway. I can't call
    os.system with a binary string, only with a text string, and
    that's encoded into utf-8, no matter what encoding I need.

    Some basic text string functions seem to be working on byte
    string functions as well, but sometimes they don't, and there's
    no rhyme in why it does or doesn't.

    >>> 'abcd'[0] == 'abcd'[:1]

    True
    >>> b'abcd'[0] == b'abcd'[:1]

    False

    Why????

    In the end it may be all better, but at the moment, still a lot
    of work has to be done to fix the standard library. And then
    there's all those packages out there, that have to be ported...
    I still can't use numpy in Python 3.


    --
    Peter Kleiweg L:NL,af,da,de,en,ia,nds,no,sv,(fr,it) S:NL,de,en,(da,ia)
    info: http://www.let.rug.nl/kleiweg/ls.html
     
    Peter Kleiweg, Jun 26, 2010
    #3
  4. On 6/26/10 11:41 AM, John Bokma wrote:
    > Stephen Hansen<me+list/> writes:
    >
    >> No, "I'm" not trying to kill Python 2 at all. My current estimation is
    >> that I'll be using it for at least the next three years -- library
    >> conversion momentum is there, but its happening faster in the pure
    >> Python libraries then a few critical C extensions I rely upon.

    >
    > Based on my experience with Perl usage [1] I guess that Python 2 will be not
    > dead for 5 - 10 years.


    I wouldn't expect it to be dead for a long time, either. There's too
    much written in it, in broad areas of usage-- and if something just
    works people may not be inclined to change. But then again, I know of
    more then one area where people are using Python 1.5.2, and even more
    who haven't moved past 2.3 and don't plan to anytime soon.

    There's always going to be people left behind; the 2->3 transition just
    might leave a bigger clump. But I still do suspect most will make that
    transition if they're in an area that's under active development and not
    just maintenance.

    >> Done means finished: complete, not going to be advanced any further.

    >
    > I think that's not true. If enough people want to support Python 2 it
    > might be possible to advance Python 2.


    I stand by the statement-- but do acknowledge that its possible for it
    to be revived in the future, if enough people end up wanting to. Be it
    by a fork, or if python-dev changes their mind.

    But as it stands, 2.7 is end-of-line for the 2.x series. I think calling
    it "done" is pretty accurate :)

    But I again want to make a point, I'm saying done, not dead. Python 2 is
    alive and vibrant, and I quite look forward to upgrading to 2.7 where I
    can (sadly, in many places I'm stuck on 2.4). The community around
    Python 2 remains active and interested, even as more and more start
    diverting attention to Python 3 compatibility / porting... Python 2
    isn't being abandoned by anyone yet.

    But that doesn't mean its going to *go* anywhere from here. This is all
    I was trying to say with 'done'.

    > Personally I think it's good to clean up the closet now and then. But
    > probably has also to do with me being "new" to the language and not
    > having to port 101 Python programs to 3 :-D.


    I'm hoping this is just a one-time thing; that we'll never see a Py4k
    event. But, I'm also happy this was evolutionary and not a major rewrite
    -- it feels to me like breaking a bone to set it It hurts now, but
    everything will grow better after.

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
     
    Stephen Hansen, Jun 26, 2010
    #4
  5. >> No, "I'm" not trying to kill Python 2 at all. My current estimation is
    >> that I'll be using it for at least the next three years -- library
    >> conversion momentum is there, but its happening faster in the pure
    >> Python libraries then a few critical C extensions I rely upon.

    >
    > Based on my experience with Perl usage [1] I guess that Python 2 will be not
    > dead for 5 - 10 years.


    Certainly so. The three year estimation of Stephen was for his own
    personal usage. Python 2.7 will only fade out of existence once it
    fails to build and install on then-current operating systems.

    >
    >> Done means finished: complete, not going to be advanced any further.

    >
    > I think that's not true. If enough people want to support Python 2 it
    > might be possible to advance Python 2.


    That won't be sufficient: enough people wanting support won't have any
    effect. People also need to want it enough to actually fork from
    python.org. They would then have to convince Linux packagers to include
    it in the distribution even though it's not available from python.org,
    and convince Windows users to download it from some other place than
    python.org. I think people will find that this isn't really worth the
    trouble.

    Regards,
    Martin
     
    Martin v. Loewis, Jun 26, 2010
    #5
  6. On 6/26/10 11:55 AM, Peter Kleiweg wrote:

    > I have been using Python 3 for quite some time now, and this

    [snip]

    I'm not advocating using Python 3 or that it doesn't have plenty of work
    to do still. I don't use it yet, so can't really comment on any of your
    issues except to ask: Have you opened bug reports?

    If not, well...

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
     
    Stephen Hansen, Jun 26, 2010
    #6
  7. Stephen Hansen schreef op de 26e dag van de zomermaand van het jaar 2010:

    > On 6/26/10 11:55 AM, Peter Kleiweg wrote:
    >
    > > I have been using Python 3 for quite some time now, and this

    > [snip]
    >
    > I'm not advocating using Python 3 or that it doesn't have plenty of work to do
    > still. I don't use it yet, so can't really comment on any of your issues
    > except to ask: Have you opened bug reports?


    Yes.





    --
    Peter Kleiweg L:NL,af,da,de,en,ia,nds,no,sv,(fr,it) S:NL,de,en,(da,ia)
    info: http://www.let.rug.nl/kleiweg/ls.html
     
    Peter Kleiweg, Jun 26, 2010
    #7
  8. Stephen Hansen

    Chris Rebert Guest

    On Sat, Jun 26, 2010 at 11:55 AM, Peter Kleiweg <> wrote:
    > Stephen Hansen schreef op de 26e dag van de zomermaand van het jaar 2010:
    >> There were various serious problems with Python 2 which could not be fixed in
    >> a backwards compatible way; we've been living with them for years and years
    >> now, and it was decided that a single break to go back and correct them would
    >> be preferable to keeping them forever.
    >>
    >> From the fact that "strings" in Python 2 ended up doing double-duty as both
    >> octet sequences and arrays of character text, to yes the syntactical

    >
    > I have been using Python 3 for quite some time now, and this
    > string thing in Python 3 has caused me more headaches than it
    > ever did in Python 2.

    <snip>
    > Some basic text string functions seem to be working on byte
    > string functions as well, but sometimes they don't, and there's
    > no rhyme in why it does or doesn't.
    >
    >    >>> 'abcd'[0] == 'abcd'[:1]
    >    True
    >    >>> b'abcd'[0] == b'abcd'[:1]
    >    False
    >
    > Why????


    In the bytes example, the former expression gives an integer
    corresponding the the value of the first byte, while the latter gives
    a bytes object of length 1 (this reminds me of Ruby now that I think
    about it).
    The slicing behavior of bytes takes some getting used to, but there
    aren't many good alternatives. Using chr() and ord() on bytes would
    feel a bit weird, no?

    Cheers,
    Chris
    --
    http://blog.rebertia.com
     
    Chris Rebert, Jun 26, 2010
    #8
  9. Stephen Hansen

    Terry Reedy Guest

    On 6/26/2010 2:55 PM, Peter Kleiweg wrote:

    PSF is funding work on the email module. Problems with cgi and other
    internet interfacing modules are the main topic of discussion on py-dev
    this week.

    > Some basic text string functions seem to be working on byte
    > string functions as well, but sometimes they don't, and there's
    > no rhyme in why it does or doesn't.
    >
    > >>> 'abcd'[0] == 'abcd'[:1]

    > True
    > >>> b'abcd'[0] == b'abcd'[:1]

    > False
    >
    > Why????


    The bytes behavior is the normal behavior for sequences. Indexing
    produces an element of the sequence (in this case an int) while slicing
    produce a subseqeunce of the sequence, which is different from an
    element of the sequence. Try the same with tuples, lists, and ranges.

    Strings are anomalous in that indexing produces a subsequence instead of
    an element (char in this case, which Guido chose for Python not to have).
    --
    Terry Jan Reedy
     
    Terry Reedy, Jun 27, 2010
    #9
  10. On Sat, 26 Jun 2010 13:41:30 -0500, John Bokma wrote:

    >> Done means finished: complete, not going to be advanced any further.

    >
    > I think that's not true. If enough people want to support Python 2 it
    > might be possible to advance Python 2.


    I can't see that happening. In my experience those who are the most
    vehemently against Python 3 are the least likely to do anything about it
    apart from bad-mouthing it. The chances of them actually taking on
    responsibility for maintaining Python 2.7 is somewhere between slim and
    none.



    --
    Steven
     
    Steven D'Aprano, Jun 27, 2010
    #10
  11. Stephen Hansen

    Nobody Guest

    On Sat, 26 Jun 2010 21:08:48 +0200, Martin v. Loewis wrote:

    >> I think that's not true. If enough people want to support Python 2 it
    >> might be possible to advance Python 2.

    >
    > That won't be sufficient: enough people wanting support won't have any
    > effect. People also need to want it enough to actually fork from
    > python.org.


    This will happen.

    > They would then have to convince Linux packagers to include
    > it in the distribution even though it's not available from python.org,


    So will this.

    > and convince Windows users to download it from some other place than
    > python.org.


    I don't know about this one. Windows uses Unicode natively, so Python3
    isn't so problematic there.

    > I think people will find that this isn't really worth the
    > trouble.


    I disagree.

    The Unix API uses byte strings, with no associated encoding; always has,
    always will. For people who use Python as an alternative to bash or Perl,
    maintaining a fork of Python 2 is going to be less trouble than using
    Python 3.
     
    Nobody, Jun 27, 2010
    #11
  12. Stephen Hansen

    Aahz Guest

    In article <>,
    Terry Reedy <> wrote:
    >On 6/26/2010 2:55 PM, Peter Kleiweg wrote:
    >>
    >> Some basic text string functions seem to be working on byte
    >> string functions as well, but sometimes they don't, and there's
    >> no rhyme in why it does or doesn't.
    >>
    >> >>> 'abcd'[0] == 'abcd'[:1]

    >> True
    >> >>> b'abcd'[0] == b'abcd'[:1]

    >> False
    >>
    >> Why????

    >
    >The bytes behavior is the normal behavior for sequences. Indexing
    >produces an element of the sequence (in this case an int) while slicing
    >produce a subseqeunce of the sequence, which is different from an
    >element of the sequence. Try the same with tuples, lists, and ranges.
    >
    >Strings are anomalous in that indexing produces a subsequence instead of
    >an element (char in this case, which Guido chose for Python not to have).


    Quoting myself from some time back:

    "...string iteration isn't about treating strings as sequences of strings,
    it's about treating strings as sequences of characters. The fact that
    characters are also strings is the reason we have problems, but characters
    are strings for other good reasons." --Aahz
    http://mail.python.org/pipermail/python-3000/2006-April/000897.html
    --
    Aahz () <*> http://www.pythoncraft.com/

    "If you don't know what your program is supposed to do, you'd better not
    start writing it." --Dijkstra
     
    Aahz, Jun 27, 2010
    #12
  13. On Sun, 27 Jun 2010 02:45:37 +0100 Nobody <> wrote:

    > On Sat, 26 Jun 2010 21:08:48 +0200, Martin v. Loewis wrote:
    >
    > >> I think that's not true. If enough people want to support Python 2
    > >> it might be possible to advance Python 2.

    > >
    > > That won't be sufficient: enough people wanting support won't have
    > > any effect. People also need to want it enough to actually fork from
    > > python.org.

    >
    > This will happen.
    >
    > > They would then have to convince Linux packagers to include
    > > it in the distribution even though it's not available from
    > > python.org,

    >
    > So will this.
    >
    > [snip]
    >

    So your crystal ball is working, eh?

    Good for you, mine was a scam.

    ;)
    /W


    --
    INVALID? DE!
     
    Andreas Waldenburger, Jun 27, 2010
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Reich

    I strongly dislike Python 3

    Stefan Reich, Jun 26, 2010, in forum: Python
    Replies:
    1
    Views:
    303
    Lawrence D'Oliveiro
    Jun 27, 2010
  2. Thomas Jollans

    Re: I strongly dislike Python 3

    Thomas Jollans, Jun 26, 2010, in forum: Python
    Replies:
    52
    Views:
    1,512
    Chris Rebert
    Jul 2, 2010
  3. Stefan Reich

    Re: I strongly dislike Python 3

    Stefan Reich, Jun 26, 2010, in forum: Python
    Replies:
    5
    Views:
    390
    Stephen Hansen
    Jun 27, 2010
  4. Terry Reedy

    Re: I strongly dislike Python 3

    Terry Reedy, Jun 27, 2010, in forum: Python
    Replies:
    43
    Views:
    1,175
  5. John Nagle
    Replies:
    79
    Views:
    1,933
    Philip Semanchuk
    Jul 8, 2010
Loading...

Share This Page