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-lib....

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.

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.

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...

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.

If I pissed him off, I'd listen to why he's pissed off, because he's good at identifying crap.

There. Fixed that for you.

Zed is has a really, amazingly, big hat. Too bad there is next to no cowboy under it.

Guido's reply is classic: "you can't criticize my work unless you fix everything you complain about." This is a nice way to avoid having to debate the merits of the criticisms, but doesn't really advance the dialog (or the code) very much.

"I will provide my fucking awesome fix on the condition you include and recognize my fucking awesomeness. If you don't promise that, I will submit nothing"

Thus avoiding a clear review of Zed's shortcomings.

Zed is in denial. He can't grasp the fact that he is not that fucking awesome. And that, perhaps, he never really was awesome.

The way I see it, Zed made a (correct and polite) criticism of Python. Someone childishly taunted back at his criticism with the typical "where's the patch?" defensiveness, and he's now responding in a rather polite fashion. If Zed is making a mistake, it's that he's engaging in the debate at all. He's expressed his opinion -- if the Python people are so petty that they can't handle constructive criticism, the best response is to ignore them and move on.

Jesse gave a lightning talk at PyCon this past year, blowing off some steam about the people that complain about Python on Slashdot/Reddit/Hacker News without submitting a patch. The video is here if you're interested. It's actually kinda funny: http://pycon.blip.tv/file/1931026/

He suggested a new Python license that would forbid people complaining about the language without first submitting a patch. If people did this they would be "Van Lindberged". Van Lindberg is the Python software foundation's lawyer.

Jesse proceeded to showcase the "Van Lindberg engine." It was a javscript bookmarklet that took a comments page on reddit that complaining about python, and superimposed pictures of Van Lindberg all over it. The reddit page had then been "Van Lindberged" or "Lindbergified".

It didn't sound like Guido was trying to start shiznit with Zed. It sounded like he was making light of the situation, and suggesting that Jesse "Van Lindberg" Zed for his comments.

Van Lindberging is funny because it's an extreme response to what some devs see as a real problem, opinions without patches. Zed's pointing out he does in fact have patches, and can have more patches if they're likely to be accepted.

He will not do it. He doesn't like to play with others or have his brilliant ideas scrutinized by who he considers lesser people.

So, the way he has to prove me, and others who agree with me, is

- to provide the said patches (a plus, if they don't collide with already existing libraries, let's call Zed's SMTP "zsfasmtp") in publicly accessible libraries

- accept criticism and patches from others

- work with the Python maintainers to help them include his fucking awesome libraries in a future Python release

And that's it.

Until then, we all would gain if only he did shut the fuck up.

a) Either you won't get good quality code because Zed may be right.

or

b) You will get Zed's python branch because he/others got pissed off enough and the python community will be split into two.

I say B is a good solution. Eventually python-fusion will come out. :)

Edit: Let the war begin!

I dunno, what do you think is common to all of these situations? :P

(point being, zed surely could stir the pot less, but he's not changing what's in the pot. And if two pots happen to be similar, i don't know that that's his fault)

Exactly, being an asshole all the time isn't changing anything for the better.

I can see how politeness would be more successful, but I am comparing causing visible public scrutiny while being an asshole vs no public scrutiny.....and you say this approach never could and never has worked?

The truth is that one must create these false hypotheticals in order to justify zed being an asshole.

Huh? Maybe try a re-read of my post.

I'm not justifying him being an asshole, I am countering your assertion that if you are an asshole while pointing out legitimate shortcomings, that it will have no positive affect.

This is a false choice as is clear by your statement that zed is high profile. If he were polite there would still be public scrutiny so your binary hypothetical is meaningless.

Lots of opportunity for pop-psychology here... but best to let it pass...

It seems to me he's justified in not wanting to waste his time writing patches that wouldn't be accepted anyways.

Zed is a gifted hacker of software systems, but I don't really think he's all that good dealing with other mammals.

I'm all for it to the extent that Zed is building his personal brand and (in essence) being a self-promoter. If he really feels self-righteous about it, then that's a bit worrisome.

