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...@email.com> > To: "Christian Tismer" <tis...@stackless.com> > Cc: python-dev@python.org > Subject: Re: [Python-Dev] A minimal Python interpreter written in Python for > experimenting with language changes > > 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
