Paul Moore wrote:
> > - If a path entry ends in ".zip", replace that entry with
> > a zipimporter instance. (obviously, the zipimport module
> > must be available for this to work.)
>=20
> This seems like a gross hack. How do I write a similar hook for
> strings ending in ".tar"? This isn't a YAGNI, it's a design
> constraint which I don't believe is reasonable.
"Let's make it *really* easy to use zip archives, and reasonably =
easy
to use other custom importers."
really easy:
import mymodule
reasonably easy: =20
import sys
# manipulate path as necessary
for index, path in enumerate(sys.path):
if isinstance(path, string) and path.endswith(".tar"):
sys.path[index] =3D tarimporter(path)
import mymodule, ...
if you think otherwise, please provide use cases. the implied "there =
will be
a separate category of people who provide hooks and repackage existing
programs without having access to source code for any part of the =
program
or the standard library" case is totally bogus, and so is the "there =
will be
programs that add importers to the path without knowing what they add"
case.
> >import.c changes:
> > - Allow arbitrary objects on sys.path.
>=20
> I still have reservations about this. Code will break... (if you
> mean "string subclasses", then I feel slightly better about it)
that's not much of an argument: fragile code will only break if *you* =
add
non-string objects to the path in *your* programs.
if you don't want your programs to break, don't break them (or fix the
breakage).
</F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4