I'm trying to *use* each new feature at least once. It looks like a
multiday project <wink/sigh>. I remember reading the discussion about this
one:
[from (old!) NEWS]
> ...
> - Two changes to from...import:
>
> 1) "from M import X" now works even if M is not a real module; it's
> basically a getattr() operation with AttributeError exceptions
> changed into ImportError.
but in practice it turns out I have no idea what it means. For example,
>>> alist = []
>>> hasattr(alist, "sort")
1
>>> from alist import sort
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named alist
>>>
No, I don't want to *do* that, but the description above makes me wonder
what I'm missing.
Or, something I *might* want to do (maybe, on my worst day, and on any other
day I'd agree I should be shot for even considering it):
class Random:
def random(self): pass
def seed(self): pass
def betavariate(self): pass
# etc etc
_inst = Random()
from _inst import random, seed, betavariate # etc, etc
Again complains that there's no module named "_inst".
So if M does not in fact need to be a real module, what *does* it need to
be? Ah: sticking in
sys.modules["alist"] = alist
first does the (disgusting) trick.
So, next gripe: I don't see anything about this in the 2.1a2 docs, although
the Lang Ref's section on "the import statement" has always been vague
enough to allow it. The missing piece: when the Lang Ref says something is
"implementation and platform specific", where does one go to find out what
the deal is for your particular implementation and platform?
guess-not-to-NEWS<wink>-ly y'rs - tim
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