[Python-Dev] Re: raw headers in rfc822.Message
Tue, 10 Sep 2002 23:39:52 -0400
From: "Guido van Rossum" <email@example.com>
> I guess we're assuming that even people who aren't familiar with
> SourceForge are familiar with diff. Is that not a reasonable
> assumption any more?
> There's also the developer FAQ, which has carefull instructions for
> patch generation at
> and in addition points to http://www.python.org/patches/ which has
> everything you need (except the hint about forward diffs; I'll add
FAQs and pointers be darned; there is only one way to
developerhood and that is through the school of hard knocks.
- Learn to use CVS (which, of course, entails SSH and such).
- Use Googol (a lot), or risk proposing that which has already
been decided, researched, or discussed ad naseum.
- Submit a patch. Find out that it was the wrong diff format
or keyed-off of an older, non-current version of the file.
Then find-out that your editor's tabbing and spacing confounds
somebody's life, somewhere. Oh, did you forget to run the
regression tests? Did your tests run fine, but you didn't run them
in debug mode? Perhaps your Windows machine skips the test for
the library you modified. Break working code and suffer public
- Read every PEP and make sure your patch style has no
deviations (unless, of course, your C and Python coding
style already matched the PEPs).
- BTW, did you submit unittests and docs with your patch?
Did you make appropriate adjustments to the makefiles,
and every other reference to you work? And appropriate
announcements in Misc/NEWS?
- Surely, you've learned TeX and its many Python specific
macros (forward slash or backslash, verbatim or code?)
How many characters were on your longest line (72, 78,
hopefully, not more).
- When learning a guitar, it helps to develop calluses on
the fingers. Write a PEP is the fastest way to develop the
calluses; contradicting Guido is the second fastest way;
submitting a great idea is third fastest (bad ideas either
get ignored or are slammed so quickly that the scar tissue
doesn't have time to develop).
- Experience the politics of bug resolution. If a developer
proposed it, then it should not be dismissed lightly. If
someone had a grandiose scheme in mind when they
submitted the report, be prepared for wrath when you
apply a simple solution. Realize that, in some cases,
someone, somewhere is relying on the undocumented
buggy behavior and your fixing it is breaking their code.
- And, my all time favorite, do everything right (formatting,
procedure, profiling, testing, etc) and watch the Timbot
come along five minutes later and improve your code
making it faster, clearer, more conformant, more elegant,
and also gel neatly with the vaguaries of memory allocation,
cache performance, and compilers you've never heard of.
Oh, and did I mention that native speakers of ASCII will
never be able to master Unicode like a native?