<div dir="ltr">Yes, but in this case the near term "problem" was as far as I can tell just parsing floats as decimals, which is easily done with a somewhat noisy function call.  I don't see why it's important.<div><br></div><div>The way that CPython does parsing is more than just annoying.  It's a mess of repetition and tests that try to make sure that all of the phases are synchronized.  I don't think that CPython is the future of Python.  One day, someone will write a Python interpreter in Python that includes a clean one-pass parser.  I would prefer to make that as easy to realize as possible.  You might think it's far-fetched.  I don't think it is.</div><div><br></div><div>Best,</div><div><br></div><div>Neil</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 12:18 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"><span class="">On 8 June 2015 at 13:10, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> In this particular case, given Nick's comments about why we change the<br>
> guts here, I'd say that 'worth doing eventually' is not in consensus,<br>
> and I personally think that anything that is 'in the indefinite<br>
> future' is almost never more important than problems affecting people<br>
> today, because its a possible future benefit vs a current cost.<br>
> There's probably an economics theorem to describe that, but I'm not an<br>
> economist :)<br>
<br>
</span>I don't know about economics, but for anyone that hasn't encountered<br>
it before, the phrase YAGNI is a good one to know: You Ain't Gonna<br>
Need It. ( <a href="http://c2.com/cgi/wiki?YouArentGonnaNeedIt" target="_blank">http://c2.com/cgi/wiki?YouArentGonnaNeedIt</a> )<br>
<br>
The way YAGNI applies when deciding *to* do something is when you're<br>
faced with the following choice:<br>
<br>
* Making a particular change solves an immediate problem, but would<br>
make another possible change more complex in the future<br>
* Not making a change preserves the simplicity of the possible future<br>
change, but also doesn't solve the immediate problem<br>
<br>
Sometimes you'll get lucky and someone will figure out a third path<br>
that both addresses the immediate concern *and* leaves your future<br>
options open for other changes. More often though, you'll have to<br>
decide between these options, and in those cases "YAGNI" argues in<br>
favour of heavily discounting the potential increase in difficulty for<br>
a change you may never make anyway.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
P.S. This tension between considering the long term implications of<br>
changes without allowing that consideration to block near term<br>
progress is what I personally see in the following two lines of the<br>
Zen of Python:<br>
<br>
    Now is better than never.<br>
    Although never is often better than *right* now.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</div></div></blockquote></div><br></div>