> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4