<p dir="ltr"><br>
On 5 Jun 2015 00:25, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 4 June 2015 at 14:48, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> > On 4 June 2015 at 23:06, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> >> As a straw man how about a new syntax (this won't work as written,<br>
> >> because it'll clash with the "<" operator, but the basic idea works):<br>
> >><br>
> >>     LITERAL_CALL = PRIMARY "<" <any source character except right<br>
> >> angle bracket>* ">"<br>
> ><br>
> > The main idea I've had for compile time metaprogramming that I figured<br>
> > I might be able to persuade Guido not to hate is:<br>
> ><br>
> >    python_ast, names2cells, unbound_names =<br>
> > !(this_is_an_arbitrary_python_expression)<br>
><br>
> The fundamental difference between this proposal and mine is (I think)<br>
> that you're assuming an arbitrary Python expression in there (which is<br>
> parsed), whereas I'm proposing an *unparsed* string.</p>
<p dir="ltr">No, when you supplied a custom parser, the parser would have access to the raw string (as well as the name -> cell mapping for the current scope).</p>
<p dir="ltr">The "quoted AST parser" would just be the default one.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>