[Python-Dev] Re: raw headers in rfc822.Message

[Raymond Hettinger]

From: "Guido van Rossum" <guido@python.org>

> 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
> 
>   http://www.python.org/dev/devfaq.html#patches
> 
> and in addition points to http://www.python.org/patches/ which has
> everything you need (except the hint about forward diffs; I'll add
> that).

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


Raymond Hettinger

Oh, and did I mention that native speakers of ASCII will
never be able to master Unicode like a native?