

Oh Yeah? Where's Your Patches Zed? - inklesspen
http://zedshaw.com/blog/2009-05-30.html

======
jfischer
Does Zed realize that Guido's response was a joke?
<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-
lib...](http://sayspy.blogspot.com/2009/05/staleness-of-standard-library-
and.html).

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

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

------
bluefish
Some people really need to be on the offensive to get things done. They need
to feel like someone else is the enemy and they are going to defeat them. It
seems to me like Zed puts himself in the position of David vs the open-source-
community-Goliath on purpose so that he can be on the offensive. He gives
himself an enemy, throws down the gauntlet and declares that he can and is
going to make things better. I'm not one to argue that he picks the best
motivational targets, calling people out and demeaning a hard-working
community seems pretty negative, but damn when Zed says he is going to
deliver, Zed delivers. Laser focused, intelligent and hard-working. I would
love to work with Zed, hire him or have him contribute to one of my projects,
but damn, I'd be terrified of pissing him off.

~~~
nailer
Zed's the enemy of crap. Whether it's inconsistency in languages, poorly
created enterprise software development practices (The ACL is dead), or
egotism and leeching from others work without acknowledgement (Rails is a
Ghetto).

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

~~~
rbanffy
"Zed's the enemy of crap. Whether it's inconsistency in languages, poorly
created enterprise software development practices (The ACL is dead), or
egotism <b>coming from others (Zed's so fucking awesome)</b> and leeching from
others work without acknowledgement (Rails is a Ghetto)."

There. Fixed that for you.

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

~~~
rbanffy
It also seems he has a couple logins here.

~~~
nuclear_eclipse
I may share your position on Zed, but people here generally dislike comments
that don't add to the discussion, or are blatant attacks on someone; your post
fits both perhaps?

~~~
rbanffy
Interesting when a factually correct observation can be construed as an
attack.

~~~
mistermann
How do you know this? Are you implying that some of the Zed positive posts
here were actually made by him?

------
compay
Zed may have his quirks but he's a good programmer and is right more often
than not about these things.

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.

~~~
rbanffy
Zed's is also classic:

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

------
YuriNiyazov
And so it slowly begins, the alienation of Zed Shaw from the Python community.

~~~
timr
Who is alienating whom? It sure sounds like Zed is offering to do something
that he doesn't have to do, that could potentially be more work for him to
maintain, and that could easily lead to a lot more political trouble in the
long run.

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.

~~~
diN0bot
"Zed is offering"

yeah, right. he's a talker.

~~~
cubicle67
Sure he's a talker, but he has a long history of putting his (usually
excellent) code where his mouth is.

~~~
jshen
I would hesitate to call his code "excellent". How about chunked encoding for
mongrel? Here (<http://www.ruby-forum.com/topic/142852>) is his naive rant
about it, but it turns out that there are real reasons for CE. I would
describe his code as a ghetto.

~~~
jrockway
And where are _your_ patches?

~~~
jshen
I haven't bragged about how great I am while releasing software that fails to
implements parts of the spec.

------
boundlessdreamz
Zed was actually quite polite [but strong] in that post. For the first time
I'm starting to believe that he has kept the promise of changing. I might
subscribe again.

------
thristian
From the article: "I will make a long bet right now, that no matter how nice I
am, no matter how many people use my software, no matter how much better it is
than anything Python has that’s similar, Guido will not accept them as
changes."

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.

~~~
brodie
I agree. I'm not sure what the fuss is all about - it's not like the standard
library was coded by the Python core monks in seclusion a thousand years ago.
Much of it has grown and taken in new things over time.

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.

------
bradgessler
I really can't stand the "Oh yeah? Where are your patches?" attitude that is
so prevalent in the OSS community.

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.

~~~
jerf
While it can be taken too far, there are reasons for that attitude, too. I
think the most important one is that until you sit down and try to write a
patch that actually meets all the relevant needs, you don't have good odds of
making a really strong _engineering_ criticism. Any idiot can sit on the
sidelines and throw stones.

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

~~~
10ren
Just regarding "stop energy", the thing I love about software and startups is
you can just _do_ something. You don't to convince a corporate manager, nor an
academic panel, nor the board of developers. All you need do is make something
useful, and let the people know about it who need it.

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.

------
0xdefec8
I know I'm missing the point, but my main reaction to this is naive admiration
that Zed can complain about a language in a blog post and get flamed by the
freakin' creator of said language.

~~~
rbanffy
Can a one-liner be considered a flame?

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

~~~
rbanffy
Zed? Is that you modding me down?

------
randallsquared
_You acknowledge that the email systems in Python need an overhaul and that my
work will seriously be the basis of the effort._

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

------
granular
It's interesting to compare the Python situation to that of Perl.

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

~~~
moe
_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._

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

------
travisjeffery
He's right on with open source communities shunning new comers and code coming
from people outside of their own circle.

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.

~~~
DarkShikari
The difference is that code from an existing developer is going to be
maintained: that is, the existing developer will stay around to take care of
it.

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.

~~~
ErrantX
Great unmaintained code is better than a well maintained codebase that
features a set of fatal flaws :)

