Hi,
(My other reply to Alex and Steven doesn't seems to appear, at least not on
pipermail so I hope these don't come in the wrong order.)
> In the readme to python_terp you say:
>
> """
> python_terp is intended to make language modification to Python easier
> to preview changes more quickly and is not intended for full CPython
> compatibility. However, a large subset of Python is already included. In
> particular, enough to run the first stage of its parser.
> """
>
> This needs clarification.
> What do you mean by subset? A real subset or also things that
> are different and will stay different?
> To what extent are you planning to stay compatible, and where
> do you plan to deviate?
>
> The reason that I'm asking is that by compatible I mean the
> compatibility of PyPy. If you can reach that, and be it just
> by a subset, then it makes sense to speak of Python.
>
Good questions! There are two part to what I meant by that passage.
One is a reflection of the current state of the interpreter and its
capabilities. I put an example instead listing all differences because its
easier to update but admittedly much less precise.
The other concerns the intention for the future. My mind is not completely made
but here's what I currently think it should/could be.
First, fidelity would be determined by how the interpreter is used (if its
used). More (potentially) drastic changes in the beginning than later on.
Hopefully the deviations from Python (if any) for this reason does not grow too
much from this. But since its for testing language changes (to Python), I don't
think it would stray too much, if any.
Second, I'd like to keep the whole thing small (of low complexity) as much as
possible so in some cases, the less featureful choice will be kept. For
example, in an earlier version, I had more functions parameters handling
(defaults, *args, **kwargs, etc) but remove it because just setting up the
initial local scope from the parameters passed and function definition took
more than 100 lines. (Maybe I just went about this the wrong way...)
However, except for easier or simpler implementation of the interpreter or some
of the initial AST nodes, I don't intend to make any additions not in the
Python language. One example of this is simple_for and single_if statements
which I explain a bit in this old post:
http://blog.asrpo.com/bootstrap_chicken_or_egg
Although those are mainly intended to bootstrap the other statements like
if_stmt and for_stmt and not used again later.
(Well, there might be some difference 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 PM
> From: "Christian Tismer" <tis...@stackless.com>
> To: "asrp asrp" <a...@email.com>, python-dev@python.org
> Subject: Re: [Python-Dev] A minimal Python interpreter written in Python for
> experimenting with language changes
>
> Hi user with no real name yet,
>
> On 03.02.18 01:01, asrp asrp wrote:
> > Hello,
> >
> > I don't know if this is the right place to post this. Please redirect as
> > needed.
> >
> > I've made a small Python interpreter in Python with runtime AST node
> > semantics and edit-and-continue. I thought it could make prototyping
> > language changes more easily and visualize usage before writing 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 seems like magic to me) so maybe no-one here
> > actually needs this.
> >
> > (I really needed edit-and-continue for one of my projects but of course,
> > running it in this extra interpreter is much too slow.)
> >
> > asrp
>
> In the readme to python_terp you say:
>
> """
> python_terp is intended to make language modification to Python easier
> to preview changes more quickly and is not intended for full CPython
> compatibility. However, a large subset of Python is already included. In
> particular, enough to run the first stage of its parser.
> """
>
> This needs clarification.
> What do you mean by subset? A real subset or also things that
> are different and will stay different?
> To what extent are you planning to stay compatible, and where
> do you plan to deviate?
>
> The reason that I'm asking is that by compatible I mean the
> compatibility of PyPy. If you can reach that, and be it just
> by a subset, then it makes sense to speak of Python.
>
> Cheers - Chris
>
> --
> Christian Tismer-Sperling :^) tis...@stackless.com
> Software Consulting : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : https://github.com/PySide
> 14482 Potsdam : GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776 fax +49 (30) 700143-0023
>
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
