[Python-Dev] Patch making the current email package (mostly) support bytes
barry at python.org
Fri Oct 8 20:20:32 CEST 2010
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?
[*] Mostly instituted to allow alternative implementations to catch up, it
does necessarily slow the pace of changes visible to end users.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Python-Dev