16 ms·

Python 2.8 Un-release Schedule

110 points by Toddward 15y ago

polemic 15y ago
Heh, PEP 404. Nice.
marchdown 15y ago
For some reason, adoption has been really slow so far; it is disappointing to see so many beginners pick Python 2 over 3. I believe that even MIT and Coursera teach Python 2.
- eli 15y ago
  Can you blame them? It's what experienced Python developers are using in the real world and there are orders of magnitude more tutorials for Python 2.
- sho_hn 15y ago
  This is one reason I like to recommend Lutz' book to beginners. Aside from generally being rather decent and thorough, it also teaches Python 3 and how Python 2 differs from it (rather than the other way around, or ignoring Python 3 altogether), resulting in a full, useful education on both, but from the right vantage point.
  - sateesh 15y ago
    I like the Lutz's book. I think if there is a version of the book which covers only Python3, that would be a great start for a person who is absolutely newbie to Python. For a Python beginner I think the constant reference/comparison and going back and forth (in the book) between Python 2 and Python 3 would be rather distracting.
- Deinumite 15y ago
  One of the issues is that almost every Linux distro is still shipping 2.7+ (and with good reason, there's a lot of code that won't run in 3.0 still). I think now that 2.7 is the last we will start to see a bit more migrate. Edit: I didn't mean they aren't shipping 3.0, but that the default is still 2.7.x
  - sho_hn 15y ago
    That's simply not true, unless perhaps you actually mean "almost every Linux distro" (i.e. including the bulk of distros that have a whole of five users and release once in a blue moon). The fact is that almost every major distro is shipping Python 3, and often has been for several releases/years: Fedora, Ubuntu, openSUSE, Debian, Gentoo, ArchLinux ... and many of these also have anywhere from dozens to hundreds of Python 3 libraries packaged. If you mean that /usr/bin/python still points to Python 2 on most of these (in fact all of them except for ArchLinux): True, and that is unlikely to change, possibly never. It's my understanding that this is in keeping with upstream's wishes (from discussions on python-devel and python-porting): bin/python is to remain Python 2 with python3 being the right way to run the Python 3 interpreter.
    - chimeracoder 15y ago
      I'm curious if a distribution like RedHat will ever link /usr/bin/python to python3 instead of python2, the way Arch did. Arch gets away with it because it's a bleeding-edge rolling-release distro, but a distro like CentOS that prides itself on stability has much more to lose. This is the only real point of uncertainty, if you ask me.
      - sho_hn 15y ago
        I think they won't, that it's no longer a point of uncertainty, and that Arch essentially made a mistake in switching their /usr/bin/python prematurely. The consensus from Python list discussions like "Shebang lines for Python 3" and "Support the /usr/bin/python2 symlink upstream" seemed to be that /usr/bin/python is to remain Python 2 indefinitely and that newly-written scripts should call python2 or python3 explicitly. If I recall right Guido's stance was the latter, but leaving plain python up to distros. There's also PEP 394: http://www.python.org/dev/peps/pep-0394/ http://www.python.org/dev/peps/pep-0394/ This is further cemented, if you will, by the new Windows launcher in 3.3 that extends shebang support to that platform and supports the same mappings. That said, one of the KDE applications I maintain contains a fair amount of Python code, and since I consider Python 3 to be a much nicer language, it of course runs fine on 3.x. And purely from an emotional POV the fact that the Arch packages get to install those scripts without their usual sed call to replace "python" with "python2" does bring a smile to my face.
- sigzero 15y ago
  To be fair, Guido laid out a 5 year process for it and we are just over half way. There is actually movement now as libs get moved over.