These things are relative

~~~
natrius
There's no such thing as "great unmaintained code".

~~~
ErrantX
of course there is... great code that doesnt get refactored. Kick aside
corporate jargon and namby-pamby ness :)

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

~~~
nailer
Great code is still subject to entropy. Shit will break. Mail servers will
start using some proposed SMTP extension, someone will find a nasty bug or
two, there will be security problems and inconsistencies and inefficiencies
discovered.

~~~
torr
Sure. Then you simply require hit-and-run commits to be well-commented and
also include good docs.

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

------
dfranke
In what project in what universe are outside contributions _not_ subjected to
more stringent quality control than those made by people who are already
trusted members of the development community? How could it possibly be any
different if you don't want your tree cluttered with garbage?

~~~
seabee
The post is saying the garbage is coming from within because trusted members
can get away with worse code.

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.

~~~
torr
> Enforcing different standards of quality control is unproductive ...

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

------
inklesspen
Sad thing is, I bet he's right.

~~~
rbanffy
Is it worth breaking backwards compatibility to have fancy libraries
distributed in the Python core?

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.

~~~
rbanffy
oops... "many modules"...

------
thomaslee
Does anyone else aside from zed have burning issues with optparse? I'm
genuinely curious. I use it quite a lot, but have never really had to push the
boundaries of what optparse can do. As an example, my optparse code usually
looks something along these lines:

    
    
        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()
    

Is it really that bad? Where does it fall down?

~~~
s3graham
I use it frequently and I like the output it creates. I sure as hell like
python's better than C#'s (== none at all and people doing all kinds of crazy
broken crap inlined into Main(string[] args).

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?

~~~
indigoviolet
I liked Getopt::Long in Perl. Even in Python, argparse or optfunc are better
(IMHO)

~~~
indigoviolet
And honestly, Zed's revolutionary replacement isn't that great
(<http://lamsonproject.org/docs/api/>, see lamson.args/lamson.commands).

------
stcredzero
"I will make a long bet right now, that no matter how nice I am, no matter how
many people use my software, no matter how much better it is than anything
Python has that’s similar, _Guido will not accept them as changes._ "

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

------
invisible
I've had similar frustrations with PrototypeJS. I've tried contributing, but
them choosing to include the patches is solely based on their mood as far as I
can tell. I've even went so far to completely rewrite the AJAX portion
(without drastic changes and shifting to better event handling+aborts)...

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

------
rbanffy
I really can't see why he can't publish his "fixes" for everyone to use. There
really is no need to bundle them in the Python distribution.

So, Zed, again, where are your patches?

------
diN0bot
"Give me six months and I’ll have the following"

------
jballanc
Here's the thing: Go to New York. Go to any random street corner. Wait until
traffic starts heading your way, then step into the middle of the street.
Guess what will happen?

I'll tell you what: You'll be called a stupid ass, a moron, a fuckin' tourist,
etc. You know what else? All those "rude" New Yorkers will have also just
saved your life. So, do you thank them or take offense?

