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

[lutz at rmi.net]

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.