<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 7, 2015 at 10:52 PM, 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 12:37, Neil Girdhar <<a href="mailto:mistersheik@gmail.com">mistersheik@gmail.com</a>> wrote:<br>
> Ultimately, my problem with "token transformers" is, if I'm understanding<br>
> correctly, that we want to change Python so that not only will 3.5 have<br>
> Token transformers, but every Python after that has to support this.  This<br>
> risks constraining the development of the elegant solution.  And for what<br>
> major reason do we even need token transformers so soon?  For a toy example<br>
> on python ideas about automatic Decimal instances?  Why can't a user define<br>
> a one character function "d(x)" to do the conversion everywhere?  I prefer<br>
> to push for the better design even if it means waiting a year.<br>
<br>
</span>Neil, you're the only one proposing major structural changes to the<br>
code generation pipeline, and nobody at all is proposing anything for<br>
Python 3.5 (the feature freeze deadline for that has already passed).<br>
<br>
Andrew is essentially only proposing relatively minor tweaks to the<br>
API of the existing tokenizer module to make it more iterable based<br>
and less file based (while still preserving the file based APIs).<br>
Eugene Toder's and Dave Malcolm's patches from a few years ago make<br>
the existing AST -> bytecode section of the toolchain easier to modify<br>
and experiment with (and are ideas worth exploring for 3.6 if anyone<br>
is willing and able to invest the time to bring them back up to date).<br>
<br>
However, if you're specifically wanting to work on an "ideal parser<br>
API", then the reference interpreter for a 24 year old established<br>
language *isn't* the place to do it - the compromises necessitated by<br>
the need to align with an extensive existing ecosystem will actively<br>
work against your goal for a clean, minimalist structure. That's thus<br>
something better developed *independently* of CPython, and then<br>
potentially considered at some point in the future when it's better<br>
established what concrete benefits it would offer over the status quo<br>
for both the core development team and Python's end users.<br></blockquote><div><br></div><div>That's not what I'm doing.  All I'm suggesting is that changes to Python that *preclude* the "ideal parser API" be avoided.  I'm not trying to make the ideal API happen today.  I'm just keeping the path to that rosy future free of obstacles.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</div></div></blockquote></div><br></div></div>