[Python-Dev] PEP 290 revisited (original) (raw)

Kevin Altis altis@semi-retired.com
Wed, 8 Jan 2003 23:22:26 -0800

-----Original Message----- From: Guido van Rossum

> I'm in the process of cleaning up string module references in wxPython. > > I decided to take a look at the 2.3a1 release and it appears that > Python and the standard libs need a similar cleanup. I thought we already eradicated most uses of the string module; whatever's left is probably due to PEP 291. But in any case, I'm against these kinds of peephole changes. Historically they have often introduced subtle bugs due to the sheer volume of changes. Also, these changes complicate code audits using cvs annotate when you need to understand who wrote a particular line of code, and why.

That makes sense. Fair enough.

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

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.

Anyway, at least the level of involvement requirement is clear so those that want to step up to the plate, can.

ka