Josiah Carlson wrote:
Further, even if it becomes a spec, it doesn't guarantee implementation in Python editors (for which you are shooting for). Take a wander through current implementations of code tags in various editors to get a feel for what they support. I've read various posts about what code tags could support, but not what editors which implement code tags and/or its variants actually currently support; which is a better indication of what people want than an informal survey via email of python-dev, python-list, and/or the PEP submission process.
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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com