A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20130302/e3a75e67/attachment.html below:

<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 28, 2013 at 1:15 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Feb 28, 2013 at 1:37 PM, Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>

> On Feb 27, 2013, at 11:33 AM, <a href="mailto:fwierzbicki@gmail.com">fwierzbicki@gmail.com</a> wrote:<br>


</div><div class="im">>>The easy part for Jython is pushing some of our "if is_jython:" stuff<br>
>>into the appropriate spots in CPython's Lib/.<br>
><br>
> I wonder if there isn't a better way to do this than sprinkling is_jython,<br>
> is_pypy, is_ironpython, is_thenextbigthing all over the code base.  I have no<br>
> bright ideas here, but it seems like a feature matrix would be a better way to<br>
> go than something that assumes a particular Python implementation has a<br>
> particular feature set (which may change in the future).<br>
<br>
</div>Yes, avoiding that kind of thing is a key motivation for<br>
sys.implementation. Any proposal for "is_jython" blocks should instead<br>
be reformulated as a proposal for new sys.implementation attributes.<br></blockquote><div><br></div><div style>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.</div>

<div style><br></div><div style>That idea obviously isn't fleshed out but i figure i'd better plant the seed...</div><div style><br></div><div style>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.</div>

<div style><br></div><div style>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.</div>

<div style><br></div><div style>-gps</div></div></div></div>


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