Fredrik Lundh wrote:
> but what if I *want* to do fruity things? that's the whole
> point here: if the framework delegates imports to objects in
> the sys.path list, it's dead simple to experiment.
>
> for some reason, all counter-proposals seem to be obsessed
> with control ("don't do that" in lower or upper case, "don't
> write code that I may =3D find ugly", "we'll break your programs
> in the future if you do that", "if you cannot think of a
> string representation, you're not qualified to write custom
> importers", "all your ZIP archives must use the same name",
> etc).
>
> why are we spending this much time and effort on making things
> hard to use?
>
> if I know that I can access all modules needed by my program
> through a five-line custom importer, why do I have to invent
> a string naming scheme, make sure that scheme is unique so
> no future version of Python may mistake it for a builtin
> importer, register the importer using some function that I can
> remember the name and signature of, and pray I've understood
> the semantics.
Having listened to the arguments, and tried a few things out
myself with iu.py, I now agree with this. Importer objects on
sys.path are *very* easy to use, and nice and clean. I have no
real code myself which will break - and I concede that if others
do, they can speak for themselves.
In fact, I've gone to the other extreme. I think I'd rather see
general objects on sys.path than string subclasses. Basically,
the breakage happens sooner if someone *does* assume that sys.path
items are strings.
I'll drop out of any more discussion on this issue now...
Paul.
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