[Python-ideas] Hooking between lexer and parser

[Neil Girdhar]

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.

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.

Best,

Neil

On Mon, Jun 8, 2015 at 12:18 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 8 June 2015 at 13:10, Robert Collins <robertc at robertcollins.net> wrote:
> > In this particular case, given Nick's comments about why we change the
> > guts here, I'd say that 'worth doing eventually' is not in consensus,
> > and I personally think that anything that is 'in the indefinite
> > future' is almost never more important than problems affecting people
> > today, because its a possible future benefit vs a current cost.
> > There's probably an economics theorem to describe that, but I'm not an
> > economist :)
>
> I don't know about economics, but for anyone that hasn't encountered
> it before, the phrase YAGNI is a good one to know: You Ain't Gonna
> Need It. ( http://c2.com/cgi/wiki?YouArentGonnaNeedIt )
>
> The way YAGNI applies when deciding *to* do something is when you're
> faced with the following choice:
>
> * Making a particular change solves an immediate problem, but would
> make another possible change more complex in the future
> * Not making a change preserves the simplicity of the possible future
> change, but also doesn't solve the immediate problem
>
> Sometimes you'll get lucky and someone will figure out a third path
> that both addresses the immediate concern *and* leaves your future
> options open for other changes. More often though, you'll have to
> decide between these options, and in those cases "YAGNI" argues in
> favour of heavily discounting the potential increase in difficulty for
> a change you may never make anyway.
>
> Cheers,
> Nick.
>
> P.S. This tension between considering the long term implications of
> changes without allowing that consideration to block near term
> progress is what I personally see in the following two lines of the
> Zen of Python:
>
>     Now is better than never.
>     Although never is often better than *right* now.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150608/f10be409/attachment.html>