On Thu, Feb 28, 2013 at 1:15 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw <barry@python.org> wrote:
> On Feb 27, 2013, at 11:33 AM, fwierzbicki@gmail.com 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_jython,
> is_pypy, is_ironpython, is_thenextbigthing all over the code base. 狢 have no
> bright ideas here, but it seems like a feature matrix would be a better way to
> 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. 狢'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.

-gps