On 9/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote: > An approach to this area that would make sense to me is: > > 1. Defer PEP 350 > 2. Publish a simple Python module for finding and processing code tags in a > configurable fashion > 3. Include a default configuration in the module that provides the behaviour > described in PEP 350 > 4. After this hypothetical code tag processing module has been out in the wild > for a while, re-open PEP 350 with an eye to including the module in the > standard library > > The idea is that it should be possible to tailor the processing module in > order to textually scan a codebase (possibly C or C++ rather than Python) in > accordance with a project-specific system of code tagging, rather than > requiring that the project necessarily use the default style included in the > processing module (Although using a system other than the default one may > result in reduced functionality, naturally). Maybe I'm just an old fart, but this all seems way over-engineered. Even for projects the size of Python, a simple grep+find is sufficient. -- --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