It's not that curious, Georg Brandl is release manager for the 3.* releases, Benjamin Peterson is release manager for the 2.7.4 release and they live in different timezones.
They probably tried calculating the day of the week using Python's truly painful timezone conversion tools. I'm not convinced it wouldn't tell you that a single date lay on both Saturday and Sunday.
It annoys me how this release was added to the 2.7.x line when it probably should have been 2.8 given all the changes and feature additions. Freezing the 2.x line means not making huge changes to it. Otherwise, it probably shouldn't have been frozen.
You should check the changelog, they're still adding functionality by stretching the definition of 'bug fix'.. 2.x development is unlikely to freeze any time soon. I certainly have no intention of moving to 3.x, it would be the most pointless upheaval ever. I'd sooner fork 2.x and maintain it myself.
It is pretty clear that the current users of Python 2.x have voted that they don't want to move to Python 3. Some language changes and lots of library changes. Everything has to be ported to upgrade.
"current users of Python 2.x" is too broad to be accurate; anyways, it will be interesting to watch how motivated the holdouts will be when the 2015 deadline[1] approaches.
I wouldn't say that at all. My company had voted that we weren't ready to move to Python 3 yet. It's looking very likely that we'll be making the leap for new development starting in the next week or so.
Python 2 is a beautiful, wonderful language. Python 3 is even better and there are very few reasons not to adopt it now.
As a current user of Python 2.x, I can't wait to make the jump to 3, and have already done so for a few of my personal projects. It's probably best not to generalize too much.
I started a new Django project at work using Python 3. Fun part is it gives me an excuse to help some of the various Django libs to move to 3 (if the authors are still around to take pull requests :/).
The core team are already planning how to interact with the eventual community maintained fork. It's not a question of if but when.
The only concrete attraction of 3 for me is the Unicode improvement, and even that isn't exactly compelling. 3 is practically a new language designed to solve problems I've almost never encountered. Perhaps when someone comes up with a meaningful use of annotations or a workaround for e.g. the functionality lost by the cmp removal, I might change my mind
Did you even read my other comment? Enhancing the (10 year old plus) buffer interface with functionality it has never supported does not constitute a bug fix
Surely, even with maintenance releases, there are exceptions where developers decide to break the rules a bit? Check the justification for this specific one: http://bugs.python.org/issue10211.
After years, better integration between the old and new buffer interfaces was finally sneaked in as a bug fix. You can now call `memoryview(some_buffer)` and it'll DTRT. The whole buffers situation is a depressing mess.
Basically, Python has the "buffer" object which is a 0-copy view of some memory area (lets an object expose itself as a bytes array of sorts). It's always been plagued with a number of issues.
In Python 3, `buffer` was removed and replaced with `memoryview`, which was backported to Python 2.7. But in said Python 2.7, `buffer` and `memoryview` both exist and fill very similar need so e.g. older libraries will likely return a buffer which newer code will want to use as a memoryview. No such luck, they're not compatible.
2.7.4 fixes that so you can get a memoryview from a buffer.
I too would like more details on this. 2.7.3 already had memoryview objects IIRC, though I found them almost as frustrating to work with as the 2.6.x world of not having them. What really changed in 2.7.4?
>>> buffer("foo")
<read-only buffer for 0x1005a5ee0, size -1, offset 0 at 0x10054f270>
and a view of a string:
>>> memoryview("foo")
<memory at 0x100574d60>
but when you get this unhelpful and really stupid result:
>>> memoryview(buffer("foo"))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface
2.7.4 fixed this so it actually works and you can get a memoryview out of an old buffer.
The word was "incredible", and I was actually not referring to 2.7 specifically, but to maintenance releases in general (3.3.1 also got hundreds of bugfixes).
It seems weird that large features like dictionary comprehensions and syntax changes like set literals are making it int0 2.7.x, but I'm not complaining - most of my projects are stuck on 2.7 due to deployment environment or library limitations and I'd love to be able to use these features.
49 comments
[ 2.6 ms ] story [ 103 ms ] threadPython 3.2.4 and Python 3.3.1 final have been released. Published: Sun, 6 April 2013, 22:30 +0200
Python 2.7.4 has been released. Published: Sat, 6 April 2013, 11:00 -0500
[1]: http://mail.python.org/pipermail/python-dev/2013-April/12516...
Python 2 is a beautiful, wonderful language. Python 3 is even better and there are very few reasons not to adopt it now.
"Python 3.0 final was released on December 3rd, 2008"
The only concrete attraction of 3 for me is the Unicode improvement, and even that isn't exactly compelling. 3 is practically a new language designed to solve problems I've almost never encountered. Perhaps when someone comes up with a meaningful use of annotations or a workaround for e.g. the functionality lost by the cmp removal, I might change my mind
Can you please elaborate? All entries in the changelog start with "Fix" or "update", etc. What new functionality has been added, according to you?
"We'll stomp our feet and make a big deal about how there won't be a 2.8, then put all the 2.8 like changes in 2.7.x"
Changes are here: http://hg.python.org/cpython/file/9290822f2280/Misc/NEWS
Basically, Python has the "buffer" object which is a 0-copy view of some memory area (lets an object expose itself as a bytes array of sorts). It's always been plagued with a number of issues.
In Python 3, `buffer` was removed and replaced with `memoryview`, which was backported to Python 2.7. But in said Python 2.7, `buffer` and `memoryview` both exist and fill very similar need so e.g. older libraries will likely return a buffer which newer code will want to use as a memoryview. No such luck, they're not compatible.
2.7.4 fixes that so you can get a memoryview from a buffer.
And you can create a memoryview which is the "new" and more flexible buffer interface: http://docs.python.org/2/library/stdtypes.html#typememoryvie...
You can get a buffer of a string:
and a view of a string: but when you get this unhelpful and really stupid result: 2.7.4 fixed this so it actually works and you can get a memoryview out of an old buffer.There aren't any libraries I know of that work in 2.7 but not 2.7.x
They made it into 2.7.0, that happened 3 years ago...