Re: I strongly dislike Python 3

Discussion in 'Python' started by Terry Reedy, Jun 27, 2010.

  1. Terry Reedy

    Terry Reedy Guest

    On 6/26/2010 11:59 AM, Stefan Reich wrote:

    > I don't like Python 3.


    I love it.

    > My complaint is about changing the syntax of "print".


    Having completely switched from 'printf(' to 'print ', I have had a bit
    of a problem switching back to 'print('. It is my single largest source
    of typos. But a decent system that puts me at the site of syntax errors
    alleviates this. Logic bugs are a much bigger problem.

    Nonetheless, I support the switch. Not just for the symmetry with
    input(), but because it properly is a function. And I really prefer
    print('xyz', file=myfile), which I do use, to the ugly >>myfile hack.

    [snip]
    > To reiterate, I am strongly in disfavor of Python 3 and will stick to
    > Python 2, for as least as long as Python 3 breaks my scripts.


    Although I an not using 2.x currently, I am one of the people who
    suggested and supported the idea of fixing bugs for 2.7 for several
    years. I hope it someday becomes a polished jewel with essentially no
    bugs. I expect it to be used a long time.

    On the other hand, I strongly feel Python3 is better for student just
    learning to program who do not need 2.x libraries.

    --
    Terry Jan Reedy
     
    Terry Reedy, Jun 27, 2010
    #1
    1. Advertising

  2. Terry Reedy

    Paul Rubin Guest

    Terry Reedy <> writes:
    > Having completely switched from 'printf(' to 'print ', I have had a
    > bit of a problem switching back to 'print('. It is my single largest
    > source of typos. But a decent system that puts me at the site of
    > syntax errors alleviates this. Logic bugs are a much bigger problem.


    I tend to print a lot of tracing messages in my programs, in the form

    print (x, y, z)

    expecting to print the tuple (x,y,z) in a form that I can read back
    into an analysis program. That's going to break without throwing
    any syntax errors if I ever switch to Python 3.
     
    Paul Rubin, Jun 27, 2010
    #2
    1. Advertising

  3. Terry Reedy

    Terry Reedy Guest

    On 6/26/2010 8:02 PM, Paul Rubin wrote:
    > Terry Reedy<> writes:
    >> Having completely switched from 'printf(' to 'print ', I have had a
    >> bit of a problem switching back to 'print('. It is my single largest
    >> source of typos. But a decent system that puts me at the site of
    >> syntax errors alleviates this. Logic bugs are a much bigger problem.

    >
    > I tend to print a lot of tracing messages in my programs, in the form
    >
    > print (x, y, z)
    >
    > expecting to print the tuple (x,y,z) in a form that I can read back
    > into an analysis program. That's going to break without throwing
    > any syntax errors if I ever switch to Python 3.


    I would hope and expect that 2to3 will properly add a second pair. But I
    can see that that would be a problem with new code. To make your life
    easier, and even save keystrokes:

    >>> print((1,2,3))

    (1, 2, 3)
    >>> def tp(*args): print(args) # tuple print


    >>> tp(1,2,3)

    (1, 2, 3)

    --
    Terry Jan Reedy
     
    Terry Reedy, Jun 27, 2010
    #3
  4. Terry Reedy

    Paul Rubin Guest

    Terry Reedy <> writes:
    > To make your life easier, and even save keystrokes:..
    >>>> def tp(*args): print(args) # tuple print


    Too much to remember, makes my life harder. If I were that organized,
    I'd figure out how to use the logging module. ;)
     
    Paul Rubin, Jun 27, 2010
    #4
  5. On Sat, 26 Jun 2010 17:02:32 -0700, Paul Rubin wrote:

    > Terry Reedy <> writes:
    >> Having completely switched from 'printf(' to 'print ', I have had a bit
    >> of a problem switching back to 'print('. It is my single largest source
    >> of typos. But a decent system that puts me at the site of syntax errors
    >> alleviates this. Logic bugs are a much bigger problem.

    >
    > I tend to print a lot of tracing messages in my programs, in the form
    >
    > print (x, y, z)
    >
    > expecting to print the tuple (x,y,z) in a form that I can read back into
    > an analysis program. That's going to break without throwing any syntax
    > errors if I ever switch to Python 3.


    Apart from retraining yourself to add the extra parentheses, the easy fix
    is to put this at the top of your module:


    _pr = print
    def print(*args, **kwargs):
    _pr(args, **kwargs)


    But I'm sure you know this :)


    I didn't notice this level of angst when Python made equally significant
    changes going from 1.5 to 2.0... admittedly Python 1.5 code would work
    unchanged in 2.0, but the 2.x series introduced MUCH bigger additions to
    Python than anything 3.0 and 3.1 have added, and anyone taking advantage
    of those changes is implicitly writing code which is not backwards
    compatible.

    To all the Python 3.x haters -- spend a few minutes installing Python 1.5
    and playing around with it and see how much it is missing: no integrated
    help, no unicode, no __futures__, no generators, no iterators apart from
    xrange and xreadlines, no properties... See how long you last before you
    (metaphorically) throw it across the room in disgust. That's what you'll
    be like for Python 2.x in a decade. I realise it's hard to see that now,
    when so many major libraries haven't been ported yet and the unicode vs.
    bytes situation is still unclean, but 3.x is the future of Python, and a
    good thing it is too.



    --
    Steven
     
    Steven D'Aprano, Jun 27, 2010
    #5
  6. On Sun, 27 Jun 2010 01:06:12 +0000, Steven D'Aprano wrote:

    > On Sat, 26 Jun 2010 17:02:32 -0700, Paul Rubin wrote:

    [...]
    > To all the Python 3.x haters


    Hmmm, I just realised that it might seem that this was aimed at Paul
    directly. I'm sorry, I wasn't intending to imply that he's a Python 3
    hater, or that anyone who mentions even the tiniest little disagreement
    or difficulty with Python 3 is a hater. That wasn't my intention, and I'm
    sorry if I gave it to anyone.

    Of course there will be difficulties during the transition period, which
    is why Python 2.7 will get a longer-than-normal release cycle. If people
    don't publicly say what those difficulties are, they won't be fixed.
    Sometimes the fix is just "hang in there, you'll learn the new ways of
    doing things", and sometimes they will require new code in Python itself.



    --
    Steven
     
    Steven D'Aprano, Jun 27, 2010
    #6
  7. > I didn't notice this level of angst when Python made equally significant
    > changes going from 1.5 to 2.0...


    I think the *level* was about the same (IIRC). People would say that
    they ignore 2.x for years, and that it is important to continue
    supporting 1.5.2 for a long time (about until 2.4 was released).

    What's different now is the *amount* of angst. That's not surprising:
    there is a much larger user community now with investment into Python
    2.x, and they are concerned, and worried about the work that they have
    to perform.

    In addition to your observations: what the 3.x haters fail to recognize
    is that the porting effort is actually much smaller than they think it
    is. Would they try it out, they'd notice that it didn't take so long,
    after all. Of course, porting from 2.x to 3.x is a skill to acquire,
    so it gets easier the more you memorize the differences and pitfalls.

    Regards,
    Martin
     
    Martin v. Loewis, Jun 27, 2010
    #7
  8. On Sun, Jun 27, 2010 at 4:54 PM, Martin v. Loewis <> wrote:
    >> I didn't notice this level of angst when Python made equally significant
    >> changes going from 1.5 to 2.0...

    >
    > I think the *level* was about the same (IIRC). People would say that
    > they ignore 2.x for years, and that it is important to continue
    > supporting 1.5.2 for a long time (about until 2.4 was released).
    >
    > What's different now is the *amount* of angst. That's not surprising:
    > there is a much larger user community now with investment into Python
    > 2.x, and they are concerned, and worried about the work that they have
    > to perform.
    >
    > In addition to your observations: what the 3.x haters fail to recognize
    > is that the porting effort is actually much smaller than they think it
    > is.


    I think one point which needs to be emphasized more is what does
    python 3 bring to people. The" what's new in python 3 page" gives the
    impression that python 3 is about removing cruft. That's a very poor
    argument to push people to switch.

    I doubt "porting is easier than you think" will convince many people
    if they don't know what the gain will be. For example, porting numpy
    and scipy to py3k has been easier than I thought, but besides making
    it easier for other people to switch, I can't see *any* benefit.
    That's bound to frustrate people.


    David
     
    David Cournapeau, Jun 27, 2010
    #8
  9. Terry Reedy

    Malte Dik Guest

    quote:
    >
    > I didn't notice this level of angst when Python made equally significant
    > changes going from 1.5 to 2.0... admittedly Python 1.5 code would work
    > unchanged in 2.0, but the 2.x series introduced MUCH bigger additions to
    > Python than anything 3.0 and 3.1 have added, and anyone taking advantage
    > of those changes is implicitly writing code which is not backwards
    > compatible.


    Maybe the print statement is like the wart of Python. It maybe ugly, but it
    adds character. Could you imagine Lemmy lasered his?

    Of course people are angsty that *their* Python might not be the same!


    But I can relieve those who are: The interactive command line shell IPython
    delivers an autocompletion where parenthesis for _any_ function may be left
    out. Now, how does that sound? Ruby anyone? ;)


    Sincerely,

    Malte
     
    Malte Dik, Jun 27, 2010
    #9
  10. David Cournapeau schreef op de 27e dag van de zomermaand van het jaar 2010:

    > I doubt "porting is easier than you think" will convince many people
    > if they don't know what the gain will be. For example, porting numpy
    > and scipy to py3k has been easier than I thought, but besides making
    > it easier for other people to switch, I can't see *any* benefit.
    > That's bound to frustrate people.


    The latest NumPy is 1.4.1, and it does not install with Python 3.1.1

    --
    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 27, 2010
    #10
  11. On Sun, Jun 27, 2010 at 11:46 PM, Peter Kleiweg <> wrote:
    > David Cournapeau schreef op de 27e dag van de zomermaand van het jaar 2010:
    >
    >> I doubt "porting is easier than you think" will convince many people
    >> if they don't know what the gain will be. For example, porting numpy
    >> and scipy to py3k has been easier than I thought, but besides making
    >> it easier for other people to switch, I can't see *any* benefit.
    >> That's bound to frustrate people.

    >
    > The latest NumPy is 1.4.1, and it does not install with Python 3.1.1


    The 3.x support for numpy is in the trunk

    David
     
    David Cournapeau, Jun 27, 2010
    #11
  12. Terry Reedy

    Terry Reedy Guest

    On 6/27/2010 8:41 AM, David Cournapeau wrote:

    > I think one point which needs to be emphasized more is what does
    > python 3 bring to people. The" what's new in python 3 page" gives the
    > impression that python 3 is about removing cruft. That's a very poor
    > argument to push people to switch.


    Python3 is about finishing transitions. The last stage in a transition
    that replaces something old with something new is to remove the old,
    after showing that the new works. I am working on a separate post for
    this.) I presume most readers here who are not packrats have at some
    time discarded a working machine (perhaps reluctantly) after installing
    and testing a new one.

    For new learners, not having to also learn the old is a real benefit.
    People who already know the old typically do not see that.

    > I doubt "porting is easier than you think" will convince many people
    > if they don't know what the gain will be. For example, porting numpy
    > and scipy to py3k has been easier than I thought, but besides making
    > it easier for other people to switch, I can't see *any* benefit.


    I thank you and your group for porting numpy and scipy for the benefit
    of those who switch and for new Pythonistas that start with Python3. I
    hope and expect that they will eventually outnumber Python2 programmers.

    I agree that there may be not much reason to port custom proprietary
    apps that are working fine and which would hardly benefit from, let
    alone need, and new Py3 features.
    --
    Terry Jan Reedy
     
    Terry Reedy, Jun 27, 2010
    #12
  13. > I agree that there may be not much reason to port custom proprietary
    > apps that are working fine and which would hardly benefit from, let
    > alone need, and new Py3 features.


    In the long run, there will be a benefit: at some point in the future
    (surely years from now), /usr/bin/python will be Python 3. So scripts
    that use /usr/bin/python (or "/usr/bin/env python") will stop working.
    As a quick fix, it might then be possible to have them run with
    /usr/bin/python2. Some time more into the future, this will also stop
    working, as Python 2.x won't be available anymore in the OS
    distributions. If the custom proprietary app is then still used, it
    better be ported.

    The same happened with other kinds of deprecations and removals through
    the life of 2.x. Some applications where tied to a specific Python
    release, or to a specific feature that had been deprecated. These either
    needed to be ported, or dropped.

    Regards,
    Martin
     
    Martin v. Loewis, Jun 27, 2010
    #13
  14. Terry Reedy

    Guest

    On Jun 27, 2:09 pm, "Martin v. Loewis" <> wrote:
    > > I agree that there may be not much reason to port custom proprietary
    > > apps that are working fine and which would hardly benefit from, let
    > > alone need, and new Py3 features.

    >
    > In the long run, there will be a benefit: at some point in the future
    > (surely years from now), /usr/bin/python will be Python 3. So scripts
    > that use /usr/bin/python (or "/usr/bin/env python") will stop working.
    > As a quick fix, it might then be possible to have them run with
    > /usr/bin/python2. Some time more into the future, this will also stop
    > working, as Python 2.x won't be available anymore in the OS
    > distributions. If the custom proprietary app is then still used, it
    > better be ported.
    >
    > The same happened with other kinds of deprecations and removals through
    > the life of 2.x. Some applications where tied to a specific Python
    > release, or to a specific feature that had been deprecated. These either
    > needed to be ported, or dropped.
    >
    > Regards,
    > Martin


    It should be easier to have a large number of python versions on one
    machine... I am realy fond of 2.5 so I am probily going to start
    compiling them or just include the python2.5 exe if I port stuff and
    settle it that way..
     
    , Jun 28, 2010
    #14
  15. On Sun, Jun 27, 2010 at 4:03 PM,
    <> wrote:
    > On Jun 27, 2:09 pm, "Martin v. Loewis" <> wrote:
    >> > I agree that there may be not much reason to port custom proprietary
    >> > apps that are working fine and which would hardly benefit from, let
    >> > alone need, and new Py3 features.

    >>
    >> In the long run, there will be a benefit: at some point in the future
    >> (surely years from now), /usr/bin/python will be Python 3. So scripts
    >> that use /usr/bin/python (or "/usr/bin/env python") will stop working.
    >> As a quick fix, it might then be possible to have them run with
    >> /usr/bin/python2. Some time more into the future, this will also stop
    >> working, as Python 2.x won't be available anymore in the OS
    >> distributions. If the custom proprietary app is then still used, it
    >> better be ported.
    >>
    >> The same happened with other kinds of deprecations and removals through
    >> the life of 2.x. Some applications where tied to a specific Python
    >> release, or to a specific feature that had been deprecated. These either
    >> needed to be ported, or dropped.
    >>
    >> Regards,
    >> Martin

    >
    > It should be easier to have a large number of python versions on one
    > machine...  I am realy fond of 2.5 so I am probily going to start
    > compiling them or just include the python2.5 exe if I port stuff and
    > settle it that way..
    > --


    You're on the only platform where it isn't that easy. All us *nix
    users have to do is compile it with the altinstall flag, and then use
    #!/usr/bin/env python25
    Windows uses the file extension instead of the shebang line to execute
    stuff, so it's harder for you to have multiple versions.
     
    Benjamin Kaplan, Jun 28, 2010
    #15
  16. On 6/27/10 4:03 PM, wrote:
    > On Jun 27, 2:09 pm, "Martin v. Loewis"<> wrote:
    >> The same happened with other kinds of deprecations and removals through
    >> the life of 2.x. Some applications where tied to a specific Python
    >> release, or to a specific feature that had been deprecated. These either
    >> needed to be ported, or dropped.
    >>
    >> Regards,
    >> Martin

    >
    > It should be easier to have a large number of python versions on one
    > machine... I am realy fond of 2.5 so I am probily going to start
    > compiling them or just include the python2.5 exe if I port stuff and
    > settle it that way..


    Why do you think you'll need to compile anything?

    I can't speak for the the people who run python.org, but considering you
    can still get 1.5.2 in binary form for windows, I don't see why they'd
    ever stop offering Python 2.5.

    Just because new development for the 2.x series is coming to a halt,
    doesn't mean anyone's forcing everyone to start using 2.6, 2.7, or 3.x,
    or that suddenly Python.org is going to stop offering downloads for it.
    There's just no reason for them to bother as long as there's any sort of
    interest. I mean, ten years from now maybe if no one ever downloads 2.5
    -- but as it is, its 11 years since 1.5.2 was released and no one seems
    inclined to remove it. :)

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
     
    Stephen Hansen, Jun 28, 2010
    #16
  17. On 2010-06-27, Benjamin Kaplan <> wrote:

    >> It should be easier to have a large number of python versions on one
    >> machine... ?I am realy fond of 2.5 so I am probily going to start
    >> compiling them or just include the python2.5 exe if I port stuff and
    >> settle it that way..

    >
    > You're on the only platform where it isn't that easy. All us *nix
    > users have to do is compile it with the altinstall flag, and then use
    > #!/usr/bin/env python25
    > Windows uses the file extension instead of the shebang line to execute
    > stuff, so it's harder for you to have multiple versions.


    If you install a real shell on Windows, then the hash-bang line works
    fine. :)

    --
    Grant
     
    Grant Edwards, Jun 28, 2010
    #17
  18. On Sun, Jun 27, 2010 at 8:50 PM, Grant Edwards <> wrote:
    > On 2010-06-27, Benjamin Kaplan <> wrote:
    >
    >>> It should be easier to have a large number of python versions on one
    >>> machine... ?I am realy fond of 2.5 so I am probily going to start
    >>> compiling them or just include the python2.5 exe if I port stuff and
    >>> settle it that way..

    >>
    >> You're on the only platform where it isn't that easy. All us *nix
    >> users have to do is compile it with the altinstall flag, and then use
    >> #!/usr/bin/env python25
    >> Windows uses the file extension instead of the shebang line to execute
    >> stuff, so it's harder for you to have multiple versions.

    >
    > If you install a real shell on Windows, then the hash-bang line works
    > fine. :)


    Might as well spare yourself the trouble and install linux or *bsd. It's
    probably easier.

    Geremy Condra
     
    geremy condra, Jun 28, 2010
    #18
  19. On 6/27/10 6:11 PM, geremy condra wrote:
    > On Sun, Jun 27, 2010 at 8:50 PM, Grant Edwards<> wrote:
    >> If you install a real shell on Windows, then the hash-bang line works
    >> fine. :)

    >
    > Might as well spare yourself the trouble and install linux or *bsd. It's
    > probably easier.


    Not at all, bash via msys is trivial to install and use.

    --

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/
     
    Stephen Hansen, Jun 28, 2010
    #19
  20. Terry Reedy

    John Bokma Guest

    geremy condra <> writes:

    > On Sun, Jun 27, 2010 at 8:50 PM, Grant Edwards <> wrote:
    >> On 2010-06-27, Benjamin Kaplan <> wrote:
    >>
    >>>> It should be easier to have a large number of python versions on one
    >>>> machine... ?I am realy fond of 2.5 so I am probily going to start
    >>>> compiling them or just include the python2.5 exe if I port stuff and
    >>>> settle it that way..
    >>>
    >>> You're on the only platform where it isn't that easy. All us *nix
    >>> users have to do is compile it with the altinstall flag, and then use
    >>> #!/usr/bin/env python25
    >>> Windows uses the file extension instead of the shebang line to execute
    >>> stuff, so it's harder for you to have multiple versions.

    >>
    >> If you install a real shell on Windows, then the hash-bang line works
    >> fine. :)

    >
    > Might as well spare yourself the trouble and install linux or *bsd. It's
    > probably easier.


    Ah, yeah, and then run all those Windows applications one requires on
    Wine...

    --
    John Bokma j3b

    Hacking & Hiking in Mexico - http://johnbokma.com/
    http://castleamber.com/ - Perl & Python Development
     
    John Bokma, Jun 28, 2010
    #20
    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. Stephen Hansen

    Re: I strongly dislike Python 3

    Stephen Hansen, Jun 26, 2010, in forum: Python
    Replies:
    12
    Views:
    496
    Andreas Waldenburger
    Jun 27, 2010
  5. John Nagle
    Replies:
    79
    Views:
    1,933
    Philip Semanchuk
    Jul 8, 2010
Loading...

Share This Page