On Sun, 6 Dec 2020 00:37:15 -0500 Ricky Teachey email@example.com wrote:
From another who like CHB is just random person on this list (but probably even more "random"), interested enough to have read the entire thread and the other thread, but not knowledgeable or competent enough to offer detailed comments that are going to be particularly helpful to anyone, I'd say this:
If you could actually make a fully functioning python that is significantly faster by doing this, and it introduced this two-stage interpreter idea with a much more strict secondary stage, and did not require all kinds of additional syntax in the code to get the speed improvements (like cython for example), I'd think you really might have something that would help a lot of people see the benefits of a potential switch to a stricter paradigm of writing in an ostensibly dynamic language that nonetheless would now have to be written much more less dynamically when inside functions and class methods.
It seems to me that if the speed increase is enough, it could be worth the decrease in flexibility, potentially. At least enough to support the existence of a second mode of python execution (whether that mode lives in cpython or not doesn't seem to much matter to me).
However I think maybe a big big problem is probably going to be the lack of interest in very popular third party, and even standard, libraries to rewrite their code to fit a D1S2 (dynamic stage one, strict stage two) interpretation model. It seems likely many heavily used packages will simply be near totally broken for your strict interpreter,
That's exactly the interesting part, which would be interesting to discuss, with interested parties. Just to give an idea of my timeline:
I coded the basic strict mode implementation for Pycopy in August last year. Then made another pass over in November last year. Before merging it to Pycopy mainline, I wanted to make sure it's viable with "general Python code". That's why for winter holidays 2019/2020 I coded up CPython pure-Python impl, https://github.com/pfalcon/python-strict-mode. Of course, I faced issues with CPython, went on to argue with CPython developers that they should fix their stuff, and then suddenly winter holidays were over.
Fast forward to this November, I figure I'm not making progress. So I think "god cares about CPython software, I care about *my* software". I went to convert whatever codes I already had running in Pycopy to the strict mode and found it's not bad at all (fixed gazillion usability bugs with the strict mode, yeah).
The spec, I started to write it, because after such a delay, my first reaction was literally the sane as @rosuav in his reply here on the list: "Wait, wtf we don't support dynamic module imports, I lllluuuuve dynamic module imports." So, I had to remind me why, and write it down this time. That's when open-source project get documentation - when the authors themselves find a need for it ;-).
Bottom line, here's the biggest change I had to apply to my most mind-boggling dynamic-imports app: https://github.com/pfalcon/ScratchABlock/commit/ac2a9145ec8c05fe2be7c982d88a... The app allows to pass on the command line a dir name, which can be full of files, and then inside each file, there can be multiple module names to import. Whoa! Still, 25 lines to cover it.
To see whether it's much or not, would need to compare what it would take me to do that in a static language. So, above I'm using Python as a kind of DSL for my app. In a static language, I would need to write a *real* DSL: all the lexer/parser/interpreter business. Not 25 lines at all. And in Python, I can pay 25 lines price to get rid of the most obnoxious Python misfeature comparing to a static language: blatantly inefficient namespace lookups.
Again, I'd be only more interested to hear/see/tell more stories about that. Just need to start somewhere.
and many many others will need tweaking. So they will have to be rewitten, or at least tweaked, somehow. Maybe many could be rewritten automatically? I do not know. But I think you need to consider that you could get to the end of writing this thing and have it working perfectly with a major (10x? 50x?) speed improvement, and still have trouble getting people interested because you can't run code in, like, the enum or pathlib or functools library, or requests or numpy or something else. That would be a bummer. How do you see that problem getting solved?
I don't see much of a problem at all. I see it the same way as e.g. Cython or Mypyc authors do: "to use this stuff, you need to change your Python code".
So, what we need to compare is how much you need to change and what you get in return. The strict mode asks for rather modest changes comparing to the tools above. But neither it claims 10x-50x speed improvement. Actually, the idea behind the strict mode is not to make Python faster. It's to make Python *not slower*. In one particular area - name lookup (and then only static classes/functions mostly, but stay tuned for the strict mode part 2, where we brainstorm object method lookup).