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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4