- johnthedebs 15y ago
  For what it's worth, it was intended to be a slow transition (3-5 years) since it's a chicken/egg situation because of backwards compatibility. The good news is that adoption should pick up very quickly after this fall. Python 3.3 will make it easier to port Python 2 projects and provide more incentives to upgrade. There's also nearly a critical percentage of major packages ported, and Django (which is still on Python 2, and is a deal breaker for many people) will have experimental support for versions up to 3.3. I expect that by this time next year, the default for most new projects will be Python 3.
  - thong 15y ago
    agreed. Django is a major reason why adoption hasn't been quicker up to now.
    - ubernostrum 15y ago
      Wait till this fall when we release Django 1.5 :)
      - timc3 15y ago
        Friendly question - What is the reason for the delay, I haven't read much on the reasons why Django doesn't support Python 3 as I have been happy with 2.7 for ages.
        ubernostrum 15y ago
        To get to Python 3 support, you first have to drop support for Python 2 versions under 2.6, because 2.6 began introducing Python 3 compatibility features that make it possible to run the same code on 2.6/2.7 and on 3.x. That's basically 90% of the time taken right there, since we had to do it one Python version at a time, giving people warnings that we'd be dropping support for 2.3, then 2.4, etc. so they'd be able to migrate up to a newer Python.
- notatoad 15y ago
  adoption hasn't seemed slower than reasonable to me. there's been steady progress in porting packages over to it, and until the packages you need are there there isn't much point in using python3.
- bgalbraith 15y ago
  I do a lot of scientific computing in Python and have had awful experiences with Python 3. We encourage everyone who comes into our lab to work with 2.7 because the libraries are all there. It's true that Numpy and Scipy now build for Python 3, but another key library, PIL, is lost in limbo with no clear timeline for porting last I checked. The only reason I've used Python 3 at all was because of project involving blender. I needed to do in-memory JPEG compression for quickly streaming images from the game engine. In Python 2, this is a couple lines of code using PIL. Instead, I ended up having to write my own pyjpeg module that provided a ctypes interface to a custom libjpeg-based compression library. I'm proud of the result, but the aggravation and frustration that entailed has removed any desire I have to move to Python 3.
  - JonAtkinson 15y ago
    I don't see why the irresponsible maintainership of PIL should reflect badly on Python 3. Pillow is a fork of PIL which was created to address some of these problems: http://pypi.python.org/pypi/Pillow#why-a-fork http://pypi.python.org/pypi/Pillow#why-a-fork
    - bgalbraith 15y ago
      I should clarify that Python 3, by itself, is fine. I had the unfortunate situation of having to use it for a task in which no suitable library existed, which led to a significant amount of unwelcome additional effort. However, until those library deficiencies are fully met, it makes no sense to move forward from 2.7. Thanks for the Pillow link, btw. I was unaware of it.
melling 15y ago
As a Perl guy waiting for Perl 6, I never understood why Python devs were waiting. I'd talk to Python guys and they'd say some library or another was missing. Then I would explain how exciting it was to have a breaking version that fixed defects and warts, and in general making the language better. Of course, I'm still waiting for Perl 6 plus another 5 before adoption. Oh well, I'm glad someone is finally moving ahead.
- Jach 15y ago
  As a non-Perl guy, I thought it was supposedly clear that Perl 6 is a completely different language than Perl 5 and isn't meant to replace it? So I don't think Perl 5 : Perl 6 :: Python 2 : Python 3 is really that analogous...
  - melling 15y ago
    Perl 6 will have a Perl 5 compatibility mode. Yes, it's a more ambitious effort and it's a loose analogy. However, I don't think there's a need to have both Perl 5 and 6. It's meant as an evolution to solve the same kinds of problems. Perl 5 came back to life after it became clear Perl 6 was going to take even longer, and it's adding some of the improvements from Perl 6. Anyway, the observation is to note how long it takes to get people "upgrade" when "breaking" changes are made to languages.
ff0066mote 15y ago
I've been using Python2 now for 4 years but have been dragging my feet upgrading to Python3. Finally, I started learning it just a month ago and now I don't know what ever stopped me before. In fact, the most annoying thing I've found about Python3 is that my searches for documentation on DDG or Google all go to the Python2 docs.
- backprojection 15y ago
  My impression is that the slowness to adopt python3 is mostly about fashion than anything else, not that there aren't solid, technical reasons to stay with python2. The main thing for me is availability of numpy/scipy packages for python 3.
  - baq 15y ago
    s/fashion/fear/ with a small pinch of missing libraries, as you said (btw i hear numpy is getting there.)
    - Estragon 15y ago
      numpy/scipy/matplotlib have been there for about a year, according to http://pythonsprints.com/2011/04/8/matplotlib-python-3-thanks-cape-town-group/ http://pythonsprints.com/2011/04/8/matplotlib-python-3-thank... (I am dragging my feet on this, too.)
ec429 15y ago
Three shall be the version of the Python, and the version of the Python shall be three. Version four shalt thou not use, nor shalt thou use version two, excepting that thou then upgrade to three. Perl 5 is right out.
manojlds 15y ago
Love that it is 404 :)
veyron 15y ago
There really should be an effort to get people to write new code in python3 and use 3to2 to backport (rather than writing in python2 and using 2to3 to convert).
- bdarnell 15y ago
  The biggest obstacle there is the lack of setuptools/distribute integration. It's easy to run 2to3 at install time when your source distribution is python2, but there's no support for going in the other direction.
trimbo 15y ago
I'm kind of surprised people are surprised that upgrading to 3.x has gone slowly. You can't upgrade a major installed base overnight unless there's incentive. Windows Vista, for example? Additionally, it has stumbling blocks towards achieving the upgrade. Packages you're using aren't upgraded, you have a lot of code dealing with strings, and so on. I worked on a project that tried to use Python 3.x and it was a nightmare in both regards. In my view, Python 3 doesn't offer any major reasons to upgrade other than we've been told to. Someone tell me: what is it that's so compelling about Python 3? For instance, when you click on "What's new in Python 3" on this page, the first thing in the list is "print is a function". Seriously? The FIRST thing in the list is something that breaks code and has very little impact. Unicode has a lot more impact, breaks a lot more stuff, and is doable in 2.x anyway, yet is the 5th or 6th thing in the list. So I'm not really sure what the devs were thinking with Python 3.x. It broke a lot of stuff but didn't break enough to make Python notably better. I was around and a heavy Python user for the 1.x -> 2.x upgrade. That was far easier, had some features I could really use, and there was a much smaller installed base. This time around, I just don't see the reason I should upgrade. Eventually, I imagine I will when support is so far gone that there's no choice, or there's some amazing feature that requires it. For those of you who will respond: "So don't upgrade, or switch off Python". One of those is mission accomplished. The other one remains to be seen, though if Tiobe is at all believed, Python is declining sharply in interest.
- sho_hn 15y ago
  I haven't written any code that doesn't run on Python 3 since 2010. I'm in the comfortable position of generally getting to use Python 3 for new projects (my library dependencies are met), and when I don't, the shared subset of Python 2.7 and 3 is useful enough to get the job done. There's lots of reasons I find coding in Python 3 more enjoyable and productive. Unicode by default, removing x*() functions and returning generators where appropriate instead, removing old-style classes, improved consistency in standard object interfaces/protocols, standard lib cleanups, etc. Yes, even print() - keyword args are a lot nicer than the old hackish syntax for things like the output file. These are often called minor and "no compelling reason to upgrade", but I'd submit that when a language does more often what you expect it to do, when the number of gotchas you need to keep in mind is reduced significantly, that's not minor. It might not be a reason to switch a large existing codebase over, but it's certainly a reason to write the next large codebase in it, and that's what Python 3 aims at: The future of Python and its future users. No, that doesn't make for a fast transition, but indeed, it was never expected to be ("five years" is the plan, we're not there yet, and things look to be on track). Eventually, there just won't be any reasons left not to use Python 3, but plenty of reasons to do so (the better core language, the sum of improvements in the standard lib, the continued maintenance), and then it'll be done.
andraz 15y ago
Great reasons to upgrade. But they should also mention they are taking away our beloved print and quick string formatting.
- wladimir 15y ago
  To be precise, print is now a function instead of a statement. It has not been taken away. Just add parenthesis. The string formatting syntax did indeed change, but the new syntax is just as "quick" as the old one, just different (see http://stackoverflow.com/questions/517355/string-formatting-in-python http://stackoverflow.com/questions/517355/string-formatting-...).
qwe123_troll 15y ago
Python jumped the shark, time to find a better language.
yason 15y ago
THis isn't surprising. Python 3 was advertised, back in the time, as "mainstream, please don't bother yet, we'll do a few more 2.x releases while letting the community catch up with jumping through the hoops of Python 3". That is, at the same time when they removed some tried and true language constructs people liked and didn't add more of any powerful features that everyone was hoping for. I bet Python 2.x will dominate for a long time, possibly with PyPy w/ LLVM becoming the de facto implementation instead of the discontinued CPython. Also, another party will at some point continue developing the 2.x line further.
kamaal 15y ago
I've tried to push Python for many projects at our shop. But it always get shot down by We don't want to write in 2.x series as its going to go away, and 3.x ecosystem isn't ready yet. The more this continues, the more some technology is going to eat Python's lunch. If Python wanted to break backwards compatibility they should have done so with some big major changes. That would have been justifiable. Right now no one sees a reason to break backwards compatibility to go to a no-so-ready ecosystem at the expense little gains. At the same time no wants to write 2.x either. At least people planning to maintain their code base for years aren't going to write in a major version that's going to go away.
gaius 15y ago
In addition, integer division now produces floating point numbers for non-integer results. Grr.
- rplnt 15y ago
  Well, that makes sense, doesn't it? Not in relation to prehistoric programming languages, but in relation to humans. I'd imagine it's hard to think about programming language without comparing it to others... but try it. Why would 5/2 be 2 and not 2.5? That being said, you can (still) use //.
  - gaius 15y ago
    Because int/float conversions are not free! It is hidden, hard-to-reason-about computation that now, you have to explicitly look for.
    - rplnt 15y ago
      One could argue that writing a/float(b) just to get float result isn't free (nor nice for that matter) either. But I still think the strongest argument is that someone who isn't corrupted by other languages would expect to get a float result (when necessary).
    - lolcraft 15y ago
      If my work's performance requirements were so tight as to make that an issue, I would use C. Or numpy. CPython is slow. CPython is so mind-numbingly slow, for many many reasons, that each numeric variable could be a bigfloat and it would not matter the slightest. Now, let's talk semantics. Not converting to floating point is precisely the kind of hidden computation that should be avoided, at all costs, in a language. Haskell is efficient and rigorous, and its division operator does floating point conversion. So, no excuses.
      - gaius 15y ago
        I see your Haskell and raise you OCaml, which has / and /. operators and you use float_of_int with /. if you really do want a float at the end. # 5/2;; - : int = 2 # 5 /. 2;; Error: This expression has type int but an expression was expected of type float # 5.0 /. float_of_int 2;; - : float = 2.5

110 points by Toddward 15y ago

Heh, PEP 404. Nice.

For some reason, adoption has been really slow so far; it is disappointing to see so many beginners pick Python 2 over 3. I believe that even MIT and Coursera teach Python 2.

eli 15y ago
Can you blame them? It's what experienced Python developers are using in the real world and there are orders of magnitude more tutorials for Python 2.
sho_hn 15y ago
This is one reason I like to recommend Lutz' book to beginners. Aside from generally being rather decent and thorough, it also teaches Python 3 and how Python 2 differs from it (rather than the other way around, or ignoring Python 3 altogether), resulting in a full, useful education on both, but from the right vantage point.
- sateesh 15y ago
  I like the Lutz's book. I think if there is a version of the book which covers only Python3, that would be a great start for a person who is absolutely newbie to Python. For a Python beginner I think the constant reference/comparison and going back and forth (in the book) between Python 2 and Python 3 would be rather distracting.
Deinumite 15y ago
One of the issues is that almost every Linux distro is still shipping 2.7+ (and with good reason, there's a lot of code that won't run in 3.0 still). I think now that 2.7 is the last we will start to see a bit more migrate. Edit: I didn't mean they aren't shipping 3.0, but that the default is still 2.7.x
- sho_hn 15y ago
  That's simply not true, unless perhaps you actually mean "almost every Linux distro" (i.e. including the bulk of distros that have a whole of five users and release once in a blue moon). The fact is that almost every major distro is shipping Python 3, and often has been for several releases/years: Fedora, Ubuntu, openSUSE, Debian, Gentoo, ArchLinux ... and many of these also have anywhere from dozens to hundreds of Python 3 libraries packaged. If you mean that /usr/bin/python still points to Python 2 on most of these (in fact all of them except for ArchLinux): True, and that is unlikely to change, possibly never. It's my understanding that this is in keeping with upstream's wishes (from discussions on python-devel and python-porting): bin/python is to remain Python 2 with python3 being the right way to run the Python 3 interpreter.
  - chimeracoder 15y ago
    I'm curious if a distribution like RedHat will ever link /usr/bin/python to python3 instead of python2, the way Arch did. Arch gets away with it because it's a bleeding-edge rolling-release distro, but a distro like CentOS that prides itself on stability has much more to lose. This is the only real point of uncertainty, if you ask me.
    - sho_hn 15y ago
      I think they won't, that it's no longer a point of uncertainty, and that Arch essentially made a mistake in switching their /usr/bin/python prematurely. The consensus from Python list discussions like "Shebang lines for Python 3" and "Support the /usr/bin/python2 symlink upstream" seemed to be that /usr/bin/python is to remain Python 2 indefinitely and that newly-written scripts should call python2 or python3 explicitly. If I recall right Guido's stance was the latter, but leaving plain python up to distros. There's also PEP 394: http://www.python.org/dev/peps/pep-0394/ http://www.python.org/dev/peps/pep-0394/ This is further cemented, if you will, by the new Windows launcher in 3.3 that extends shebang support to that platform and supports the same mappings. That said, one of the KDE applications I maintain contains a fair amount of Python code, and since I consider Python 3 to be a much nicer language, it of course runs fine on 3.x. And purely from an emotional POV the fact that the Arch packages get to install those scripts without their usual sed call to replace "python" with "python2" does bring a smile to my face.
sigzero 15y ago
To be fair, Guido laid out a 5 year process for it and we are just over half way. There is actually movement now as libs get moved over.
johnthedebs 15y ago
For what it's worth, it was intended to be a slow transition (3-5 years) since it's a chicken/egg situation because of backwards compatibility. The good news is that adoption should pick up very quickly after this fall. Python 3.3 will make it easier to port Python 2 projects and provide more incentives to upgrade. There's also nearly a critical percentage of major packages ported, and Django (which is still on Python 2, and is a deal breaker for many people) will have experimental support for versions up to 3.3. I expect that by this time next year, the default for most new projects will be Python 3.
- thong 15y ago
  agreed. Django is a major reason why adoption hasn't been quicker up to now.
  - ubernostrum 15y ago
    Wait till this fall when we release Django 1.5 :)
    - timc3 15y ago
      Friendly question - What is the reason for the delay, I haven't read much on the reasons why Django doesn't support Python 3 as I have been happy with 2.7 for ages.
      - ubernostrum 15y ago
        To get to Python 3 support, you first have to drop support for Python 2 versions under 2.6, because 2.6 began introducing Python 3 compatibility features that make it possible to run the same code on 2.6/2.7 and on 3.x. That's basically 90% of the time taken right there, since we had to do it one Python version at a time, giving people warnings that we'd be dropping support for 2.3, then 2.4, etc. so they'd be able to migrate up to a newer Python.
notatoad 15y ago
adoption hasn't seemed slower than reasonable to me. there's been steady progress in porting packages over to it, and until the packages you need are there there isn't much point in using python3.
bgalbraith 15y ago
I do a lot of scientific computing in Python and have had awful experiences with Python 3. We encourage everyone who comes into our lab to work with 2.7 because the libraries are all there. It's true that Numpy and Scipy now build for Python 3, but another key library, PIL, is lost in limbo with no clear timeline for porting last I checked. The only reason I've used Python 3 at all was because of project involving blender. I needed to do in-memory JPEG compression for quickly streaming images from the game engine. In Python 2, this is a couple lines of code using PIL. Instead, I ended up having to write my own pyjpeg module that provided a ctypes interface to a custom libjpeg-based compression library. I'm proud of the result, but the aggravation and frustration that entailed has removed any desire I have to move to Python 3.
- JonAtkinson 15y ago
  I don't see why the irresponsible maintainership of PIL should reflect badly on Python 3. Pillow is a fork of PIL which was created to address some of these problems: http://pypi.python.org/pypi/Pillow#why-a-fork http://pypi.python.org/pypi/Pillow#why-a-fork
  - bgalbraith 15y ago
    I should clarify that Python 3, by itself, is fine. I had the unfortunate situation of having to use it for a task in which no suitable library existed, which led to a significant amount of unwelcome additional effort. However, until those library deficiencies are fully met, it makes no sense to move forward from 2.7. Thanks for the Pillow link, btw. I was unaware of it.

melling 15y ago

As a Perl guy waiting for Perl 6, I never understood why Python devs were waiting. I'd talk to Python guys and they'd say some library or another was missing. Then I would explain how exciting it was to have a breaking version that fixed defects and warts, and in general making the language better. Of course, I'm still waiting for Perl 6 plus another 5 before adoption. Oh well, I'm glad someone is finally moving ahead.

Jach 15y ago
As a non-Perl guy, I thought it was supposedly clear that Perl 6 is a completely different language than Perl 5 and isn't meant to replace it? So I don't think Perl 5 : Perl 6 :: Python 2 : Python 3 is really that analogous...
- melling 15y ago
  Perl 6 will have a Perl 5 compatibility mode. Yes, it's a more ambitious effort and it's a loose analogy. However, I don't think there's a need to have both Perl 5 and 6. It's meant as an evolution to solve the same kinds of problems. Perl 5 came back to life after it became clear Perl 6 was going to take even longer, and it's adding some of the improvements from Perl 6. Anyway, the observation is to note how long it takes to get people "upgrade" when "breaking" changes are made to languages.

ff0066mote 15y ago

I've been using Python2 now for 4 years but have been dragging my feet upgrading to Python3. Finally, I started learning it just a month ago and now I don't know what ever stopped me before. In fact, the most annoying thing I've found about Python3 is that my searches for documentation on DDG or Google all go to the Python2 docs.

backprojection 15y ago
My impression is that the slowness to adopt python3 is mostly about fashion than anything else, not that there aren't solid, technical reasons to stay with python2. The main thing for me is availability of numpy/scipy packages for python 3.
- baq 15y ago
  s/fashion/fear/ with a small pinch of missing libraries, as you said (btw i hear numpy is getting there.)
  - Estragon 15y ago
    numpy/scipy/matplotlib have been there for about a year, according to http://pythonsprints.com/2011/04/8/matplotlib-python-3-thanks-cape-town-group/ http://pythonsprints.com/2011/04/8/matplotlib-python-3-thank... (I am dragging my feet on this, too.)

ec429 15y ago

Three shall be the version of the Python, and the version of the Python shall be three. Version four shalt thou not use, nor shalt thou use version two, excepting that thou then upgrade to three. Perl 5 is right out.

manojlds 15y ago

Love that it is 404 :)

