[Python-Dev] PEP 290 revisited (original) (raw)
Guido van Rossum guido@python.org
Thu, 09 Jan 2003 10:47:40 -0500
- Previous message: [Python-Dev] PEP 290 revisited
- Next message: [Python-Dev] Re: PEP 290 revisited
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> If you want to help, pick one module at a time (it must be a module > that you know and use) and do a thorough style review on all aspects > of the module. E.g. add docstrings, make sure docstrings conform to > PEP 8, use the latest builtins where it makes sense, use nested scopes > if it would clarify things, etc. Also do a thorough review of the > module's test suite, making sure that all end cases are tested and > that all code in the module is actually tested (use coverage tools!), > adding tests when necessary. > > I know, that's much less fun and no quick satisfaction, but it leads > to code improvement rather than bitrot.
Yes, but it also means the folks doing the real work in a module are going to have to deal with this kind of stuff that probably seems trivial to them and not worth doing when they could be writing real code. It just means there is more on their plate and that Python itself, may not meet its own guidelines; these kinds of changes tend to not get done because there is never enough time.
I've never considered this a problem. If the code isn't changed for trivial reasons that means I still recognize it when I have to fix a bug 3 years later.
I am certainly not up for the level of involvement you are suggesting for a given module within the standard libs, nor do I think I have the level of knowledge and skills required, so I'll have to decline on that and just stick to the projects already on my plate.
That's okay. You're doing good work on your own projects!
The downside is that after a certain point, a Python programmer starts looking at the standard libs and common packages for inspiration and code to reuse in their own code, at least I know I did. That's where I picked up my use of the string module, types, == None and != None, etc. A year and half later I'm getting around to cleaning this stuff up in my own code (and wxPython) when I see it, plus now I know better, but I would have preferred to see the "correct" way first. And yes I didn't discover the PEPs until long after I was already investigating and copying examples from the Python sources; that order of discovery may not be typical.
People who don't read documentation have no excuse. :-)
Anyway, at least the level of involvement requirement is clear so those that want to step up to the plate, can.
--Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] PEP 290 revisited
- Next message: [Python-Dev] Re: PEP 290 revisited
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]