[Python-ideas] Hooking between lexer and parser
mistersheik at gmail.com
Mon Jun 8 06:23:43 CEST 2015
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.
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.
> 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...
More information about the Python-ideas