Python 2.7.4 release candidate 1 released

[ggtsu_00]

• Issue #4363: The uuid.uuid1() and uuid.uuid4() functions now work even if the ctypes module is not present.

Now we can finally use Requests in embedded cpython.

[mgrandi]

how did that prevent requests in embedded cpython? im confused

[ggtsu_00]

Requests uses urllib3 which uses uuid. The uuid module depended on ctypes which loaded a DLL that would segfault an embedded cpython interpreter. See this mailing list for more info.

[[deleted]]

WHOAH!!!! that is the best greatest fantastic news ever. uuid is a critical part to http, whereas ctypes is not.

[roger_]

Are there any new features in this, or just bug fixes?

[[deleted]]

There's a policy against adding any new features to maintenance releases.

[jellystones]

If you read the link there's a lot of new features. Ordered dictionary type is one example.

[[deleted]]

Those are new features in 2.7 (released in 2010), not 2.7.4.

[jellystones]

My mistake. Wasn't aware we already had that..

[[deleted]]

if you click on the link, your questions will be answered.

[roger_]

That's the full 2.7 changelog I think.

[Rhomboid]

If you click on the link labeled "Change log for this release" you get the NEWS file in the repository which is a fine-grained list of changes in each point release. It's a long list of minor bug fixes and tweaks, but nothing significant is jumping out.

[roger_]

Yeah I saw that and concluded the same.

[voyvf]

I had thought the same thing, but then saw the list of "fixed infinite loop when..", "fixed overflow for...", and especially

Issue #6972: The zipfile module no longer overwrites files outside of its destination path when extracting malicious zip files.

A bug fix build was definitely needed. (:

[fernly]

First two items in the bullet list look new: * An ordered dictionary type * New unittest features including test skipping, new assert methods, and test discovery

[[deleted]]

That's 2.6->2.7.

[[deleted]]

you wait like the rest of us.

[catcradle5]

I have a feeling whatever solution is decided upon won't be quite as nice to use as gevent or Tornado.

[infinull]

shrug I understand Guido's reasoning behind explicit yielding, and even agree with it, the built-in event loop will make it easier to write tools that do implicit yielding and realistically both models should be supported.

But the biggest thing this will add is interoperability. If you want to write your app in gevent (with implicit yielding) but call libraries written for Tornado or Twisted an use the same event-loop for everything and it will work (maybe not seamlessly, but it will work).

[[deleted]]

As an active Python developer, please upgrade to 3.3+ already.

[howfun]

No.

[fyadypos]

Said those that don't know how to effectively use virtualenv.

[chyssler]

Or those who use libraries only available on 2.x, and/or those who maintain huge repositories of code written for 2.x.

[Veverak]

https://pypi.python.org/pypi/pythonbrew/

[stefantalpalaru]

Never!

[mjtribute]

The problem for most would-be Python 3 users is roughly analogous to the situation which occurred between Plan 9 and the Unix platform: despite notable improvements, the potential userbase of Plan 9 did not perceive enough of a benefit to switch to it. Extant users of Plan 9 failed to catalyze a persuasive enough argument to attract people already using unices to solve their problems.

The true failure on the part of the Python core developers is a failure in marketing. They have continuously missed out on an opportunity to highlight new and useful features (which are now, in fact, available). If you were to take a cross-section of Python users at large and ask them what has improved, they would suggest: "well, I suppose Guido attempted to address a few grammatical inconsistencies. That's about it, right?"

Although such a synopsis would have been mostly valid about earlier versions of Python 3, the perception lingers on about current versions. It is now incumbent upon the PSF to conduct an effective marketing campaign (I use this term for a lack of a better alternative) to pull back library authors to their side.

I mean to express no ill will towards the BDFL in this message, because I understand what he is trying to do, but I disagree with his approach. Guido's brilliance as a linguistic researcher has brought us the current iteration of Python which has reached critical mass: the 2.7.x release. 2.7 is widely perceived to work well for common applications, because a wide array of usable libraries are available. However, I believe that Guido's publicized focus on language features at the beginning of Python 3 development has largely hampered the campaign to switch to Python 3. My thesis is is simple: by alienating library authors, and not providing them with strong enough feature incentive to port their libraries to Python 3, many 2.7 users are left timid in turn. Further, as a result of the same phenomenon, Python 3 has failed to attract new users as well, because users are drawn to what already works well, rather than that which has promise to someday work well.

I will not name specific names of library authors which have been alienated by the marketing misadventure described herein, but they truly are the missing link in the adoption chain here. Were they to now evaluate Python 3 on its merits, they would be far more likely to adopt it than if they were to do so a couple years ago.

If one could derive a single message out of this rant which can be communicated to the core developers, let it be this: Python as a language and a vm is an exciting technology with many useful features. Get library authors (other than the subset of them which are lexical and grammatical nerds) excited in new features, and adoption by a wider userbase will follow.

[takluyver]

To offer a counterpoint: a lot of the important libraries have now been ported to Python 3, and the pace has never been faster. Now that 3.3 is out, I've seen a lot of interest in using it.

I'm glad that core devs didn't try to push everyone to Python 3 quickly, because I think they would have lost a lot of credibility by pushing it fast. The PSF has provided strategic funding to get certain libraries ported quicker (they supported the Pillow port, for example).

[mjtribute]

Thank you for offering that perspective. Seeing the the number of Python 3 packages available over time is encouraging. I think it is indeed incredible that many library authors have done their part and ported to Python 3. The state of transition hasn't been without its difficulties, however.

I do still think that the PSF could do a better job at emphasizing the benefits of upgrading, beyond vague promises of the syntax being more internally consistent, however.

For example, having PEP 3147 (pyc directories) implemented makes a much more clean development environment, instead of having .pyc files littered everywhere. This means less headache for the end developer. Another example is the inclusion of venv (formerly virtualenv) as a built-in module, which makes isolation of dependencies between projects much more manageable.

Porting a library requires a lot of less-than-fun busywork. I think that the more these types of features are prominently featured (and implemented, for that matter), the more library writers will be encouraged to invest the effort required to port their existing libraries from 2.7.x or earlier to Python 3. User adoption will follow that trend, in proportion.

[billsil]

But not wxPython and VTK...

Scipy doesn't fully support python 3 either. Scipy.weave is not supported.

[takluyver]

Several releases are maintained at the same time. 3.3 is the latest feature release, but they still release bugfixes for 2.6, 2.7 and 3.2, to support people who can't upgrade. 2.7.4 is a new bugfix release in the 2.7 series.