One interesting thing from the "What's new in 3.2?"[1] page:
After the 3.2 release, there are plans to switch to Mercurial as the primary repository. This distributed version control system should make it easier for members of the community to create and share external changesets. See PEP 385 for details.
The reasoning was a bit odd (right at the end). For example:
> First, git's Windows support is the weakest out of the three DVCSs being considered...
True... kinda. In my experience it sucks unless you use Cygwin. I'm not sure how much that matters however. There is excellent tool support for Git on Windows, namely Jetbrains' IntelliJ (with the Python module) or PyCharm. Version control integration is one of those things that Jetbrains excels at with nobody else really coming close.
But, then again, the vim/Emacs Python crowd (over IDEs) are still pretty strong.
I'd be interested to know what the "core developers" disliked about Git too.
The git community seemed a little inaccessible at the time (though that might have just been because they were very smart and very busy). Documentation was couched in graph theory, and Windows support wasn't a priority.
The attitude seemed to be "git is a powerful command line tool for manipulating a graph-theory-based file system, which uses cryptographic hashes to identify nodes. Use it with care, as you don't want to do a hard reset on the index when you really wanted a semi-soft reset -- that could be bad".
Mercurial sold itself as a distributed version control system.
Github has done a lot to bring git into the mainstream (I'm switching on account of them), but it's taken a long time for git to become newbie friendly.
> I'd be interested to know what the "core developers" disliked about Git too.
I spoke to Brett Cannon --basically the guy who chose Mercurial-- not long after the choice was made. Apparently the most important factor was that Mercurial was the favorite choice in the Python community. That's probably because Mercurial is written in Python, and was used by a lot of Python projects.
Also Git didn't work very well under Windows at the time if I remember correctly.
Library support is so-so. It's actually surprising how many libs out there could be have an initial port completed in an hour. I would encourage anyone to look at a dependency of theirs, run it through 2to3, then see what it does. Sometimes it's as easy as making a few fixes and it runs fine.
Obviously there are complicated projects out there where this isn't true, but I don't think there needs to be any distinction between amateur and professional porting levels. Just go for it. As I said in another post, taken from the movie Field of Dreams: "if you build it, they will come."
For most people, the docs/tutorials aren't that big a deal because the differences aren't that great. If you're just beginning I would say read up on the differences between 2.x and 3 so you're aware of it but wait until the majority of projects are ported.
Use 3.x if you can. Use 2.x if a library you require hasn't been ported (or better, help them with it, although that's probably not a job for a self-described amateur).
The problem with that plan is that you might not need a 2.x library right now, but when you need one tomorrow you're going to be really sad. In essence, Python 3.x is a brand new niche/minority language, and should be treated as such by people thinking of using it.
Start now! The sooner we get the ball rolling the better. Libraries are waiting on devs who are waiting on libraries. There are definitely enough compatible libraries for a brand new project. It's when you have to port old projects that things get tricky.
> I don't have much experience in that area, so I can't judge if it's as cool as I think it is. Will anyone help me out?
It is quite cool. Strictly speaking, it doesn't have to be in standard library, but Python has always had a batteries-included mentality anyway. Besides, it offers a more sane way to parallelize execution than mutexes, and that mentality should be encouraged.
The entire java.util.concurrent.* library is quite good, actually. No shame in porting it.
If you can do it based on your dependencies and your time, I don't see why you wouldn't, given the following:
* It's easiest to do when you don't have a wide range of versions to support. If you want to support 2.6, 2.7, and 3.x, writing a single codebase that supports both versions is not really that hard. It gets harder the wider your range gets, but it's not impossible. For example: if you need 2.4-3.x then you don't have the `as` statement, so exception handling is tricker across all versions.
* Run your code through `2to3`, it probably works. A lot of people are surprised at how close they are to working under 3.x, enough that there are some projects which successfully keep the codebase under 2.x and port to 3 via 2to3 only at release time.
* You need good test coverage to have a successful port. Period. This is one of the barriers a lot of people see to porting -- they need to stop and build up tests before they can even think about moving forward.
The initial effort in porting turns a lot of people off, as does the ongoing maintenance, especially when there's no audience for it, but as with the movie Field of Dreams: "if you build it, they will come". We need more projects to be proactive and spend a little time if they can...enough that the PSF will fund porting sprints (see www.pythonsprints.com)
No offense intended, but I think that using `2to3` at release time is exactly the wrong way around. I'd rather like to have something like `3to2`.
The idea is to use `2to3` only initially to move your code to Python3. From then on, develop your code in Python3 – that's what "we all" want, don't we? At release time, use `3to2` to also provide a Python2 version.
It is definitely not the recommended nor the common way of doing it. Many projects use 2to3 at release time (which hopefully include testing time) to support python 3.x. Numpy and scipy do exactly that for example, and we won't limit ourselves to python 3.x anytime soon.
The context I was speaking is projects who still want to support 2.x, which is what most projects want.
Obviously, if you don't care about supporting 2.x at all once the conversion is done, modifying the output and using the output as your reference source is fine.
> The context I was speaking is projects who still want to support 2.x
This is also what I was speaking about. And to reach that goal, you have generally 3 options:
1) write code that works with Python2 as well as Python3
2) maintain your code in Python2 and use 2to3 on release time
3) maintain your code in Python3 and use 3to2 on release time
Given you don't want to do 1) for whatever reason, my argument is that 3) seems to be the preferable solution. It allows you to use our loved Python3 right now, while still supporting Python2.
However, "in the wild" we see 2) way more often, and I don't understand why this is the case.
Because for many contributors, python 3 is not usable as there are so few packages available. And on the other hand, the improvements from python 2 -> 3 are really minor.
"No offense intended, but I think that using `2to3` at release time is exactly the wrong way around."
It's not a method I'd recommend, but I was just pointing out that some people had such success with 2to3 that it's reliable enough for them to provide releases based on it. I would guess that this isn't their eternal 3.x support plan, but may give some confidence in projects that 3.x is only a 2to3 run away.
As the name implies, 2to3 gets you from 2 to 3, but it leaves 2 behind entirely which isn't something most people are ready to do (myself included). I'm a fan of trying to run a single codebase that supports 2 and 3, so the method I like is to run 2to3 up front but don't immediately apply the patch it generates. Use that patch as a guide for the area that needs attention, then manually apply changes where the patch points you to and ensure they will work for both versions.
For example, 2to3 changes "print 'hello'" to "print('hello')", but if you need to support 2.4-3.2, you'll need something like "sys.stdout.write('hello')". Even supporting 2.7-3.2, 2to3 will make the same suggestion, but I would add "from future import print_function" at the top in order to function across both versions.
The same goes for imports. "import ConfigParser" will be changed to "import configparser", but what in my case I want...
try:
import configparser
except ImportError:
import ConfigParser as configparser
I've never had much difficulty in porting using this method. It's more work than creating a 3.x branch for your product and just letting 2to3 apply its changes there, but then you have the ongoing maintenance of two separate branches.
Is it your own project? If so, I'd base the decision on libraries you rely on in your code. If the libs can do 2 or 3, then go ahead and migrate to 3. If they only do 2, stick with what you have. Some libraries may never make the move, other coders will write libraries for 3 when they have the need and can't find a suitable 3 lib to use.
i agree with the above response, it seems like a lot of python libraries still haven't made the shift to supporting python 3.x. it reminds me of the time when ms windows went 64 bit and vista, a lot of the drivers just didn't work and to many extents still don't work.
from what i understand, python 3 has a lot of changes to the interface which makes porting not so straightforward.
If that's a project for yourself, maybe you can use python 3.x if you don't depend on libraries which need python 2.x.
If that's project you intend on distributing, then please support python 2.x. First, given that python 3.x has few killer features compared to 2.x, it won't bring you much, frankly. Then using python 3.x in production is near impossible ATM for many people. Third, it is easy to forget that other people may have other dependencies than you, which means that even though you don't depend on python3, other people may want to use your package in an environment where python 3.x is not possible.
Note that supporting python 2.x may mean different things. It could be that you restrict to the subset common to 2 and 3: while painful, it is possible, and some known packages have done it (ply I believe, for example). It could be that you write your code such as 3to2 can produce a workable solution (I have never used it, so cannot comment on it).
Since the GIL is still there, I doubt that any drastic improvement has been achieved. Basically, instead of getting significantly worse performance when using threads, you will get close to single-threaded performance. Not better performance.
If I could easily update python so that yum still worked fine on centos I would definitely start using python3. As it is I'm still stuck with python2.4 for a majority of the stuff I write.
You can always install other versions of Python. I have never used the distro's version of Python. I have always built my preferred version from source. It's trivial.
Python 2.6 as a language is "good enough", for whatever meaning of that phrase. What would be exciting in Python development is the PyPy + LLVM (and the short stretch of the Unladen Swallow project) backend, and applying the modern optimization techniques for compiling dynamic code into efficient machine code. There is IronPython etc. but the platform is different from CPython's.
Who are "they"? I imagine the overlap between people working on the core python language and people maintaining popular third party libraries is pretty small. Or are you suggesting that Van Rossum and friends drop python development for a year and start hacking on NLTK and PIL instead?
1. Because it's not really their job, the core team ports their own libraries and (as far as I know) are always available to help others do so for theirs.
2. Because some of the Python 3.2 fixes and improvements are needed for library migrations.
I have read it, but evidently I'm misunderstanding something, either in the parent post or the PEP. Would you care to be a bit more explicit in pointing it out?
Remember the break from Numeric to numpy / scipy.core? Matplotlib managed to port OK, which was not small feat.
The fact that you could do lots of try/excepts helped:
try:
import Numeric as np
newaxis = np.NewAxis
...
else:
import numpy as np
newaxis = np.newaxis
I think that was about 10 years ago. It took ~5 years to gain acceptance. Python 3 is < 2.5 years old (3.0 final was Dec, 2008), so it's not doing that badly.
The big problem seems to be whether both versions can run off the same source base, even with some voodoo (i.e. defining print functions, etc).
Agreed. Once I made the mental decision to stop supporting Python < 2.7, I ended up with at least one code base that runs under both 2.7 and 3.2. Switching to print() ("from __future__ import print_function"), basing error objects on Exception instead of StandardError, and wrapping loops over .items() or .keys() with list() were the only significant changes, and all of the above are available in 2.7. Runtime for a typical job was marginally slower (8-11%) in my testing with 2.7 vs. 3.1; more than acceptable for me.
(There's some variation in output, thanks to Unicode, but it's a variation that this project could live with.)
After the 3.2 release, there are plans to switch to Mercurial as the primary repository. This distributed version control system should make it easier for members of the community to create and share external changesets. See PEP 385 for details.
1- http://docs.python.org/dev/whatsnew/3.2.html