Python 3.2 Released
python.org
python.org
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.
http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...
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.
I seem to recall part of the attraction of Mercurial was that it's written in Python.
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.
Yep, Windows wasn't well supported so it was a pain to setup, and it was very very slow.
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.
How far along are the libraries and the documentation/tutorials?
http://python3wos.appspot.com/
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.
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."
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?
The ability to safely convert string representations of data structures into the structures themselves seems pretty sweet, too: http://docs.python.org/dev/whatsnew/3.2.html#ast
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.
from what i understand, python 3 has a lot of changes to the interface which makes porting not so straightforward.
* 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)
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.
Indeed, this proposal is not the common way. But why is that so uncommon?
Why is using 3to2 not recommended? In how far do you limit yourself if you develop in Python3 and use 3to2 at release time?
Rather, I'd guess that developing in Python2 and using 2to3 is limiting, because that limits you to the language features of Python2.
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.
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.
Why do so many projects prefer 2) over 3)?
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.
What's the method you'd recommend to solve this issue?
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
The equivalent to "print 'hello'" is not "sys.stdout.write('hello')" but "sys.stdout.write('hello\n')".
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).
It shouldn't be too long though. I'd bet that in 6 months 1 or 2 projects will already be functional.
http://docs.python.org/dev/whatsnew/3.2.html#multi-threading
http://mail.python.org/pipermail/python-dev/2009-October/093...
2. Because some of the Python 3.2 fixes and improvements are needed for library migrations.
We're still pretty locked into 2.6. I'd love to move to 3.2 but it would break EVERYTHING!!!!(! added for emphasis!)
Maybe in ~10 years, everyone will be using 3.2, I know I can't wait! :D
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
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).
(There's some variation in output, thanks to Unicode, but it's a variation that this project could live with.)