e 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
&g
> 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
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
o work.
If we wanted an "otherwise" clause on top of an "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} &q
e for class method lookup (late-binding
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
iting them 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 s
