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

Kevin Altis altis@semi-retired.com
Mon, 13 Jan 2003 11:23:10 -0800

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