[Python-Dev] Patch making the current email package (mostly) support bytes (original) (raw)

lutz at rmi.net lutz at rmi.net
Tue Oct 12 18:01:57 CEST 2010

barry at python.org wrote in the full post below:

I'm reminded of a survey Guido conducted at some long past Python conference. He asked (paraphrasing): raise your hand if you think Python is changing too fast. Lots of hands went up. Then he asked, raise your hand if you have a feature you want to get in the next version. Lots of hands went up.

When? I doubt that you'd get the same reaction today given the schism that 3.X has created. Regardless, this underscores much of what I'm trying to get across here. Python conference attendees are hardly representative of the user base at large. Even today, they are probably just 0.1% of the whole. This list's readership is an order of magnitude smaller still. Open doesn't mean all that much to those outside the 0.01% whose preferences set the agenda.

I appreciate that some people here do indeed weigh compatibility carefully, and realize that there are multiple valid viewpoints on this issue. And regrettably, I have neither solutions nor time to give this thread the further attention it deserves.

So my point is just this: Change for change's sake is truly not what most Python users want. If Python core developers want 3.X to become as popular as 2.X, they should be less concerned with posts on this list or hands at a conference, than with the feet of the masses whose votes will ultimately decide 3.X's fate.

--Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)

Date: Fri, 8 Oct 2010 14:20:32 -0400 From: Barry Warsaw <barry at python.org> To: python-dev at python.org Subject: Re: [Python-Dev] Patch making the current email package (mostly) support bytes

On Oct 08, 2010, at 03:44 PM, lutz at rmi.net wrote: >Ultimately, development in the open source world is driven by the >very few with time to show up, rather than by the very many who >depend on it. This can unfortunately lead to the perception >of thrashing by end users. Some even come to see the net effect >as not that much different from closed models. I have no solution >to offer, except to underscore again that changes made here affect >very many people who are too busy using Python to participate here. >Especially given the still tentative state of 3.X, stability matters. I'm reminded of a survey Guido conducted at some long past Python conference. He asked (paraphrasing): raise your hand if you think Python is changing too fast. Lots of hands went up. Then he asked, raise your hand if you have a feature you want to get in the next version. Lots of hands went up. I'm sympathetic to the view that changes in Python can be disruptive to end users. The Python community itself takes this seriously too, as evidenced by the language moratorium[*]. But OTOH, Python cannot stagnate and even fixing things means changing things. The reality too is that Python releases come out approximately every 18 months, and a year and a half can either seem like an excruciatingly long time, or blink of the eye depending on which side of the fence you stand on. Yes, stability matters, but Python 3 is still a new snakeling and I suspect that as the pace of porting picks up, more changes will be necessary. Adding new modules named like distutils2 or unittest2 is less than satisfying but useful for keeping older APIs around. I'm sad to hear that some people think that our development model differs little from closed source development. To me, nothing could be further from the truth. But the adage does go "(s)he who does the work, decides", and this is the forum for those who are doing the work. I think everyone here welcomes advocates for under-represented Python communities, and their concerns should be taken in consideration when changes are discussed. But ultimately, Python must evolve to stay relevant or it will die. This is where competing design trade-offs must be discussed. If not here, by us, then where and by whom? -Barry [*] Mostly instituted to allow alternative implementations to catch up, it does necessarily slow the pace of changes visible to end users.

More information about the Python-Dev mailing list