veyron 15y ago

There really should be an effort to get people to write new code in python3 and use 3to2 to backport (rather than writing in python2 and using 2to3 to convert).

bdarnell 15y ago
The biggest obstacle there is the lack of setuptools/distribute integration. It's easy to run 2to3 at install time when your source distribution is python2, but there's no support for going in the other direction.

trimbo 15y ago

I'm kind of surprised people are surprised that upgrading to 3.x has gone slowly. You can't upgrade a major installed base overnight unless there's incentive. Windows Vista, for example? Additionally, it has stumbling blocks towards achieving the upgrade. Packages you're using aren't upgraded, you have a lot of code dealing with strings, and so on. I worked on a project that tried to use Python 3.x and it was a nightmare in both regards. In my view, Python 3 doesn't offer any major reasons to upgrade other than we've been told to. Someone tell me: what is it that's so compelling about Python 3? For instance, when you click on "What's new in Python 3" on this page, the first thing in the list is "print is a function". Seriously? The FIRST thing in the list is something that breaks code and has very little impact. Unicode has a lot more impact, breaks a lot more stuff, and is doable in 2.x anyway, yet is the 5th or 6th thing in the list. So I'm not really sure what the devs were thinking with Python 3.x. It broke a lot of stuff but didn't break enough to make Python notably better. I was around and a heavy Python user for the 1.x -> 2.x upgrade. That was far easier, had some features I could really use, and there was a much smaller installed base. This time around, I just don't see the reason I should upgrade. Eventually, I imagine I will when support is so far gone that there's no choice, or there's some amazing feature that requires it. For those of you who will respond: "So don't upgrade, or switch off Python". One of those is mission accomplished. The other one remains to be seen, though if Tiobe is at all believed, Python is declining sharply in interest.

