Hello, On Sun, 6 Dec 2020 00:37:15 -0500 Ricky Teachey <ri...@teachey.org> 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/ac2a9145ec8c05fe2be7c982d88a8abfa37609cc 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). -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HOZGLJ2XD3YAIRYVZVQM5DWFKL5RCALZ/ Code of Conduct: http://python.org/psf/codeofconduct/
