Updated Packages – Python 3.3(wiki.ubuntu.com)
wiki.ubuntu.com
Updated Packages – Python 3.3
https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview#Python_3.3
116 comments
I don't code Python so as an outsider it always seemed strange that almost all code was written for Python 2.x - like 3 was unanimously rejected from the community. Can anyone shed light on why this is/was the case?
It was not a rejection. Python 3 (project name Python 3000, just to give you the kind of scope we're talking about) was always expected to be a long and rather arduous migration, because it "cleaned up" a number of things in backwards-incompatible manner: the stdlib was reorganized, syntax was added (and removed), semantics altered (the basic string of Python 2 is a bytestring, in Python 3 it's a codepoint sequence and implicit conversions were removed from the language), shuffling between keywords and regular symbols, etc... It might have been even more arduous than the core team expected, but most of the community has been aware it'd take a long time from the start (the initial planning alone took ~30 months: the PEP3000 was created in April 2006 and Python 3.0 was released in December 2008, and as far as I remember Python 3.0 was not considered a production-able Python, more of a "stable" version for experiments and discovery in real-world settings)
Things were moving very slowly at the start, some features were backported to Python 2, others were reintroduced (in Python 3.2 and 3.3) and compatibility packages slowly appeared as people started experimenting with porting strategies and methods.
Since the second half of 2012, things have started picking up steam as bigger packages have started their migration effort (often as single-source, which is now considered the best strategy when possible) which is starting to solve the chicken-and-eggs problem for end-users (applications can't switch until all their dependencies are compatible)[0].
Python 2 will stick around though, there are 20 years of Python code which won't run as-is on Python 3, and may never do barring significant rewrite.
And of course Python 3 may yet be rejected by the community, although it definitely seems to be gaining — rather than losing — steam. The biggest problems in the long term will probably be in the Scientific Python communities.
[0] A few pretty big names are still Python 2 though, Werkzeug and Flask are big ones for webby stuff, the official-ish MySQL adapter is an other one for many, and a bunch are not considered "production-ready" state or side-packages are missing e.g. Django 1.5 is the start of Django's transition but many extensions such as South or the debug-toolbar are not p3-compatible.
Things were moving very slowly at the start, some features were backported to Python 2, others were reintroduced (in Python 3.2 and 3.3) and compatibility packages slowly appeared as people started experimenting with porting strategies and methods.
Since the second half of 2012, things have started picking up steam as bigger packages have started their migration effort (often as single-source, which is now considered the best strategy when possible) which is starting to solve the chicken-and-eggs problem for end-users (applications can't switch until all their dependencies are compatible)[0].
Python 2 will stick around though, there are 20 years of Python code which won't run as-is on Python 3, and may never do barring significant rewrite.
And of course Python 3 may yet be rejected by the community, although it definitely seems to be gaining — rather than losing — steam. The biggest problems in the long term will probably be in the Scientific Python communities.
[0] A few pretty big names are still Python 2 though, Werkzeug and Flask are big ones for webby stuff, the official-ish MySQL adapter is an other one for many, and a bunch are not considered "production-ready" state or side-packages are missing e.g. Django 1.5 is the start of Django's transition but many extensions such as South or the debug-toolbar are not p3-compatible.
How I wish Flask would support Python 3. And gevent, Twisted, PIL, NumPy, PyPy and... can I have gevent and PyPy working together as well? Oh well, back to reality!
> PIL
https://pypi.python.org/pypi/Pillow/2.0.0
> NumPy
We're at almost three years now that people have been wrongly complaining about NumPy not being on Python 3. When do you think it will end?
http://www.mail-archive.com/[email protected]/msg26...
> PyPy
It's getting close.
http://morepypy.blogspot.com/2013/03/py3k-status-update-10.h...
https://pypi.python.org/pypi/Pillow/2.0.0
> NumPy
We're at almost three years now that people have been wrongly complaining about NumPy not being on Python 3. When do you think it will end?
http://www.mail-archive.com/[email protected]/msg26...
> PyPy
It's getting close.
http://morepypy.blogspot.com/2013/03/py3k-status-update-10.h...
PIL barely works on python 2. You can't even install the official distribution inside a virtualenv without running into problems, so I don't expect them to sort anything out quickly.
Pillow works on py3 as others have already mentioned.
Pillow works on py3 as others have already mentioned.
Pillow supports Python 3 IIRC, and I think PIL can be built on Py3 as well/
Flask porting is WIP.
For current status see https://gist.github.com/untitaker/5321447 (Werkzeug is the most significant Flask dependency)
For current status see https://gist.github.com/untitaker/5321447 (Werkzeug is the most significant Flask dependency)
[deleted]
As a Rubyist it also seemed strange to me. As soon as Ruby 1.9 became stable, it was embraced by the community fairly quickly. Ruby 2.0 has only been out for a month and there are already projects that require 2.0. In contrast, Python 3 adoption still isn't finished, and Python 3 has been around for several years longer than Ruby 1.9.
I guess that the incompatible changes in Python 3 don't really help. Ruby 1.9 introduced incompatibilities but they were fairly minor and easy to resolve. The biggest incompatibility was probably the introduction of string encodings. Python 3 introduced a stricter string encoding system and changed syntax in some ways. Some of the syntax changes make it very difficult to write code that is compatible with 2.6, 2.7 and 3.0.
I guess that the incompatible changes in Python 3 don't really help. Ruby 1.9 introduced incompatibilities but they were fairly minor and easy to resolve. The biggest incompatibility was probably the introduction of string encodings. Python 3 introduced a stricter string encoding system and changed syntax in some ways. Some of the syntax changes make it very difficult to write code that is compatible with 2.6, 2.7 and 3.0.
Some of this may have to do with the general differences in attitude we often see between Ruby and Python developers.
In my experience, Python developers put much more emphasis on creating systems that are correct, secure, robust and reliable. Part of this involves thinking through any changes thoroughly, and being somewhat conservative in the adoption of new technologies and techniques.
The Ruby community, on the other hand, generally places much less emphasis on such factors. They're often much more willing to use newer software, even if it means the stability, correctness and security of the software systems they're building is decreased.
So it doesn't surprise me at all that Ruby developers would rush to a new version, while Python developers take a slower approach involving more thought and care.
In my experience, Python developers put much more emphasis on creating systems that are correct, secure, robust and reliable. Part of this involves thinking through any changes thoroughly, and being somewhat conservative in the adoption of new technologies and techniques.
The Ruby community, on the other hand, generally places much less emphasis on such factors. They're often much more willing to use newer software, even if it means the stability, correctness and security of the software systems they're building is decreased.
So it doesn't surprise me at all that Ruby developers would rush to a new version, while Python developers take a slower approach involving more thought and care.
Lol, I don't do Python or Ruby, but... biased much?
Not at all. Python and Ruby are just two tools among many that I've used at one point or another in my career. Besides, this isn't an issue with the tools themselves, but with the developers who use them. There are generally very significant differences in attitude between those in the Python camp and those in the Ruby camp.
Ruby != Rails, but we hardly here about Ruby without Rails, and Rails does have this reputation.
I know several pieces of production code that are still on Ruby 1.8.x. 1.9.x was adopted fairly quickly in some very vocal subsets of the Ruby community, but despite the fact that the incompatibilities are fairly small there are still people that haven't made the migration.
Personally I still run 1.8.x several places too, not because I have any particular reason to, but because I haven't had any particular reason to upgrade - not a single gem I depend on for my hobby projects require 1.9.x.
Personally I still run 1.8.x several places too, not because I have any particular reason to, but because I haven't had any particular reason to upgrade - not a single gem I depend on for my hobby projects require 1.9.x.
One big reason for moving to 1.9 is that 1.8 is hitting EOL in June[1]; this means no further security patches either.
(The plan for this was originally announced[2] in 2011.)
1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/4...
2. http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
(The plan for this was originally announced[2] in 2011.)
1. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/4...
2. http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
True, for people running Rails etc. on it. Said systems I know of aren't public facing and don't process user provided data... Not everyone uses Ruby for web apps.
The next version of Django (Python's largest web framework) will experimentally support Python 3.0 next release. They did so because maintaining two branches would be a pain, and they didn't want to dump their existing community. Not too long ago, matplotlib (the plotting library) didn't have ports for some versions. They were slow to port because they were waiting for scipy and numpy. Anything which deals heavily in string processing needs a major re-write. Libraries were waiting for other libraries, which where waiting for other libraries to be ported.
If Rails didn't support Ruby 1.9, I'd imagine the migration would have been slower.
If Rails didn't support Ruby 1.9, I'd imagine the migration would have been slower.
I've heard before that the Ruby community accepts new stuff much quicker than Python. You can make an argument for either attitude being more healthy. Part of it is because Python has become a core part of many Linux distributions, so it was tied to release cycles lasting years. Until quite recently, many packages were supporting Python 2.4, superseded in 2006, so they could be used on RHEL 5 servers.
It's actually fairly easy to write code that works with 2.6+ and 3.x, although you do still have to pay attention to it. Supporting 2.5 or below as well makes it rather harder.
It's actually fairly easy to write code that works with 2.6+ and 3.x, although you do still have to pay attention to it. Supporting 2.5 or below as well makes it rather harder.
There's huge difference between a point release 2.6 to 2.7 and full release 1.9 to 2.0
Most of Python's features are carefully crafted to not cause compatibility issues. 3.x is the major exception in many, many years.
Most of Python's features are carefully crafted to not cause compatibility issues. 3.x is the major exception in many, many years.
All code WAS written for 2.X, because 3 was either not around yet, under constantly changing flux (before release proper, and to a certain extent for a couple of versions) or the subsequent killer: Not enough libraries that you might depend on, worked in 3.0 yet - as it was written to be deliberately incompatible by removing legacy and old ways of doing things.
IIRC most of the big packages have finally moved over so it'll just become less of an issue over time.
IIRC most of the big packages have finally moved over so it'll just become less of an issue over time.
Is there a clear list anywhere of which major packages have and haven't moved over to Python 3 yet?
Edit: I found one here https://python3wos.appspot.com/ and another one here http://py3ksupport.appspot.com/
Looking forward to NLTK 3.0.
Edit: I found one here https://python3wos.appspot.com/ and another one here http://py3ksupport.appspot.com/
Looking forward to NLTK 3.0.
That's the one I watch ... it's a lot greener today than it was 2 years ago.
IIRC it became the "Wall of SuperPowers" (from its former Wall of Shame) — indicating more than 50% of tracked packages being P3 compatible — around mid-december 2012.
There's been a real change, even from 6 months ago when I last considered Python 3.0.
Apart from NLTK (A port is underway) everything I use currently has been ported which was a surprise. Time to start thinking about making the move I think.
Apart from NLTK (A port is underway) everything I use currently has been ported which was a surprise. Time to start thinking about making the move I think.
Guido put out a 5 year transition plan. I think we are coming to the tail end of that and now the move is happening to Python 3.
The best thing about python 3 is that it froze python 2. So right now we have this rock solidly stable python (2.7) and this weird new python (3.x) that not a lot of libraries work with. The point here is that they changed too much in python 3. Basic things like division changed, and many of these changes people disagreed with. People will still be starting projects with 2.7 in 5 years.
Around 40% of python.org Windows downloads last year were of Python 3[1]. This is for something that is less than 5 years old. What do you think the next 5 years will look like? It will be interesting to watch.
[1]: http://blog.briancurtin.com/posts/the-year-of-the-snake.html
[1]: http://blog.briancurtin.com/posts/the-year-of-the-snake.html
I don't think it's about "rejection" but a practical thing.
When starting a project you may need some 3rd party stuff (library, framework, etc) that doesn't support Python 3 (yet; for different reasons, sometimes the project is unmaintained, sometimes is a _huge_ project and Python 3 support is not ready, but I have yet to find a project that "rejects" Python 3).
Because 2.x (2.6 to 2.7) is available, it's not a big deal and you just use Python 2. Thanks to 2.7 (that includes several features from Python 3), finally moving to Python 3 shouldn't be a pain for most people, once all your requirements support Python 3.
When starting a project you may need some 3rd party stuff (library, framework, etc) that doesn't support Python 3 (yet; for different reasons, sometimes the project is unmaintained, sometimes is a _huge_ project and Python 3 support is not ready, but I have yet to find a project that "rejects" Python 3).
Because 2.x (2.6 to 2.7) is available, it's not a big deal and you just use Python 2. Thanks to 2.7 (that includes several features from Python 3), finally moving to Python 3 shouldn't be a pain for most people, once all your requirements support Python 3.
Can't shed any light on this, just wanted to add a 'me too'. As a perl veteran, I've been meaning to learn Python someday, and I figured I'd wait until the 'new' one became the standard, saving me from worrying about all the random incompatibilities. Maybe I'll only have to wait a few more years!
...makes me wonder if anyone had the opposite thought: A python programmer thinking of learning perl, but waiting until this newfangled perl 6 became the standard. I wonder who'll end up learning a new language first?
...makes me wonder if anyone had the opposite thought: A python programmer thinking of learning perl, but waiting until this newfangled perl 6 became the standard. I wonder who'll end up learning a new language first?
As a polyglot whose preferred scripting language is Python, 3 is the future, there will be no more backwards compatibility breakage in it (that was what going to v3 was for) and the only reason major dev houses still don't use it is because legacy 2.7 code isn't / won't be ported, and is backwards incompatible.
3.0 and its usage of pervasive unicode is an essential scripting language feature Python needed, and where Python2 was a syntactically pretty language with some big pitfalls and "wtfs?" Python3 corrects most of those and is all around better for it.
I do have to say, as someone who has looked at Perl, that is pretty much my stance - Perl 6 is a long time coming, I want it to hit before I try out Perl, same reason I waited until C++11 was market ready to jump into C++ (and now I'm writing qt apps all the time).
3.0 and its usage of pervasive unicode is an essential scripting language feature Python needed, and where Python2 was a syntactically pretty language with some big pitfalls and "wtfs?" Python3 corrects most of those and is all around better for it.
I do have to say, as someone who has looked at Perl, that is pretty much my stance - Perl 6 is a long time coming, I want it to hit before I try out Perl, same reason I waited until C++11 was market ready to jump into C++ (and now I'm writing qt apps all the time).
I think it's pretty safe to say at this point that Perl 6 will never really arrive. If a language doesn't have a practical implementation after well over a decade, it probably never will. This is even more true given that many of its features are now available, often in a better form, in many other mainstream languages.
At least Python 3 exists, and is usable for production-grade systems. Its adoption may not have been as quick as anticipated, but at least it does exist, and it is usable.
At least Python 3 exists, and is usable for production-grade systems. Its adoption may not have been as quick as anticipated, but at least it does exist, and it is usable.
If you want to learn Python, you should jump in. The differences between Python 2 and Python 3 are easy to pick up if you start with Python 2.
Tons of changes in 3 making it backwards incompatible + nearly 20 years of legacy Python libraries
It's not exactly rejected by the community - apart from a few vocal critics, I think most people are comfortable with it, and a lot of code does now support it.
It's just a slow movement, because there's a lot of legacy code out there. Also, many features up to 3.2 were backported to 2.7, so there was little incentive to make the switch. That's starting to change with 3.3.
It's just a slow movement, because there's a lot of legacy code out there. Also, many features up to 3.2 were backported to 2.7, so there was little incentive to make the switch. That's starting to change with 3.3.
Well, nothing new.
In Java a lot of code is still written for Java 6.
C++11 is not even fully supported from compilers
And Windows Xp still have more than 30% of market share.
Difference being that new versions of java, windows, c++ compilers work with the existing software.
That comes at a cost, though.
The implementations become more complex, which in turn can result in bugs, development delays, and so forth.
Additionally, it allows users of said technologies to continue to use techniques and functionality that have been observed to be outdated, bad or even harmful. You mention Java, which is a good example of how cruft can linger for many, many years, and continue to be used in that time.
The implementations become more complex, which in turn can result in bugs, development delays, and so forth.
Additionally, it allows users of said technologies to continue to use techniques and functionality that have been observed to be outdated, bad or even harmful. You mention Java, which is a good example of how cruft can linger for many, many years, and continue to be used in that time.
Not saying python 3 should have been compatible with 2. Just that this was not an apt comparison.
Is there Java 6 code that is not forward-compatible with Java 7?
Not easy to port pyGTK projects at all -- they didn't release until long after python 3's first release, and also combined the bump with a step to GTK3 and a different technology for the langauage bindings (gobject-introspections).
Sure, all those three new things are better, but each of them add up to porting a complex app.
Sure, all those three new things are better, but each of them add up to porting a complex app.
The best way is to get your application working with gobject-introspection and GTK3 on Python 2 first. Then it's very easy to port to Python 3.
Python 2 and Python 3 are effectively different languages in the way that VB and C# are different languages. Does it seem strange that some people code in VB when C# exists?
Python 3 isn't just a little bit incompatible in a few places, it has widespread incompatibilities and is therefore effectively a different language.
Python 3 isn't just a little bit incompatible in a few places, it has widespread incompatibilities and is therefore effectively a different language.
That's a pretty bad comparison. The differences between VB and C# are much more dramatic than the differences between Python 2 and Python 3.
I dunno, it is kind of reasonable. C# was designed with a different mindset, but the intents were the same - take a predecessor (VB / Python2) and make them more modern, fix the gotchas and mindfuck, and produce something more refined that isn't backwards compatible.
C# takes it much further, and iterates on syntax a lot more, but Python3's breakage from Python2's is comparable I feel, just not in nearly as extreme a case.
C# takes it much further, and iterates on syntax a lot more, but Python3's breakage from Python2's is comparable I feel, just not in nearly as extreme a case.
> Python3's breakage from Python2's is comparable I feel
They're not. You can create "single source" Python packages working on both Python 2 and Python 3. Good luck doing that with C# and VB.
They're not. You can create "single source" Python packages working on both Python 2 and Python 3. Good luck doing that with C# and VB.
It is trivial to write new projects that work on both Python 2.7 and 3.3. So trivial in fact that I did it without trying to several times.
The comparison may have made more sense with C and C++...
That would be an exaggeration too. More like K&R C vs ANSI C.
Been happily running Ubuntu 13.04 with Python 3.3 for a few weeks. Sure some packages will break, but it will initiate a real migration, and in the end Python3 will be the default Python. All in all, there's no way to make this transition without breaking stuff, it just needs to be done.
Arch has been using Python 3 for quite a long while, now.
However, any push that allows us to use 3.3 is a great thing. I've been reading the 3.3 docs and being like, neat feature! Then switching back to the 2.7 docs and realising I can't use it :(
However, any push that allows us to use 3.3 is a great thing. I've been reading the 3.3 docs and being like, neat feature! Then switching back to the 2.7 docs and realising I can't use it :(
Yep, after the feature freeze between 3.1 and 3.2, 3.3 was a significant jump forward.
Bha, I still believe that's a mistake. Breaking already existing and working tools for the sake of having python3. Thousands of scripts use "python" as default, instead of "python2". They will all break. The problem isn't when it's your own stuff. but mostly when you're using a automatically build system that use "python" somewhere. And then, that thing crashes because it's now expecting python2.. or that the 10 years old package would automatically be ported to python3.
As far as I'm concerned, I would have preferred Python to be Python2.x, and a new code name for Python3, i.e. Cobra.
As far as I'm concerned, I would have preferred Python to be Python2.x, and a new code name for Python3, i.e. Cobra.
I'm guessing that Debian, if they have not already done it, will start searching packages for ^#/usr/bin/python$, and filing bug reports for packages that match. So that should not be as much of a problem.
As for user-created scripts...
As for user-created scripts...
If you want to live in the past, don't upgrade.
If you want have your cake and eat it too, tough.
Everyone else, will upgrade and rejoice that Ubuntu isn't 10 years behind like another CrimsonCap distro.
If you want have your cake and eat it too, tough.
Everyone else, will upgrade and rejoice that Ubuntu isn't 10 years behind like another CrimsonCap distro.
The CrimsonCap distro has supported side-by-side Python2 and Python3 for awhile now. There is already a process underway to get the larger components migrated to Python3.
Sure the process isn't 100% complete, but it is hardly 10 years behind.
Sure the process isn't 100% complete, but it is hardly 10 years behind.
Python 3.3 was added to Fedora in August 2012. Source:
http://koji.fedoraproject.org/koji/packageinfo?packageID=978...
http://koji.fedoraproject.org/koji/packageinfo?packageID=978...
This is different than the Ubuntu proposal. Fedora is not yet shipping Python3 as the default Python interpreter [1].
[1] https://fedoraproject.org/wiki/Python3
[1] https://fedoraproject.org/wiki/Python3
Fedora is more of a bleeding-edge (or at least developer-focused) distro - they also ship with Ruby 1.9 instead of 1.8.
Fedora is certainly more bleeding-edge. Ruby 1.8 end of life is June 2013 however. It is unfortunate that most distros still ship with 1.8.7 as the default.
Ruby 2.0 actually, in Rawhide :-)
http://koji.fedoraproject.org/koji/packageinfo?packageID=125
http://koji.fedoraproject.org/koji/packageinfo?packageID=125
Interesting, until last year I used to use Ubuntu when I wanted a bleeding edge and lightweight OS for, say, working with new hardware. How things change.
In its lifetime Ubuntu has never been bleeding edge nor lightweight compared to many other distros. I'm an Arch user all the way but I still take other distros for a test drive every so often and it amazes me the crap distros bundle together in packages when so many things could be made to be optional dependencies. I guess it all depends on your standard for lightweight :).
Fedora has always been bleeding edge. In my experience, to the point of being unstable, at least when a version is new (Installed Fedora 15 the day it came out, segfaults galore).
Arch Linux all the way!
+1 for Fedora :)
Interesting. Maybe as the push to Python 3 gets more forced, more active-legacy code will be upgraded?
Let's hope so, there's got to be a tipping point.
Previous discussion: https://news.ycombinator.com/item?id=4486608
This was around Ubuntu 12.10, references Ubuntu wiki with nearly the same text back then.
This was around Ubuntu 12.10, references Ubuntu wiki with nearly the same text back then.
I think it's good that they "force" a little for devs to start using Python3.
When will perl6 become the standard perl?
Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked.
Python 2 is not being developed actively, aside from security updates, so it is permanently frozen at 2.7, with the intent of removing support entirely eventually (though not for a while).
It's not really a like comparison to compare the two.
Python 2 is not being developed actively, aside from security updates, so it is permanently frozen at 2.7, with the intent of removing support entirely eventually (though not for a while).
It's not really a like comparison to compare the two.
>Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked.
It wasn't always that way, however much certain luminaries try to retcon. Perl6 was originally intended to be, well, the next version of perl; it was only after the community's rejection that the decision to continue perl5 happened. It's not beyond the realms of possibility that the same thing could happen to python (though I certainly hope not, and stories like this suggest we're reaching the tipping point).
It wasn't always that way, however much certain luminaries try to retcon. Perl6 was originally intended to be, well, the next version of perl; it was only after the community's rejection that the decision to continue perl5 happened. It's not beyond the realms of possibility that the same thing could happen to python (though I certainly hope not, and stories like this suggest we're reaching the tipping point).
it was only after the community's rejection that the decision to continue perl5 happened.
The lack of any usable Perl 6 implementation by the time of Perl 5.12 did more to promote the continuation of Perl 5 as its own project than any specific rejection of Perl 6. When the plan was for Perl 6 to replace Perl 5, the idea that Perl 5.12 would migrate to Parrot as a VM so that Perl 5 and Perl 6 code could run in the same process.
The lack of any usable Perl 6 implementation by the time of Perl 5.12 did more to promote the continuation of Perl 5 as its own project than any specific rejection of Perl 6. When the plan was for Perl 6 to replace Perl 5, the idea that Perl 5.12 would migrate to Parrot as a VM so that Perl 5 and Perl 6 code could run in the same process.
From what I've seen, the difference between Perl 5 and 6 is much greater than the difference between Python 2 and 3. For this reason, I have very little hope for Perl 6.
There's always Linux Mint[1].
[1] http://www.linuxmint.com/about.php
[1] http://www.linuxmint.com/about.php
Ubuntu also thinks Unity is a good idea.
I like Python, but keeping both 2 and 3 alive for so long has caused problems that make it hard to justify for serious projects. What will your boss decide when half his developers say that the two branch is right for a task and half say the three branch should be used? He'll pick another language.
I'm not sure I'm willing to trust Ubuntu to decide this for me ... they also thought Unity was in my best interest, and foisted the Amazon store upon my desktop. Good luck Ubuntu ... I'm outta here.
I'm not sure I'm willing to trust Ubuntu to decide this for me ... they also thought Unity was in my best interest, and foisted the Amazon store upon my desktop. Good luck Ubuntu ... I'm outta here.
"I like Python, but keeping both 2 and 3 alive for so long has caused problems that make it hard to justify for serious projects."
Sounds like a strawman arguement to me. People in the community are aware of the different versions of Python and know how to deal with it. This "issue" hasn't affected Google, NASA or the millions of developers/users that utilize Python to the extent that they are in crisis mode. You can run multiple versions of Python on the same system, there are utilities that make this manageable.
What other language is "your" boss going to pick that you can't find issues with? Does he actually understand the technical details and history of said language? You can find all sorts of issues with any programming language, all of them are "Hopper complete."
Sounds like a strawman arguement to me. People in the community are aware of the different versions of Python and know how to deal with it. This "issue" hasn't affected Google, NASA or the millions of developers/users that utilize Python to the extent that they are in crisis mode. You can run multiple versions of Python on the same system, there are utilities that make this manageable.
What other language is "your" boss going to pick that you can't find issues with? Does he actually understand the technical details and history of said language? You can find all sorts of issues with any programming language, all of them are "Hopper complete."
Having Python 3 installed does not mean that you cannot install and use Python 2 if you wish to; if you upgrade to 13.04, your copy of Python 2.7 will remain installed, and for other users it's still in the package repositories (if it's not already installed—I'm not certain). But pushing Python 3 forwards makes sense. It is a better language and is the way forward. Having a major operating system promoting it as the primary distribution will be very helpful in continuing Python 3 adoption. I don't agree with the rest of that paragraph, either.
Then to your second paragraph—I actively enjoy using Unity. And as for the Amazon things, I see the direction they're headed in and approve of it, though the Amazon part alone is of no use to me. Canonical is making good things; sure, in the meantime there have been some things which haven't worked quite so well (e.g. I didn't find Unity usable for the first two releases) but their direction is solid, in my opinion.
Then to your second paragraph—I actively enjoy using Unity. And as for the Amazon things, I see the direction they're headed in and approve of it, though the Amazon part alone is of no use to me. Canonical is making good things; sure, in the meantime there have been some things which haven't worked quite so well (e.g. I didn't find Unity usable for the first two releases) but their direction is solid, in my opinion.
I think the way the Python community handled this change is really mature compared to several other communities who've been through such change. They've done great work in making sure one single codebase can support 2.6, 2.7 and 3.2/3, Django does this.
Teams using Python to develop, in the present state, mostly base their decisions to chose py2 or py3 based on the maturity of the libraries (py3 ones) they are gonna use. Ubuntu devs are using good judgment here, they are first moving code they use for the OS from 2 to 3 and switch the default python package version. But py2 should be available to any package which specifies it as a dependency. This should be nearly invisible to a normal user. This also gives the much needed push for Py3 adoption.
Teams using Python to develop, in the present state, mostly base their decisions to chose py2 or py3 based on the maturity of the libraries (py3 ones) they are gonna use. Ubuntu devs are using good judgment here, they are first moving code they use for the OS from 2 to 3 and switch the default python package version. But py2 should be available to any package which specifies it as a dependency. This should be nearly invisible to a normal user. This also gives the much needed push for Py3 adoption.
Python 2 and 3 are in most practical senses two very closely related, but different, languages. So your scenario is not very different from the two groups of developers suggesting Python and Ruby.
By the way, assuming either language satisfies the external requirements for the project, any half-way competent boss would say "Figure it out. Bring me your decision by the end of the day(/week/whatever). KTHXBYE."
By the way, assuming either language satisfies the external requirements for the project, any half-way competent boss would say "Figure it out. Bring me your decision by the end of the day(/week/whatever). KTHXBYE."
> Python 2 and 3 are in most practical senses two very closely related, but different, languages.
They're so closely related you can write code compatible with both (and that's the path many — if not most — libraries are taking)
They're so closely related you can write code compatible with both (and that's the path many — if not most — libraries are taking)
ubuntu isn't deciding anything for you. both are available as packages. and the decision to introduce python 3 wasn't made by them anyway.
for new projects where i control deployment i use python 3 (these days, the support is there - in fact in at least one case i am using a python 3 only lib). for maintenance or projects where the client has existing systems, i use whatever is most appropriate.
i am a professional. i get the job done. what more is there to say? oh, yeah, running round throwing a hissy fit for internet points.
for new projects where i control deployment i use python 3 (these days, the support is there - in fact in at least one case i am using a python 3 only lib). for maintenance or projects where the client has existing systems, i use whatever is most appropriate.
i am a professional. i get the job done. what more is there to say? oh, yeah, running round throwing a hissy fit for internet points.
Arch has python2 and python3 with the /usr/bin/python symlinked to python3. Anything that depends on 2 uses, well, 2.
It is the bane of backwards compatibility breakage in language semantics. I sometimes think maybe Python3 should have been another language, but it is understandable when there is so little syntactic breakage between the two you want to try to tie them together than diverge on the unicode issue.
It is the bane of backwards compatibility breakage in language semantics. I sometimes think maybe Python3 should have been another language, but it is understandable when there is so little syntactic breakage between the two you want to try to tie them together than diverge on the unicode issue.
Arch made the mistake of symlinking python to python3, that's all.
Has anyone that uses Arch called it a mistake?
Yes, tons and tons of confused people popped in on all python IRC channels. Arch devs seem to think their users know everything, but there is enough evidence that not every single arch user reads all the details.
It is intentional. From the Archwiki [1]:
> Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system.
[1] - https://wiki.archlinux.org/index.php/The_Arch_Way
> Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system.
[1] - https://wiki.archlinux.org/index.php/The_Arch_Way
I would like to amend it with "all users are required to sign a paper that says they won't bother 3rd party developers before completely understanding the arch way". Seriously, just because you think your software is used in the way X, it doesn't mean it's not used in the way Y too and maybe you should consider thinking about those people too.
If you don't know enough to maintain your system, you shouldn't use Arch...
yes. using "python3" to run Python 3 would have been possible without breaking existing scripts. Also you can switch your entire infrastrucutre to use "python3" without breaking anything. I don't say switching to Python 3 was to early or the worst thing in the world. I'm just not sure if changing the "python" symlink to "python3" was great.
[deleted]
It was confusing for a while and broke some stuff. I haven't personally experienced problems in a while though. Mistake? No. It fits in with Arch's personality and made sense. It'd have been a mistake for Ubuntu to do it at the same time ofc!
I started to specify my python preference in my #! (ie #!/usr/bin/python3) in my own programs. If everyone did this the move would be much easier.
I started to specify my python preference in my #! (ie #!/usr/bin/python3) in my own programs. If everyone did this the move would be much easier.
I recommend using #!/usr/bin/env python3 as the shebang for portability[1] reasons if you intend to distribute the programs.
[1] https://en.wikipedia.org/wiki/Shebang_%28Unix%29#Portability
[1] https://en.wikipedia.org/wiki/Shebang_%28Unix%29#Portability
Thanks. Shall switch to using that.
As a full time Arch user the change was a little annoying at first but now I am perfectly happy using Python3 as the default because all my Python shell scripts and system installed packages work under Python3. I can simply work in a Python2 virtualenv when I need python2.
Agreed, I use virtualenv if I'm hacking up a website at home.
mkvirtualenv <name> --python=pythonx.y --no-site-packages
As of version 1.7 (2011), --no-site-packages is default behavior.
I still specify it every time anyway, but thought it'd be worth mentioning. :)
The --python switch is really great, though, particularly now that 3 is getting distro traction and most of us who work in Python are likely maintaining a lot of 2.x projects. Thanks!
I still specify it every time anyway, but thought it'd be worth mentioning. :)
The --python switch is really great, though, particularly now that 3 is getting distro traction and most of us who work in Python are likely maintaining a lot of 2.x projects. Thanks!
Yes, I use Arch, and I think it was a mistake. Symlinking python to python3 breaks the assumption of virtually every Python dev out there; if you maintain an Arch package that has Python components, you usually have to sed replace the python shebangs with python2. Totally goes against Arch's normal "keep it simple" philosophy.
But, isn't it compatible with PEP 394[1]? As I see it, the mistake is to assume the `python`command links to python2.
The PEP itself should maybe point that out and not say that `python`SHOULD refer to python2 and at the same time MAY refer to python3. It only helps to the confussion.
[1]: http://www.python.org/dev/peps/pep-0394/
The PEP itself should maybe point that out and not say that `python`SHOULD refer to python2 and at the same time MAY refer to python3. It only helps to the confussion.
[1]: http://www.python.org/dev/peps/pep-0394/
I've worked in environments where classic ASP, .NET 1.0, .NET 3.5 and 4.0 are all in production, some on the same server. I imagine there are similar tales regarding production environments for Java and Ruby etc. If you cannot run different versions simultaneously you have a problem. Thankfully you can.
I hope this is some sort of development/project manager rather than a business manager, otherwise they shouldn't be choosing the language at all!
[deleted]
Get a different boss, that one sucks.