LWN.net Logo

Proposal: Moratorium on Python language changes

Proposal: Moratorium on Python language changes

Posted Oct 21, 2009 22:29 UTC (Wed) by hazmat (subscriber, #668)
In reply to: Proposal: Moratorium on Python language changes by sergey
Parent article: Proposal: Moratorium on Python language changes

I've used python for 12 years.. with a lot of different organizations.. fact of the matter afaics, is that
most organizations still just use the feature set from python 2.3/2.4 core, alot of the new features
are infrequently used. decorators (func and class) saw large uptake, but i only see a handful of
references to context managers (with). i can't say i've seen a single conditional expression. so i take
think guido's moratorium has good value.. given that the users adopting new features seem to be a
small percentage of the overall user base.

anyways.. i'm just as happy to see work on additional language implementations, as well speed
improvements ( unladen-swallow for example ). if a moratorium can help bring that forward,
sounds good to me.


(Log in to post comments)

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 16:13 UTC (Thu) by nevyn (subscriber, #33129) [Link]

fact of the matter afaics, is that most organizations still just use the feature set from python 2.3/2.4 core

2.4 is what is in RHEL-5, so unless you want to do a lot of work you are stuck with that for most production work.

alot of the new features are infrequently used. decorators (func and class) saw large uptake

They work fine in 2.4, and are pretty useful.

but i only see a handful of references to context managers (with)

2.4 didn't have with, and even 2.5 has to have it specially enabled. And you have to wait for 2.6 before you can do multiple expressions per. 'with'. I'm also not convinced that everyone will want to make all their objects context managers.

i can't say i've seen a single conditional expression.

Even if that was in 2.3, I'd never use it ... has to be the most ugly implementation of that feature.

From 2.6.x the new string.format crack seems complete insanity, preferring one DSL over another for no sane reason that I can see. My guess is that java/.net programmers will use it, and C/old-python programers will ignore it ... but maybe I'm wrong.

On the other side I'm shocked it's taken this long for "0b" to get into the language, and I'm still amazed/disappointed that they haven't added perl's _ number seperator (Eg. 1_000_000 is a valid number in perl). Having ** work on any mapping in 2.6.x will certainly stop some of my cursing, dito. keyword args. after *args (although I hit that much less). Adding more tweaks like these would be a much bigger benefit than loss, IMO.

But in general given that it looks like RHEL-6 is going to be based on a 2.6.x variant, not changing the language too much from that for a few years seems like a good idea.

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 16:49 UTC (Thu) by sergey (guest, #31763) [Link]

I use with and conditional expressions all the time and write context managers very often. It makes my life easier that open/close semantics is part of the language. I don't even have to document how to grab a resource and give it back when done -- it's obvious. Both features in my opinion are easy to read, elegant, and extremely useful. But difference of opinion on each individual feature is not the topic of this discussion I believe. Compare this, I don't know, with NUMA support in Linux: I've never had access to a machine that would require it, but I know it's being used, have nothing against it, and benefits from it trickle down even to a relatively simple kernel build on my dual-core laptop.

All these arguments above are actually in favor of keeping the language fluid: there doesn't seem to be a single case where new features harm anybody.

> But in general given that it looks like RHEL-6 is going to be based on a 2.6.x variant, not changing the language too much from that for a few years seems like a good idea.

I think RHEL or any other distribution's choice is much less relevant than it seems. I used to work for a large financial services organization, the department in charge of that stuff used RHEL 4 at the time but built their own Python packages, along with Apache, Perl, proprietary products like RogueWave libraries, and lots of other stuff. If people need these features, they'll find a way to get them "for most production work." A stronger argument would be that those on shared hosts are stuck, but I use Webfaction for example and they have all versions of Python available (on RHEL boxes btw), so even this is not generally true.

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 19:04 UTC (Thu) by nevyn (subscriber, #33129) [Link]

I use with and conditional expressions all the time and write context managers very often. It makes my life easier that open/close semantics is part of the language. I don't even have to document how to grab a resource and give it back when done -- it's obvious.

I agree conditional expressions are mostly opinion but for 'with' ... can you give some examples? I guess my biggest confusion is why you need it over just using __del__ and reference counting? (what I do with files). It also seems weird because now you can't easily change code to move things out of blocks, because the end of the block explicitly closes one or more resources (generally what I need to do with dbconnections).

All these arguments above are actually in favor of keeping the language fluid: there doesn't seem to be a single case where new features harm anybody.

I agree, I think with the move to py3k breaking so much old code and generally causing lots of pain ... people have probably voiced that they want more stability, but I don't think it's the new features which were the problem (Eg. I moved to 2.6.x almost immediately, I'm still dreading moving to py3k).

I think RHEL or any other distribution's choice is much less relevant than it seems.

I guess it depends on who you are, and it's possible be that a "lot" of large companies will move to internal versions of py3k before RHEL-6 is dead ... but my code gets deployed on other people's RHEL-x so I have no choice, and I know of a lot of people who own their production servers who would have to have a very big reason to maintain their own version of a big critical like python.

Proposal: Moratorium on Python language changes

Posted Oct 22, 2009 20:46 UTC (Thu) by tan2 (subscriber, #42953) [Link]

I agree conditional expressions are mostly opinion but for 'with' ... can you give some examples? I guess my biggest confusion is why you need it over just using __del__ and reference counting? (what I do with files).

Because it's hard to control who holds the reference. See this post on comp.lang.python for an example.

Proposal: Moratorium on Python language changes

Posted Oct 23, 2009 15:04 UTC (Fri) by sergey (guest, #31763) [Link]

> I agree conditional expressions are mostly opinion but for 'with' ... can you give some examples?

You can can get in and out of "with" blocks repeatedly with the same context manager instance. Locking and all kinds of transactions are a good example, I'd be surprised if those are not mentioned in a PEP for "with." As for less conventional stuff... I used it once to control output indentation level in a console tool. A primitive bug tracker web application wrapper I wrote for work must use SOAP so suds (https://fedorahosted.org/suds/) is my friend. I'd rather not keep recreating all the SOAP metadata, so I keep the same suds SOAP "factory" inside the wrapper class and use context manager pattern to log into/out of the bug tracker.

Proposal: Moratorium on Python language changes

Posted Oct 25, 2009 22:13 UTC (Sun) by SEJeff (subscriber, #51588) [Link]

If you're feeling froggy, you can take a F9/F10 python and add this to the
patchlist at the end.

http://www.digitalprognosis.com/opensource/patches/python...
backport-to-db4-4.3.patch

With a little mundging of %_prefix in the spec file, you can have python2.4
and python2.5
installed side by side on production RHEL5 boxen.

Proposal: Moratorium on Python language changes

Posted Oct 25, 2009 22:34 UTC (Sun) by SEJeff (subscriber, #51588) [Link]

http://tinyurl.com/yjfem6n This might work better as the LWN comment system
ate the URL.

Proposal: Moratorium on Python language changes

Posted Oct 26, 2009 4:20 UTC (Mon) by nevyn (subscriber, #33129) [Link]

There's an open BZ that the python maintainer is looking at, which is trying to put python3.x in Fedora along side python2.6 ... but I don't recommend that, for the same reasons I don't recommend 2.4 + 2.5 in RHEL-5. Doing it via. rpms is likely to cause you pain, I've written up the major bits of pain you'll hit:

http://illiterat.livejournal.com/7660.html

Proposal: Moratorium on Python language changes

Posted Oct 26, 2009 5:50 UTC (Mon) by SEJeff (subscriber, #51588) [Link]

Great blog post btw but I've had this in production (python2.4 and
python2.5) for almost a full year with no problems. We just have our
applications explicitly request python2.4 or python2.5 in the shebang. We
also did something similar for another application using the alternatives
system with %ifarch magic and %preun/%post scripts in the spec. It is
doable. Even managing /usr/bin/python using alternatives is *doable* if you
decide it is the right thing for your use case.

However for general purpose distro with finite resources I agree with you
completely. With production code that is tested in a limited environment
(read %packages --nobase in the ks) you should use whatever makes the most
sense. For my stuff, python2.4 lacks needed features. Each environment is
unique and neither is wrong.

Redhat not making python > 2.4 available in RHEL has caused some
environments to move away from RHEL/CentOS. It is one of the disturbing
reasons you'll see some of the ruby shops or newer django ponies websites
be powered by Ubuntu, Debian, or even Fedora.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds