[Python-Dev] PEP 290 revisited

[Kevin Altis]

> -----Original Message-----
> From: Michael Hudson
>
> "Kevin Altis" <altis@semi-retired.com> writes:
>
> > > 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 think this is a bogus argument, sorry.  If you're doing something
> non trivial to a module, the time required to use string methods
> rather than the string module is in the noise.

The point was that if you were just going to change to string methods or
implement any of the suggested changes in PEP 290, that each of these
changes would be considered trivial by themselves and not worth doing on
their own. I think they are worth doing, thus my original post, but other
developers probably feel that if it ain't broke don't fix it, despite how
the changes should make some code more readable and a bit faster.

If someone was involved in doing something non-trivial to the module, then I
agree with you, the time to implement just one change of PEP 290 isn't bad
either. Maybe the Python dev guidelines should encourage developers to make
PEP 8 and PEP 290 cleanups the next time they work on their particular
modules.

Implementing all the changes of PEP 290 does take time and focus. I would
set aside at least an hour per file for a thorough set of changes,
meticulously double-checking the patch diffs, etc. For PythonCard I found it
much simpler to batch change and so was able to do all the changes
comfortably over two days for 150+ files; I didn't change that many files,
but I had to do repeated greps, etc. of them. I was focused on one
particular aspect of PEP 290 per change to all the files in the framework
and samples. Each change such as switching to is None instead of == None,
isinstance(), or startswith() and endswith() in all the files was a separate
check-in. I think this makes it very easy to see the "upgrades" without any
confusion with new functionality changes (Skip's point).

But Guido's reply about someone other than the maintainer of the module
making changes leading to "bitrot" has merit, so I withdrew my original
offer to make the upgrades myself. It will be up to you and the other
developers to decide how much effort you want to put into conforming to PEP
290.

ka