ding
instead of early-binding) that's needed for edit-and-continue. But the
intention would be to list all of those differences.)
Feel free to ask again if I missed some aspect of your questions here.
asrp
> Sent: Saturday, February 03, 2018 at 12:29 PM
> From: "Christian Tism
ot;else" clause, we probably want
to make some provision for the runtime to distinguish between the two so I'd
edit the grammar with something like
for_stmt = "for" {exprlist} "in" {testlist} ":" {suite} {((SAME_INDENT
"else" ":" {suite})
Oh and I forgot to mention that since everything is mostly done at run time,
there could just be different modules for (slightly) different languages. I
don't know if that'd be problematic for maintenance though.
asrp
> Sent: Saturday, February 03, 2018 at 3:17 PM
> From: asrp <a...@
> Message-ID: <20180206034013.gz26...@ando.pearwood.info>
>
> On Sat, Feb 03, 2018 at 11:45:15AM +0100, asrp wrote:
>
> > > Can you give an example of how you would do that? I don't mean the
> > > mechanism used, I mean how would a developer implement a new
the RPython language a bit more explicit for the
rest of us.
Reading your post reminded me that having nested lists of lists of ...
eventually strings (not all at the same nesting level) already made it
difficult. I don't remember if I stopped trying there or a bit more further
along.
asrp
> On Feb
in C.
Its here: https://github.com/asrp/python_terp
So, for example, redefining the for_stmt function in the right scope changes
the behaviour of future for loops at runtime.
Although from discussion I've read in PEPs, actual implementation always look
like a non-issue (which seems like magic
