Hello, On Wed, 2 Dec 2020 03:02:26 +1100 Chris Angelico <ros...@gmail.com> wrote:
[] > If there are special-purpose cut-down implementations that provide a > more restricted environment in return for some other feature (say, > "being able to run in a web browser", or "being able to run on a > microcontroller"), then that's fine, Kinda yes, except not as vulgar as examples above. More like "being able to develop a JIT which doesn't cost million dollars" (extra points if that still can run on a microcontroller!). > but that's not a language feature > - that's a partial implementation that sacrifices the parts it can't > afford to do. The sacrifice is coming more from theoretical constraints on what's (easily) possible and what's not, not from vulgar constraints like "my microcontroller doesn't have space for that". How to be a dynamic language (addressing only dynamic name lookup here) and not suffer from that? How to have a cake and eat it? A simple answer (and we're interested in such here) is that you can't. First you have the cake - and heavy emphasis in the proposal is put on that, so you didn't start with just breadcrumbs. Then you eat the cake. To give the right idea of how to look at this stuff, you should compare this "strict mode" with Python compilers like Mypyc or Shedskin, and what restrictions they place. > From the sound of your proposal, this should be part of > the main Python language and be a normal expectation of code. I don't know where you got that sound from, because the very first sentence of the very first "Introduction" section reads: "This proposal seeks to introduce opt-in "strict execution mode" for Python language implementations interested in such a feature." So, is for example the CPython implementation interested? [] > Still -1000 on that, partly because you can never guarantee that it'll > be fast (if only because searching for and loading large numbers of > files can be very expensive without any single one of them being > blamed for the cost), This proposal puts a heavy emphasis on a JIT usecase, and JIT is known to have its startup costs. JIT is also known to not be a panacea fro all usecases, why this proposal says that strict mode doesn't replace "normal" mode, some programs are just bound to be run in it. > and partly because two-phase initialization is > something Python tries hard to avoid. This proposal specifically introduces two-phase startup sequence, which does affect imports. Price of magic. Now, all that in detail discussed in the proposal: https://github.com/pycopy/PycoEPs/blob/master/StrictMode.md#dynamic-module-imports (yes, I put it in a repo to link to specific sections). Sneak peeks for you: "By far, the most "grave" issue with the strict mode is that dynamic (at run-time) imports are not supported" "Let us walk thru why" "To perform any non-trivial optimization on dynamic languages, whole-program analysis is required." "Don't get me wrong - I absolutely love dynamic imports! As an example, the strict mode was implemented in the Pycopy dialect of Python, and of 5 not completely trivial applications written for Pycopy, 5 use dynamic imports." "There is actually yet another option to tackle dynamic imports problem - to ease restrictions" So, I feel, and share, your pain ;-). [] > Yes, I'm thinking about Python, but unless you specifically tell me > that this is a narrow special-purpose sublanguage, I'm going to assume > you want CPython to at least respect this, even if it doesn't take > advantage of it. I'd like to have a pure-python implementation running on CPython, yes. I'm not sure what you mean by "respect this". Any valid strict-mode program is also a valid normal-mode program. You can treat strict mode as a kind of type linter - it will pinpoint issues violating particular discipline (not totally insane), you fix them, and then can run without it too. > > ChrisA -- 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/2OFFDRYC6XKLKJJAJUHU2HOIGFCSYZ6B/ Code of Conduct: http://python.org/psf/codeofconduct/
