[Python-Dev] Python Language Summit at PyCon: Agenda

[Gregory P. Smith]

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

> On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw <barry at python.org> wrote:
> > On Feb 27, 2013, at 11:33 AM, fwierzbicki at 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.  I
> 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.  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.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130302/e3a75e67/attachment.html>