Moore, Paul wrote:
> > A) Stick with strings. Hooks can be implemented by subclassing str.
> > This is great for hooks written in Python, but subclassing str
> > in C is not straightforward. Things can still break, though: eg.
> > os.path.basename(strsubinst) will return a regular string, not an
> > instance of the subclass; might be an issue.
> >
> > B) Allow arbitrary objects on sys.path. Hooks are then easier to
> > write (in C), but some code breakage will occur. The std library we
> > can fix (if needed), but third-party code might break.
> >
> > I would very much prefer B, but if it turns out that we can't break
> > the string assumption, I'd still be happy with A (rather that than
> > nothing!).
>
> As I say above, I prefer (A) of these two. But in practice, I don't
> see the problem with Gordon's metapath approach. Equivalently, every
> element of sys.path must be a string, and there is a dictionary mapping
> sys.path elements to Owner instances (if it helps, you can say that if
> the dictionary doesn't contain a particular element as a key, it can be
> treated as a normal directory). The advantage is that we stick to pure
> strings, not string subclasses...
What's the advantage of banning string subclasses? What's so bad about lifting
limitations?
> > Regarding PYTHONPATH and sys.path.append("/path/to/my/archive.zip"):
> > for now I'd suggest that the sys.path traversing code checks
> > for a .zip extension, and replace the item with a zipimporter
> > instance. This check can be very cheap. Later we could add a general
> > extension-checking feature, where one could register an import hook
> > for a specific extension. This might be a case of YAGNI, though...
>
> Is this check going to happen whenever sys.path gets changed? If so,
> how do you trap that?
It's trapped every single time sys.path is traversed. It's a very cheap test.
> And yes, I very definitely need a way of registering a user-defined
> hook for path entries (and not always based on extension!!!) Imagining
> a hook to handle something like "http://my.repository/python/" on
> sys.path is not hard, or unreasonable... (Security considerations aside).
That would be way cool! But let's please not try to do too much *now*; let's get
zipimport going and see from there.
Just
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