[Python-Dev] PEP 290 revisited

[Kevin Altis]

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