On Wed, Dec 2, 2020 at 2:53 AM Paul Sokolovsky <pmis...@gmail.com> wrote:
>
> Hello,
>
> On Wed, 2 Dec 2020 02:39:38 +1100
> Chris Angelico <ros...@gmail.com> wrote:
>
> > On Wed, Dec 2, 2020 at 2:29 AM Paul Sokolovsky <pmis...@gmail.com>
> > wrote:
> > > def fun():
> > > # Imports are not allowed at run-time
> > > import mod2
> > > # But you can re-import module previously imported at
> > > import-time. import mod
> >
> > Wait, what? No. No no no. Please do not do ANYTHING like this. Having
> > suffered under JavaScript's highly restrictive import system (and
> > actually been glad for it, since the alternative is far worse), I do
> > not want ANY version of Python to give up the full power of its import
>
> Then it's luck that ALL versions and dialects of Python aren't under
> your control ;-).
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, but that's not a language feature
- that's a partial implementation that sacrifices the parts it can't
afford to do. From the sound of your proposal, this should be part of
the main Python language and be a normal expectation of code.
> > system, including the ability for a module to be imported only when
> > it's actually needed. Imports inside functions allow a program to have
> > optional dependencies, or dependencies that might be slow to load (eg
> > numpy), and without that, even running your script with "--help" has
> > to process every single import in the entire file.
>
> But didn't you you already spotted a line which says that the strict
> mode also aspires to improve on the Python module practices? Under
> strict mode's firm but benevolent rule, there won't be slowly-loading
> modules any more. All imports will be fast. And modules which want to be
> slow will do that in their module.init() function.
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), and partly because two-phase initialization is
something Python tries hard to avoid. You don't get code like this:
f = file("/path/to/file")
f.open()
db = psycopg2.database("postgresql://user@localhost/dbname")
db.connect()
Two-phase initialization means that everything in that module (or
class, as the case may be) has to first check if it's been
initialized. Why not just initialize it when you create the object?
Why not just initialize when you import the module?
How much do you really gain by forcing this? You get stub modules
everywhere that aren't initialized yet, but have to be imported just
to satisfy this restriction. Current code simply... doesn't import it.
> I also forgot to mention very important point in the intro: when you
> read this proposal, please don't think about "CPython". That for sure
> will send you the wrong vibes. Think about "Python". ;-)
>
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.
ChrisA
_______________________________________________
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/NDC4BBHOUJ66PCBIGUBVLQND7HZPGIEC/
Code of Conduct: http://python.org/psf/codeofconduct/