Zed vs Guido is exactly the sort of David vs Goliath story that makes for entertaining reading...

He is free to provide packages that replace core python libraries. The fact he doesn't want to do so and would only give his contributions if they are included in the standard Python libraries is childish, at best.

Man, how do you think we got optparse in the first place? People got sick of using getopt to parse command-line arguments (now there's a C-style option-parsing library for you) and somebody said "Hey, there's this third-party tool called Optik (http://optik.sf.net) that's much better than anything Python has that's similar, let's add it." And so, after some messing around with evaluating alternatives (http://www.python.org/community/sigs/retired/getopt-sig/) Optik was adopted as optparse.

I see no reason why Zed's shiny, improved replacements couldn't become part of the standard library if they're as good and as popular as he claims they'll be, so long as they're independently reusable and not all bundled together in some 'lamson' hierarchy.

And it's not the end of the world if his changes aren't accepted. He'll still have his own libraries, and people can enjoy them through PyPI.

That said, Guido is definitely very picky about changes to the language itself. I think that's a good thing.

If hackers want to describe their code as art or poetry; like artists, they damn well better be able to stand up to the critiques.

For instance, Zed says he wrote an options parser and it sounds like he wants it to ship with Python. Well, has he made the API reverse compatible? If not, is his really so much better that it's worth breaking reverse compatibility? Should we now ship two option parsers? These are questions that are easy to elide over in a blog post, but must be solved in the process of building a real patch, and criticisms that come from a true, honest attempt to build a real patch are much more valuable.

(Also, note the distinction I draw between simply replacing the option parser Python ships with because you have something better, vs. balancing the desire to not break old code against the better choice. Presumably Zed doesn't have years of code written against the options parsing module that Python ships with; those who do will have rather different priorities when it comes to deciding whether to ship a new one, if it breaks their code.)

At work, I frequently come across old code, go "This is stupid!", and replace it. Somewhat less frequently, I come across old code, say "This is stupid!", but discover in the process of replacing it why it was done that way. (No comments, of course.) It would be easy for me to go yell "It's stupid!" in both cases, but until I actually spend some time fixing it, my criticism is objectively less valuable.

There are other reasons too, this is just what I think is the best.

Let me repeat my first point so it is both my first last: This attitude can be taken too far. But the seed of the attitude is there for good reason.

See also: http://www.userland.com/whatIsStopEnergy (Note I don't think Zed has "stop energy"; he has code and he is pushing for things to be done. But I think this is related to the "show me the patches" issue, because in the general open source case it is one of the easiest ways to throw stop energy at somebody.)

Yes, you still have to convince people - but they aren't gateway guardians whose good opinion you must seek, but people who have the problem that you are trying to solve. Your interests are aligned.

Lately I have been searching for online API design guidelines - and the results were really rather dissapointing - there aren't many good online resources on that subject (or at least they are not easy to find). But all that I found were stressing how important it is to write use cases and example code using the API before wrtiting the implementation. I wonder what OS projects would accept use cases and example code as patches.

Two links for the interested in API design: my reddit question: http://www.reddit.com/r/programming/comments/8n4ov/api_desig... and my blog post about the findings: http://perlalchemy.blogspot.com/2009/05/api-design.html

Writing an egotistical blog post that rips on someone is destructive.

You know the drill: "show me the code or STFU".

Well, who's gonna promise that up front? Maybe Guido would be interested if Zed said, "You acknowledge that the email systems in Python need an overhaul and that my work will seriously be considered as the basis of the effort."

With Perl, there's a dozen solutions on CPAN for every problem, and you can pick and choose to find the best one. In Python, there's usually one that's had the blessing from above, and like-it-or-lump-it, that's the one everyone's using.

But the end result is, with Perl, in the long run, even though it's more work, the community ends up eventually filtering through the choices and homes in on the nearst-optimal solution. With Python, the higher-ups make the decision and you get what you get.

What's striking is that even with all its faults, Perl still can often win. Python fans look down at the playing field and they say, "How can this be? How is Perl still scoring goals? Python's got more equipment, a more detailed playbook, fancier training facilities, bigger crowds of fans, even snazzier jerseys. Perl's team is scruffy, scarred, and unkempt; they train on old equipment, and half the time they don't even seem to be taking the game seriously. Yet they still manage to score!"

As an aside: I like how even though Zed said he's done with the over-the-top persona, the real Zed is still showing through like always. :)

I think you have a misconception about Python. The equivalent to CPAN in the Python world is not the std library but PyPI (easy_install).

Zed's whining is inappropiate, he should just get to work. The current recommended practice to get something into the stdlib is:

1. Build it as an external package.

2. If it's good people will use it, it becomes popular, bugs get fixed.

3. Eventually it enters the stdlib (potentially obsoleting whatever package previously did the task)

Yes, the stdlib has accumulated a lot of cruft over the years due to the higher ups not adhering to this procedure. That's only more reason to tighten the criteria and accept new stuff only when it has proven itself in the wild - and not because a particular name is printed on it (be it Zed or someone else's).

Of course, Perl's followup problem is that the ill-thought core versions rarely get removed....

Enforcing different standards of quality control is unproductive since the weakest link in the chain determines the overall quality. Now, certainly you should scrutinise outside contributions more strongly than trusted contributions, but this isn't the argument.

Not only that, but it's poison for attracting new developers.

I've seen all over the place, it's pathetic.

Great code is great code, doesn't matter who it comes from and who gets the recognition. Think about the project over yourself.

Code from an outside developer will just be committed and never touched again in many cases, since the outside developer doesn't intend to stay and work on the project. If you don't believe me, look at the history of the ffmpeg project: there are enormous swaths of unmaintained code (and uncommitted code) for exactly this reason.

Thus, it is often reasonable to have higher code standards for code whose author does not intend to maintain it into the future.

These things are relative

The point was sometimes stuff just works, much better than a mess of a refactored project that has a core flaw.

Just because it's not currently maintained does not mean it won't be maintained in the future.

(I think your misunderstanding: I was replying to the generalisation with a generalisation)

Programmer A has been working with me for a long time, has done a lot of B- to B+ code. I trust that what he does is going to be up to that level.

Programmer B has been working with me for a long time and consistently turns in C level code. It isnt great, it isnt horrid. Call him pedestrian. When I get something from him, I know what it is going to be. Adequate. Not everything has to be great, most things move forward on adequate because there are too many things to get for B and A level people to do them all.

Programmer C is someone I don't know it all. Maybe I've heard of them by reputation, maybe not. Doesn't much matter, there is no trust there, I don't know what I'm getting. If I'm responsible, I'm going to vet their code closely. Make sure they follow coding conventions, best practices, etc. This takes time on my part. And my time is limited because now I am BDFL or some similarly ridiculous title that means "He's a busy guy".

Zed is employing a false contradiction: he can make his patches available and people can use them regardless of them being or not included in the core Python.

In fact, my modules that are now core started this way.

Zed is full of hot air.

    from optparse import OptionParser
    parser = OptionParser()
    parser.add_option("--force", default=False, action="store_true")
    parser.add_option("--host", default="localhost")
    options, args = parser.parse_args()

So it passes out any options it finds by default and lets you decide what to do with it - you only have to call a function if you want to set a default.

It lets you run args.parse_and_run_command to directly run a function and pass it the cmdline options as a dict.

It's all very handy and is totally compatible with previous cmdline structures!

I think it's a neat option & hopefully someone will convince Guido to have it in Python core in the future :) (doubt it though)

Grab the lamson source and dig it out to get a better idea.

I've never managed to use optparse without the docs open though. I'm not sure that's a defect, but it seems like room for improvement.

Can someone (zed?) point at a library in any other language that's better?

That's the same "not invented here" pattern that happened with Parc Smalltalk, and which persisted until a few years ago. (4 companies later.)

There are a lot of frustrations in doing that and it pretty much being moot on the politics of the community.

So, Zed, again, where are your patches?