On Oct 08, 2010, at 03:44 PM, l...@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.
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