sho_hn 15y ago
I haven't written any code that doesn't run on Python 3 since 2010. I'm in the comfortable position of generally getting to use Python 3 for new projects (my library dependencies are met), and when I don't, the shared subset of Python 2.7 and 3 is useful enough to get the job done. There's lots of reasons I find coding in Python 3 more enjoyable and productive. Unicode by default, removing x*() functions and returning generators where appropriate instead, removing old-style classes, improved consistency in standard object interfaces/protocols, standard lib cleanups, etc. Yes, even print() - keyword args are a lot nicer than the old hackish syntax for things like the output file. These are often called minor and "no compelling reason to upgrade", but I'd submit that when a language does more often what you expect it to do, when the number of gotchas you need to keep in mind is reduced significantly, that's not minor. It might not be a reason to switch a large existing codebase over, but it's certainly a reason to write the next large codebase in it, and that's what Python 3 aims at: The future of Python and its future users. No, that doesn't make for a fast transition, but indeed, it was never expected to be ("five years" is the plan, we're not there yet, and things look to be on track). Eventually, there just won't be any reasons left not to use Python 3, but plenty of reasons to do so (the better core language, the sum of improvements in the standard lib, the continued maintenance), and then it'll be done.

andraz 15y ago

Great reasons to upgrade. But they should also mention they are taking away our beloved print and quick string formatting.

wladimir 15y ago
To be precise, print is now a function instead of a statement. It has not been taken away. Just add parenthesis. The string formatting syntax did indeed change, but the new syntax is just as "quick" as the old one, just different (see http://stackoverflow.com/questions/517355/string-formatting-in-python http://stackoverflow.com/questions/517355/string-formatting-...).

qwe123_troll 15y ago

Python jumped the shark, time to find a better language.

yason 15y ago

THis isn't surprising. Python 3 was advertised, back in the time, as "mainstream, please don't bother yet, we'll do a few more 2.x releases while letting the community catch up with jumping through the hoops of Python 3". That is, at the same time when they removed some tried and true language constructs people liked and didn't add more of any powerful features that everyone was hoping for. I bet Python 2.x will dominate for a long time, possibly with PyPy w/ LLVM becoming the de facto implementation instead of the discontinued CPython. Also, another party will at some point continue developing the 2.x line further.

kamaal 15y ago

I've tried to push Python for many projects at our shop. But it always get shot down by We don't want to write in 2.x series as its going to go away, and 3.x ecosystem isn't ready yet. The more this continues, the more some technology is going to eat Python's lunch. If Python wanted to break backwards compatibility they should have done so with some big major changes. That would have been justifiable. Right now no one sees a reason to break backwards compatibility to go to a no-so-ready ecosystem at the expense little gains. At the same time no wants to write 2.x either. At least people planning to maintain their code base for years aren't going to write in a major version that's going to go away.

gaius 15y ago

In addition, integer division now produces floating point numbers for non-integer results. Grr.

rplnt 15y ago
Well, that makes sense, doesn't it? Not in relation to prehistoric programming languages, but in relation to humans. I'd imagine it's hard to think about programming language without comparing it to others... but try it. Why would 5/2 be 2 and not 2.5? That being said, you can (still) use //.
- gaius 15y ago
  Because int/float conversions are not free! It is hidden, hard-to-reason-about computation that now, you have to explicitly look for.
  - rplnt 15y ago
    One could argue that writing a/float(b) just to get float result isn't free (nor nice for that matter) either. But I still think the strongest argument is that someone who isn't corrupted by other languages would expect to get a float result (when necessary).
  - lolcraft 15y ago
    If my work's performance requirements were so tight as to make that an issue, I would use C. Or numpy. CPython is slow. CPython is so mind-numbingly slow, for many many reasons, that each numeric variable could be a bigfloat and it would not matter the slightest. Now, let's talk semantics. Not converting to floating point is precisely the kind of hidden computation that should be avoided, at all costs, in a language. Haskell is efficient and rigorous, and its division operator does floating point conversion. So, no excuses.
    - gaius 15y ago
      I see your Haskell and raise you OCaml, which has / and /. operators and you use float_of_int with /. if you really do want a float at the end. # 5/2;; - : int = 2 # 5 /. 2;; Error: This expression has type int but an expression was expected of type float # 5.0 /. float_of_int 2;; - : float = 2.5