On Thu, Feb 28, 2013 at 1:15 AM, Nick Coghlan firstname.lastname@example.org wrote:
On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw email@example.com wrote:
On Feb 27, 2013, at 11:33 AM, firstname.lastname@example.org wrote:
The easy part for Jython is pushing some of our "if is_jython:" stuff into the appropriate spots in CPython's Lib/.
I wonder if there isn't a better way to do this than sprinkling
is_pypy, is_ironpython, is_thenextbigthing all over the code base. I
bright ideas here, but it seems like a feature matrix would be a better
go than something that assumes a particular Python implementation has a particular feature set (which may change in the future).
Yes, avoiding that kind of thing is a key motivation for sys.implementation. Any proposal for "is_jython" blocks should instead be reformulated as a proposal for new sys.implementation attributes.
I kind of wish there were an assert-like magic "if __debug__:" type of mechanism behind this so that blocks of code destined solely for a single interpreter won't be seen in the code objects or .pyc's of non-target interpreters.
That idea obviously isn't fleshed out but i figure i'd better plant the seed...
It'd mean smaller code objects and less bloat from constants (docstrings for one implementation vs another, etc) being in memory. Taken further, this could even be extended beyond implementations to platforms as we have some standard library code with alternate definitions within one file for windows vs posix, etc.
Antoine's point about code like that being untestable by most CPython developers is valid. I'd want --with-pydebug builds to disable any parsing -> code object exclusions to at least make sure its syntax doesn't rot but that still doesn't _test_ it unless we get someone maintains reliable buildbots for every implementation using this common stdlib.