On Fri, Jun 02, 2017 at 12:36:59PM +1000, Chris Angelico wrote:
[...]
> > I expect that moving '' to the end of sys.path will be a less disruptive
> > change than removing it.
>
> This is true. However, anything that depends on the current behaviour
> (intentionally or otherwise) would be just as broken as if it were
> removed,
I don't think we've agreed that the current behaviour is broken. I
think we agree that:
- it is unfortunate when people accidentally shadow the stdlib;
- it is a feature to be able to intentionally shadow the stdlib.
I believe that it is also a feature for scripts to be able to depend on
resources in their directory, including other modules. That's the
current behaviour. I don't know if you agree, but if you want to argue
that's "broken", you should do so explicitly.
Broken or not, removing '' from the sys.path will break scripts that
expect to import modules in their directory. So even if we conclude that
the current behaviour is broken, we still need a deprecation period.
How about... ?
- in 3.7, we add a pair of command line flags, let's say:
--script-directory # add '' to sys.path when running scripts
--no-script-directory # don't add '' to sys.path
with the default remaining to add it
- add a warning to 3.7 whenever you import a module from ''
- in 3.9, we move '' to the end of sys.path instead of the start
- and in 3.9, the default changes to not adding '' to sys.path unless
explicitly requested.
Alternatively, we could use a single flag:
--script-directory-location=FIRST|LAST|NONE
> and it's still possible for "import foo" to mean a local
> import today and a stdlib import tomorrow.
Of course -- that's the downside of any search path. Without a
central authority to allocate library names, how do you deal with
name conflicts? Any library can clash with any other library, all you
can do is choose the order in which clashes are resolved.
The advantage of moving '' to the end is that shadowing the stdlib
becomes an affirmative, deliberate act, rather than something easy to do
by accident. Experts who want to shadow a stdlib module can be assumed
to be able to cope with the consequences of moving '' back to the front
(or whatever technique they use to shadow a module).
The disadvantage is that now the std lib can shadow your modules! Naive
users will instead find the std lib shadowing *their* modules, which
will be no less mysterious when it happens, but at least you can't
break things by shadowing a module you don't directly import.
E.g. you import A, which requires B, but you've shadowed B, and now A
is broken. That's an especially frustrating error for beginners to
diagnose, even with help. Moving '' to the end of the path will, I
think, all but eliminate that sort of shadowing error.
> It'd just move the
> ambiguity around; instead of not being sure if it's been accidentally
> shadowed, instead you have to wonder if your code will break when a
> future Python version adds a new stdlib module.
You don't have to wonder. You just have to read the What's New document.
Your code can also break if you install a third-party library which
(accidentally?) shadows the std lib, or another library which you rely
on. There are only so many short, descriptive library names, and any
time anyone (std lib or not) uses one, it risks clashing with somebody
else's use of the same name.
> Or your code could
> break because someone pip-installs a third-party module. You can take
> your pick which thing shadows which by choosing where you place '' in
> sys.path, but there'll always be a risk one way or another.
Indeed.
> Different packages don't conflict with each other because
> intra-package imports are explicit. They're safe.
Unless the package shadows another package of the same name.
By the way, to give you an idea of how hairy this can get, there was a
recent bug report (now closed) complaining that intra-package imports
can shadow each other:
spam/
+-- __init__.py
+-- eggs/
+-- __init__.py
+-- cheese
+-- eggs.py
Inside spam, the eggs.py module shadows the eggs subdirectory and makes
it impossible to reach eggs.cheese.
(Or perhaps the other way -- I don't think the language guarantees one
way or the other.)
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
