On Sat, Dec 5, 2020, 3:03 PM Christopher Barker <python...@gmail.com> wrote:
> just one more note: > >> > things like you are proposing with an eye to performance is not >> > really where the Python community wants to go. >> >> I never met a Python user who said something like "I want Python to be >> slow" or "I want Python to keep being slow", so we'll see how that goes. >> > > But many that might say "I don't want to make Python less flexible in > order to gain performance" > > Of course no one one is going to reject an enhancement that improves > performance if it has no costs. > > My thought on your idea is this: > > Yes, a more restricted (strict) version of Python that had substantially > better performance could be very nice. But the trick here is that you are > proposing a spec, hoping that it could be used to enhance performance. I > suspect you aren't going to get very far (with community support) without > an implementation that shows what the performance benefits really are. > > I'm just one random guy on this list, but my response is: > > "interesting, but show me how it works before you make anything official" > > -CHB > >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, 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? >
_______________________________________________ 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/CNNZYGER6IJYMK6V3D2GUQHRGDCHA53Y/ Code of Conduct: http://python.org/psf/codeofconduct/
