4 ms·

Does Zed realize that Guido's response was a joke? http://blip.tv/file/1931026 http://blip.tv/file/1931026 On a more serious note, I think that high bar to get

Does Zed realize that Guido's response was a joke? http://blip.tv/file/1931026 http://blip.tv/file/1931026 On a more serious note, I think that high bar to getting things into python is a good thing. What if Zed's changes were accepted, as is, into the Python codebase today? What about when the next guy comes with his alternative APIs for option parsing and email along with a new standard for templates? Should they include them, too? How many completely different APIs for the same thing should they include in the standard library? Any software system as large as Python is going to be imperfect -- it is constrained by backwards compatibility and conflicting requirements. However, Zed is free to build whatever he wants outside the core and make it available to the world. If it catches on enough, maybe his followers will go through the social process to get it into the core. This process helps to ensure consensus, consistency, and quality. For a thoughtful response from a core Python developer, see Brett Cannon's blog post: http://sayspy.blogspot.com/2009/05/staleness-of-standard-library-and.html http://sayspy.blogspot.com/2009/05/staleness-of-standard-lib....

jnoller 17y ago
Thank you.
- jfischer 17y ago
  You are welcome. Actually, the inclusion of your processing module in 2.6/3.0 is an excellent example of a non-core developer getting code into the Python distribution. Your blog postings on the process (especially http://jessenoller.com/2009/01/28/multiprocessing-in-hindsight/ http://jessenoller.com/2009/01/28/multiprocessing-in-hindsig...) really show how challenging it is to add something to a system that big (and ported to so many platforms). I appreciate the work you've put into processing (and one of these days I'll get around to using it). Overall, the Python community strikes me as a bunch of really pragmatic, low-key people who have learned the hard lessons in the trenches of software engineering. To me, this is almost more important than the details of the language.
nailer 17y ago
> What about when the next guy comes with his alternative APIs for option parsing and email along with a new standard for templates? Should they include them, too? If they improve the consistency of the language, sure. Keep the old APIs for a bit with a deprecation warning. Python 3 makes good breakpoint to do this too, as though released, it's still not used for most projects - the core team are making similar post-3.0 changes themselves.
tjogin 17y ago
I agree, this is something that shouldn't be solved arbitrarily in a first-come first-served fashion. However, I don't think this is something that will ever be solved or even addressed as long as Pythonistas continue to pretend Python is super consistent. A good first step towards fixing these kinds of issues would be to admit the issues exist at all.
- deleted 17y ago
  [deleted]
- ubernostrum 17y ago
  So you've missed the rounds of "name 5 things you don't like about Python" posts by prominent people in the community, many of which harp on various modules in the standard library? That there are things in need of improvement is not disputed. What to do to accomplish the improvement, well, that's a topic to go 'round and 'round about...
bartl 17y ago
I've got the strong impression Guido has no sense of humour.

jnoller 17y ago

Thank you.

jfischer 17y ago
You are welcome. Actually, the inclusion of your processing module in 2.6/3.0 is an excellent example of a non-core developer getting code into the Python distribution. Your blog postings on the process (especially http://jessenoller.com/2009/01/28/multiprocessing-in-hindsight/ http://jessenoller.com/2009/01/28/multiprocessing-in-hindsig...) really show how challenging it is to add something to a system that big (and ported to so many platforms). I appreciate the work you've put into processing (and one of these days I'll get around to using it). Overall, the Python community strikes me as a bunch of really pragmatic, low-key people who have learned the hard lessons in the trenches of software engineering. To me, this is almost more important than the details of the language.

nailer 17y ago

> What about when the next guy comes with his alternative APIs for option parsing and email along with a new standard for templates? Should they include them, too? If they improve the consistency of the language, sure. Keep the old APIs for a bit with a deprecation warning. Python 3 makes good breakpoint to do this too, as though released, it's still not used for most projects - the core team are making similar post-3.0 changes themselves.

tjogin 17y ago

I agree, this is something that shouldn't be solved arbitrarily in a first-come first-served fashion. However, I don't think this is something that will ever be solved or even addressed as long as Pythonistas continue to pretend Python is super consistent. A good first step towards fixing these kinds of issues would be to admit the issues exist at all.

deleted 17y ago
[deleted]
ubernostrum 17y ago
So you've missed the rounds of "name 5 things you don't like about Python" posts by prominent people in the community, many of which harp on various modules in the standard library? That there are things in need of improvement is not disputed. What to do to accomplish the improvement, well, that's a topic to go 'round and 'round about...

bartl 17y ago

I've got the strong impression Guido has no sense of humour.