Python 2.8 Un-release Schedule(python.org)
python.org
Python 2.8 Un-release Schedule
http://www.python.org/dev/peps/pep-0404/
13 comments
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.
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.
Honest question though: do you think that, given all of the breaking changes and toughness of upgrading, _even more_ should have been broken in this release to improve the language?
I guess that's my most major beef with it. The upgrade has been tough, and a lot of the most inconsistent aspects of Python weren't fixed. (A good example: "len()")
BTW, I tried using Python 3 on that project in 2010, if that helps anyone gauge my opinion on it.
I guess that's my most major beef with it. The upgrade has been tough, and a lot of the most inconsistent aspects of Python weren't fixed. (A good example: "len()")
BTW, I tried using Python 3 on that project in 2010, if that helps anyone gauge my opinion on it.
> Honest question though: do you think that, given all of the breaking changes and toughness of upgrading, _even more_ should have been broken in this release to improve the language?
Yeah, sure, there are still some things in there that make me wonder why they didn't go one step further to fix it too. Little things even, like the names of the special methods to intercept attribute access: __getattr__ and __getattribute__ should have been swapped for consistency, since __getattribute__ is closer in behavior to __setattr__ and __delattr__, making the current __getattr__ the behavioral outlier.
But meh, any language has its odd little warts, and so has Python 3. It does have significantly less than Python 2, though.
Yeah, sure, there are still some things in there that make me wonder why they didn't go one step further to fix it too. Little things even, like the names of the special methods to intercept attribute access: __getattr__ and __getattribute__ should have been swapped for consistency, since __getattribute__ is closer in behavior to __setattr__ and __delattr__, making the current __getattr__ the behavioral outlier.
But meh, any language has its odd little warts, and so has Python 3. It does have significantly less than Python 2, though.
I think that len() is not a good example, it was actually designed that way for a very good reason. [0]
[0]. http://lucumr.pocoo.org/2011/7/9/python-and-pola/
[0]. http://lucumr.pocoo.org/2011/7/9/python-and-pola/
I love python. It took a while but it has won me over, and I've come to appreciate its commitment to legibility and consistency. At this point it only loses out to javascript in my heart because javascript is universally deployed on users' machines.
However this is complete and utter bullshit.
Other languages are inconsistent? The answer is not to be inconsistent, and you can be consistent as a method or as a builtin function.
Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care.
The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?
Sorry for going off on a rant, please correct me if I'm wrong here. I just get so frustrated with the eagerness of the Python community's apologetics for things that no longer make sense to be in the language.
I can feel it working within me too, I'm more and more on the fence about explicit self.
However this is complete and utter bullshit.
Other languages are inconsistent? The answer is not to be inconsistent, and you can be consistent as a method or as a builtin function.
Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care.
The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?
Sorry for going off on a rant, please correct me if I'm wrong here. I just get so frustrated with the eagerness of the Python community's apologetics for things that no longer make sense to be in the language.
I can feel it working within me too, I'm more and more on the fence about explicit self.
> Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care.
Python didn't have properties when the len protocol was implemented. What exactly will be gained if Python replaces len(a) with a.length(where a.length translates to a.__len__())? If properties were there from the beginning, that would have been the implementation; but since they weren't, len(a) is just fine and I don't see any reason for it to be changed.
> The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?
Personally I would have preferred __len__ to be just length, because length of a sequence is part of it's public interface, as opposed to other special methods viz. __getattr__, __getitem__. Apart from that, his 'special meaning' section is just saying that following a weird naming convention for the special methods permits programttacily differentiating between public interface and special methods.
> I can feel it working within me too, I'm more and more on the fence about explicit self.
The main reason it is that way is decorators.
http://neopythonic.blogspot.in/2008/10/why-explicit-self-has...
> However this is complete and utter bullshit.
This isn't an appropriate response to a well thought out article.
Python didn't have properties when the len protocol was implemented. What exactly will be gained if Python replaces len(a) with a.length(where a.length translates to a.__len__())? If properties were there from the beginning, that would have been the implementation; but since they weren't, len(a) is just fine and I don't see any reason for it to be changed.
> The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?
Personally I would have preferred __len__ to be just length, because length of a sequence is part of it's public interface, as opposed to other special methods viz. __getattr__, __getitem__. Apart from that, his 'special meaning' section is just saying that following a weird naming convention for the special methods permits programttacily differentiating between public interface and special methods.
> I can feel it working within me too, I'm more and more on the fence about explicit self.
The main reason it is that way is decorators.
http://neopythonic.blogspot.in/2008/10/why-explicit-self-has...
> However this is complete and utter bullshit.
This isn't an appropriate response to a well thought out article.
On reflection, the bullshit comment was overblown. The author was not trying to be deceptive or anything. I take it back.
len and __len__ may have made sense when they were first implemented, I do not disagree.
Having tutored students learning python as their first experience programming, I recall that it was confusing that len was a function which merely calls a method on its argument. They wanted to know when they should write their own functions in a similar style.
I looked into it, and the best answer I came up with was that len is an historical artifact. If it were designed with the capabilities of modern Python, then there would be no good reason for doing it that way that I can find. Please correct me if I'm wrong.
The article as a whole is quite good. Its arguments in favor of len being a builtin function are quite bad. I've noticed this as something of a pattern in the Python community that I'm speaking out against. It's ok for there to be things in a project the size and age of Python that are historical artifacts. Python is certainly far and away better in this regard than its sibling languages.
Defending them as good design is counterproductive. I don't want newly designed languages to ape the mistakes of the old.
Having tutored students learning python as their first experience programming, I recall that it was confusing that len was a function which merely calls a method on its argument. They wanted to know when they should write their own functions in a similar style.
I looked into it, and the best answer I came up with was that len is an historical artifact. If it were designed with the capabilities of modern Python, then there would be no good reason for doing it that way that I can find. Please correct me if I'm wrong.
The article as a whole is quite good. Its arguments in favor of len being a builtin function are quite bad. I've noticed this as something of a pattern in the Python community that I'm speaking out against. It's ok for there to be things in a project the size and age of Python that are historical artifacts. Python is certainly far and away better in this regard than its sibling languages.
Defending them as good design is counterproductive. I don't want newly designed languages to ape the mistakes of the old.
> Other languages are inconsistent? The answer is not to be inconsistent, and you can be consistent as a method or as a builtin function.
With dynamically typed languages, it is very hard to "be consistent as a method" since there are no tools to enforce that consistency. Social cues usually go 90% of the way, but not all the way whereas a function/generic method handles that just fine: to get a length, you call `len`. Period. The developer does not really have the option to do otherwise, unless he wants to opt out of the language's ecosystem.
Actually what I said above is not entirely true, there is one situation where it is "quite easy" to handle method consistency in a dynamically typed language: when you deal with mixins.
Because mixins have preconditions (methods and/or properties which need to exist for it to work), they enforce those names or they can't be used at all. And of course any method brought in by the mixin is "enforced" by default.
So is it with most things iteration in Ruby for instance: Enumerable mandates that a core internal iterator named `#each` exists (as well as #<=> optionally) and as a reward for doing so it gives about 30 methods "for free". That enforces consistency in collection traversal, because even if you reimplement some or all of these methods in the long term (for efficiency and whatnot) getting them "for free" out of the box is valuable.
With dynamically typed languages, it is very hard to "be consistent as a method" since there are no tools to enforce that consistency. Social cues usually go 90% of the way, but not all the way whereas a function/generic method handles that just fine: to get a length, you call `len`. Period. The developer does not really have the option to do otherwise, unless he wants to opt out of the language's ecosystem.
Actually what I said above is not entirely true, there is one situation where it is "quite easy" to handle method consistency in a dynamically typed language: when you deal with mixins.
Because mixins have preconditions (methods and/or properties which need to exist for it to work), they enforce those names or they can't be used at all. And of course any method brought in by the mixin is "enforced" by default.
So is it with most things iteration in Ruby for instance: Enumerable mandates that a core internal iterator named `#each` exists (as well as #<=> optionally) and as a reward for doing so it gives about 30 methods "for free". That enforces consistency in collection traversal, because even if you reimplement some or all of these methods in the long term (for efficiency and whatnot) getting them "for free" out of the box is valuable.
Why then is len special? Should we also have builtins to add to a collection?
If it is good design there, should others repeat it? For example, if a module author is defining a new protocol for a set of objects that anyone can implement should they provide functions that delegate to the methods in their protocol?
For myself I think that the python community can be counted on to be consistent without the need for this duplication and indirection.
If it is good design there, should others repeat it? For example, if a module author is defining a new protocol for a set of objects that anyone can implement should they provide functions that delegate to the methods in their protocol?
For myself I think that the python community can be counted on to be consistent without the need for this duplication and indirection.
> Should we also have builtins to add to a collection?
No, because each collection type (mapping, sequence, set, ...) has very different addition semantics (and potentially arguments as well). On the other hand, there is a builtin to iterate over stuff.
No, because each collection type (mapping, sequence, set, ...) has very different addition semantics (and potentially arguments as well). On the other hand, there is a builtin to iterate over stuff.
To be really frank for quality programming shops. Readability is hardly an issue. They have better issues to worry about like features, scalability etc.
And readability in itself, I mean alone in its own merit isn't a deciding factor for most projects today.
Far too many factors decide in choosing a language today, they rapidly change and will continue to change over time. Concurrency and JVM's feasibility is giving clojure great mileage in the mainstream.
The problem with python is, its brittle enough to break at any new syntax experiment. This doesn't do good for language evolution.
And evolution is what keeps you in the game. How else do you think Perl and Lisp have managed to survive and grow till today's date.
I don't sort of want to be making a negative point here. But hey Perl has been adding keywords and new syntax to Perl 5 without breaking backwards compatibility.
Some times flexibility is important.
And readability in itself, I mean alone in its own merit isn't a deciding factor for most projects today.
Far too many factors decide in choosing a language today, they rapidly change and will continue to change over time. Concurrency and JVM's feasibility is giving clojure great mileage in the mainstream.
The problem with python is, its brittle enough to break at any new syntax experiment. This doesn't do good for language evolution.
And evolution is what keeps you in the game. How else do you think Perl and Lisp have managed to survive and grow till today's date.
I don't sort of want to be making a negative point here. But hey Perl has been adding keywords and new syntax to Perl 5 without breaking backwards compatibility.
Some times flexibility is important.
This was my exact view as well. Especially since I've learned a few languages since I first learned Python, and I just don't understand why they didn't take the opportunity to implement more good features from other languages.
What are some examples of features from other languages that you would like to see in Python?
I'm kind of surprised people are surprised that upgrading to 3.x has gone slowly.
I'm kind of surprised that people think people are surprised that the upgrade to Python 3 has gone so slowly. After all, Guido himself has stated on numerous occasions that the migration would take many years to complete. The time to complete this transition is not so much of a problem for a language that plans to be around for the indefinite future. After all, the future is much longer than the past.
I'm kind of surprised that people think people are surprised that the upgrade to Python 3 has gone so slowly. After all, Guido himself has stated on numerous occasions that the migration would take many years to complete. The time to complete this transition is not so much of a problem for a language that plans to be around for the indefinite future. After all, the future is much longer than the past.
This still doesn't solve the problem of users who wish to start a project in Python now.
Should they work with 2.x which is going to go away, or 3 whose ecosystem is not ready yet.
Should they work with 2.x which is going to go away, or 3 whose ecosystem is not ready yet.
If your dependencies already support 3.x, at least in some svn/git trunk publicly available, there is no reason for sticking with 2.x.
I think the minute Django supports Python 3, we'll see the level of whining drop to almost zero.
I think the minute Django supports Python 3, we'll see the level of whining drop to almost zero.
Now that Django 1.4 has dropped support for 2.4, compatibility with 3.2 is going to be a lot easier. There is an experimental branch that Vinay Sajip has created https://bitbucket.org/vinay.sajip/django/ which I believe is being considered for merging in time for Django 1.5.
> I think the minute Django supports Python 3, we'll see the level of whining drop to almost zero.
As the grandparent's author for perspective: I don't use, nor have never used, nor intend to use Django. My issues with Python 3 have no basis in Django's compatibility.
Carry on.
As the grandparent's author for perspective: I don't use, nor have never used, nor intend to use Django. My issues with Python 3 have no basis in Django's compatibility.
Carry on.
Which part of the ecosystem is holding you back then?
Unless you believe Django ~ Python.
And that is bad news for Python, trust me. We have already seen this in the past.
And that is bad news for Python, trust me. We have already seen this in the past.
Perl ~ CGI/Sysadmin
Javascript ~ Jquery
Ruby ~ Rails
Python ~ Django???
To continue your silly analogy:
Association with a very popular project has its downsides, but the upsides are much stronger, in my opinion. For instance, would Ruby be as widely known, deployed and used for non-Rails projects if it wasn't for Rails? It probably would just be another "niche" language rarely used outside of Japan. OTOH gem probably wouldn't be as badly broken as it is.
C ~ Unix
Association with a very popular project has its downsides, but the upsides are much stronger, in my opinion. For instance, would Ruby be as widely known, deployed and used for non-Rails projects if it wasn't for Rails? It probably would just be another "niche" language rarely used outside of Japan. OTOH gem probably wouldn't be as badly broken as it is.
I don't think Python community ~ Django community; I do believe the loudest elements in any geek community are, invariably, web developers, who (unsurprisingly) are over-represented on the web. Once you satisfy them, the level of noise on any given subject drops considerably.
At the moment, they are pissed off that Django is not moving as fast as the language, so they whine that "nobody is moving to Python 3". As soon as that's fixed, the noise will drop.
Same for the numpy/scipy community, which is the other big one for Python. Lots of academic people there, who have a lot of spare time to bitch on the web.
At the moment, they are pissed off that Django is not moving as fast as the language, so they whine that "nobody is moving to Python 3". As soon as that's fixed, the noise will drop.
Same for the numpy/scipy community, which is the other big one for Python. Lots of academic people there, who have a lot of spare time to bitch on the web.
Use python 2.x, but write it in such a way that the code will run on python3 is the semi-official answer.
People who are supposed to make decisions on choosing technology are not going to think that way.
There are better things to worry than to maintain two parallel versions of the same code supposed to run on two different versions of Python.
Its either going to be one of them or some other language.
There are better things to worry than to maintain two parallel versions of the same code supposed to run on two different versions of Python.
Its either going to be one of them or some other language.
I think the point is that you don't have to keep two parallel versions of the same code, since it's possible to write a single version that it's both compatible with 2.7 and 3.X.
Exactly. A fair bit of python 3 has been backported to python 2, and there exist tools (like http://packages.python.org/six/) to help paper of the cracks. You might not necessarily be able to keep things 100% source compatible, but if you think and plan a little bit you should end up with a codebase that can quickly port over to python3 once all your third party libraries are supported and stable
I don't see any reason why I must do all this extra stuff. When there are better alternatives available elsewhere.
I don't see any reason why I must do all this extra stuff
You don't have to do all this extra stuff. You could say I'm going with python3 and simply live without (or port or re-implement) any features from third party libraries that don't have a python2 version. Or you could say I'm going with python2 and live with the facts that the language won't be evolving any more and a few years from now most libraries will only see updates to their python3 branch. Both of those approach are also perfectly reasonable depending on the scope of the project.
When there are better alternatives available elsewhere.
Obviously if there are significantly better answers than python to the problem you're facing then you should be using one of those alternatives. I was assuming that you'd already decided that python was the best fit for an upcoming project and needed a plan on how to proceed.
You don't have to do all this extra stuff. You could say I'm going with python3 and simply live without (or port or re-implement) any features from third party libraries that don't have a python2 version. Or you could say I'm going with python2 and live with the facts that the language won't be evolving any more and a few years from now most libraries will only see updates to their python3 branch. Both of those approach are also perfectly reasonable depending on the scope of the project.
When there are better alternatives available elsewhere.
Obviously if there are significantly better answers than python to the problem you're facing then you should be using one of those alternatives. I was assuming that you'd already decided that python was the best fit for an upcoming project and needed a plan on how to proceed.
In addition, if you're developing a web-based system you can write your code in preparation for Python 3. When you're ready to move over, you do a one-time port and drop Python 2.x support altogether.
Obviously this depends on a few things - deployment, time/cost etc.
Obviously this depends on a few things - deployment, time/cost etc.
As I said people have better issues to worry about than walking on a string trying to balance not falling on either side.
They are either going to use one of them fully or neither.
They are either going to use one of them fully or neither.
Personally I use Python 2. I'll move to Python 3 when I think it's ready for prime time for my needs. I'm in no rush.
None of this deters me from thinking that Python 3 was the right thing to do.
None of this deters me from thinking that Python 3 was the right thing to do.
I am not sure about now, but another point is that when Python 3 was released it was slower as well, so there was hardly a reason to swap for very minor changes and no libraries. Python 3 should have been something radical like PyPy or large changes to the standard library.
There were large changes to the standard library :). The big io rewrite, for example (which was also one of the reasons for the slowdown initially as it was implemented in pure Python; it eventually got rewritten in C and should be faster than before now).
Anyway, I think it makes more sense to major-version language than implementation changes. In theory CPython vs. PyPy shouldn't matter to code.
Anyway, I think it makes more sense to major-version language than implementation changes. In theory CPython vs. PyPy shouldn't matter to code.
though if Tiobe is at all believed, Python is declining sharply in interest.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Java script seems to be going strong. Python has fallen by 3 places and has the maximum drop in ratings among top 20 languages.
Python is right next to Perl.
Since according to many Pythonistas and the references they used to point to in the past when they talked of Perl, Perl was dead for the same metrics which Python has now.
Can we say Python is dead? It must be since TIOBE says so!
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Java script seems to be going strong. Python has fallen by 3 places and has the maximum drop in ratings among top 20 languages.
Python is right next to Perl.
Since according to many Pythonistas and the references they used to point to in the past when they talked of Perl, Perl was dead for the same metrics which Python has now.
1. A major revision whose ecosystem isn't ready.
2. Current stable widely deployed version is going to go away soon.
3. Fall in ratings.
4. Fall in usage.
5. Rise of new languages like clojure.
Can we say Python is dead? It must be since TIOBE says so!
TIOBE also says Delphi/Object Pascal is more popular than Ruby. Also where do you get the "Rise of new languages like clojure" from? Certainly not from TIOBE, it's not even in the top 50, which sounds about right (btw it's not that hard to have 1000% rise if your starting point is like 0.0001%)
> TIOBE also says Delphi/Object Pascal is more popular than Ruby
Why do you doubt this? Delphi was huge in the late 90s, and I would postulate that there is a major amount of legacy code still out there.
Why do you doubt this? Delphi was huge in the late 90s, and I would postulate that there is a major amount of legacy code still out there.
To everybody who is downvoting this, this is heights of hypocrisy and fanboy'ism.
I am just applying the same principles to Python what used to be applied to Perl.
And more importantly there is data to back up everything that I said.
I am just applying the same principles to Python what used to be applied to Perl.
And more importantly there is data to back up everything that I said.
I'd guess the downvotes are thanks to sloppy and/or biased dataanalysis rather than fanboyism. For one thing Perl has been dropping almost steadily for the last 7 years, Python just one.
> I am just applying the same principles to Python what
> used to be applied to Perl.
> Python is declining sharply in interest
Maybe it is only me, but I feel the number of Python-related articles is higher than ever on HN.
Maybe it is only me, but I feel the number of Python-related articles is higher than ever on HN.
You took what I wrote out of context. I wrote "if Tiobe is at all believed, Python is declining...". I wasn't postulating that I have evidence of it other than to say Tiobe has indicated that.
Though, it'd be interesting to write some code to pull language interests off HN. It would be an interesting experiment. Granted, HN is a tiny subset of the programming community, but it would be interesting nevertheless.
Though, it'd be interesting to write some code to pull language interests off HN. It would be an interesting experiment. Granted, HN is a tiny subset of the programming community, but it would be interesting nevertheless.
Coudlent agree more. Py3 was/is a shocking disaster. All this work and effort for nothing...except crap that most people dont care or know about...like how Unicode strings a dealt with internally and stuff.
Things that would have made Py3 enticing to me: - JIT - Real GIL improvements (no changing from op-slicing to time-slicing is not a real improvement) - Better OO. Roles, traits, enough with the duck-typing. - Anonymous subroutines/multiline lambdas. Creating closure generators is too much work in Python compared to Perl. - Tail recursion - More stuff that will come to me after I click "submit"
Things that would have made Py3 enticing to me: - JIT - Real GIL improvements (no changing from op-slicing to time-slicing is not a real improvement) - Better OO. Roles, traits, enough with the duck-typing. - Anonymous subroutines/multiline lambdas. Creating closure generators is too much work in Python compared to Perl. - Tail recursion - More stuff that will come to me after I click "submit"
Whoa whoa, Unicode is huge for users of internationalized libraries and internationalization packages. I think you're underestimating the importance of this.
JIT and GIL are not language features, they're implementation details. Once alternative implementations catch up, many will look at this again.
The other things are considered to be language features by many, have been discussed to death by developers and users alike, and are unlikely to be changed or modified any time soon.
JIT and GIL are not language features, they're implementation details. Once alternative implementations catch up, many will look at this again.
The other things are considered to be language features by many, have been discussed to death by developers and users alike, and are unlikely to be changed or modified any time soon.
The unicode change is net-even functionally with 2.x. Unicode everywhere is a nice goal, but let's not pretend that 2.x can't do unicode and that 3.x is the only solution.
Not to mention that 3.x breaks many things about strings and unicode that were perfectly fine under 2.x. Things like forcing separate codecs for str/unicode (double the work!) and the elimination of basestr (what? why?). Armin did a great article on this a while back.
Sure python2 can do Unicode, but it's a pain and it's far too easy to introduce bug if you're not paying attention. Unicode everywhere is probably the only python3 feature I miss with any regularity when using python2.
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.
Perl 5 is right out.
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.
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.
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.
s/fashion/fear/ with a small pinch of missing libraries, as you said (btw i hear numpy is getting there.)
numpy/scipy/matplotlib have been there for about a year, according to http://pythonsprints.com/2011/04/8/matplotlib-python-3-thank...
(I am dragging my feet on this, too.)
(I am dragging my feet on this, too.)
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.
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.
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).
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.
In addition, integer division now produces floating point numbers for non-integer results.
Grr.
Grr.
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 //.
Because int/float conversions are not free! It is hidden, hard-to-reason-about computation that now, you have to explicitly look for.
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.
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.
Haskell's division operator (/) does not do floating point conversion. It may seem that way to you since evaluating 3/4 gives 0.75, for example. What actually happens is that every integer literal get the function fromInteger applied to it automatically, this function converts integers to whatever other type is necessary. So if you evaluate 3/4 at the REPL you're really computing (fromInteger 3) / (fromInteger 4), giving, by default[^1] a floating point number.
The key point in this is that only integer literals get fromInteger applied automatically, so for example
[^1]: only by default, if you load the rational number library, you can ask for / to compute rational numbers by simply saying the type of result you want: 3/4 :: Ratio Int evaluates to the rational number 3 % 4 (% is Haskell's odd choice of notation for rationals).
The key point in this is that only integer literals get fromInteger applied automatically, so for example
let n=6 :: Integer in n/3
let n=6 in n/3
[^1]: only by default, if you load the rational number library, you can ask for / to compute rational numbers by simply saying the type of result you want: 3/4 :: Ratio Int evaluates to the rational number 3 % 4 (% is Haskell's odd choice of notation for rationals).
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.5One 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).
I agree with your grumble, division of integers with a non-integer result should give an exact rational number, not some messy floating point approximation. Clojure does that, for example.
Heh, PEP 404. Nice.
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.
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.
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.
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.
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.
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
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.
Thanks for the Pillow link, btw. I was unaware of it.
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.
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.
agreed. Django is a major reason why adoption hasn't been quicker up to now.
Wait till this fall when we release Django 1.5 :)
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.
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.
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.
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.
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.
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.
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
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
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.
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.
That's so idiotic, I can't believe it might be the consensus on the python lists. It's exactly the right approach if you want to keep everyone on python 2 forever.
Linux developers and sysadmins are lazy by default (with good reasons: they have a lot to do). To make them get off their arses, you have to switch defaults and scream loudly when stuff breaks, otherwise they'll never bother.
If the problem is that it will break package xyz that is so old and completely unmaintained that nobody can fix it, well, it's a good reason to drop a zombie package. If your code depends on a zombie package, things would have broken down sooner or later anyway.
Linux developers and sysadmins are lazy by default (with good reasons: they have a lot to do). To make them get off their arses, you have to switch defaults and scream loudly when stuff breaks, otherwise they'll never bother.
If the problem is that it will break package xyz that is so old and completely unmaintained that nobody can fix it, well, it's a good reason to drop a zombie package. If your code depends on a zombie package, things would have broken down sooner or later anyway.
Sorry, you are right, I did mean that /usr/bin/python is usually 2.7.
For someone just starting out with python (on linux anyways) that means they are probably going to fire up that interpreter first.
I was wondering myself actually if any of the distros would switch to 3.0. I think a lot of packages would break if that were to happen.
As you've said, Arch has already switched but their package release isn't really typical for most distros.
For someone just starting out with python (on linux anyways) that means they are probably going to fire up that interpreter first.
I was wondering myself actually if any of the distros would switch to 3.0. I think a lot of packages would break if that were to happen.
As you've said, Arch has already switched but their package release isn't really typical for most distros.
Ubuntu's Python maintainer Barry Warsaw recently announced their goal to have no Python 2 in the "main" part of the repositories by their April 2014 release: http://lwn.net/Articles/469939/
I think that's probably a too aggressive schedule to actually keep, but here's hoping.
I think that's probably a too aggressive schedule to actually keep, but here's hoping.
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.
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/
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.
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/
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.
Arch moved to python3 well over a year ago.
Python2 is still in base-devel, but /usr/bin/python symlinks to python3, not python2.
Python2 is still in base-devel, but /usr/bin/python symlinks to python3, not python2.
You are right, I remember seeing that on my laptop.
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.
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.
Great reasons to upgrade.
But they should also mention they are taking away our beloved print and quick string formatting.
But they should also mention they are taking away our beloved print and quick string formatting.
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-...).
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-...).
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.
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...
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.
Anyway, the observation is to note how long it takes to get people "upgrade" when "breaking" changes are made to languages.
Love that it is 404 :)
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.