On 10/29/2015 12:30 PM, Paul Moore wrote:
On 29 October 2015 at 18:45, Donald Stufft <don...@stufft.io> wrote:
So I don=E2=80=99t think it=E2=80=99s true that people don=E2=80=99t shad=
ow the standard library, they just have various ways to do it that have s=
everal gotchas and require people to generally hack around the limitation=
.=C2=A0
(Your mailer or mine seems to have gone weird with encoding...)
There's a difference between the opting into using (say) pdb++ at
runtime, and at install time. The problem with the sort of shadowing
eggs did (and people try to emulate) is that simply *installing* a
package changes the behaviour of programs that don't use that package,
by virtue of the fact that it's there at all.
I'd much rather pdb++ or anything similar allowed the user to opt in
on demand. For example, it could put a file pdb.py containing "from
pdbpp import *" into a subdirectory, and direct users who want to
replace pdb with pdbpp to add that directory to PYTHONPATH. Just don't
do that at install time, leaving the user needing to uninstall pdbpp
to opt out of the behaviour.
As I said, I'm not against people being *able* to shadow the stdlib, I
just don't want to see it being *easy*, nor do I want it to be the
norm.
Paul
PS My experience with a similar case is pyreadline on Windows, which
hooks into the stdlib readline functionality when installed. That's a
PITA, because mostly I don't want pyreadline (I prefer the default
Windows command line editing, despite it having less functionality)
but I want pyreadline when using ipython. There's no way for me to get
that behaviour because (py)readline is enabled by installing it, not
by user choice at runtime.
+1
Although, I wouldn't mind if it were easy & documented, like say having
both shadow-packages before stdlib and site-packages after it, so that
multiple, super-tricky and annoying ways of doing the shadowing were not
needed. But, say, packages shadow-packages would only be used if there
were an extra directive somewhere to enable it, or a subset of the
packages that reside there.
Glenn
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
