Guido van Rossum wrote:
>> Then you're proposing a way for a highly knowledgable user to
>> anticipate, and partially worm around, that Python leaves behind
>> insane module objects in sys.modules. Wouldn't it be better to
>> change Python to stop leaving insane module objects in sys.modules
>> to begin with? That's harder, but seems to me it would do a lot
>> more good for a lot more people.
>
> +1
OK - the problem as I see it is that a given …
[View More]module that exists, but
raises ImportError, only raises ImportError *once*, whereas it really
should raise ImportError every time i.e. currently doing the following:
# a.py
raise ImportError
# b.py
try:
import a
except ImportError:
import a
print 'OK'
prints when it really should raise ImportError.
Additionally, a module could have messed with sys.modules directly, so
just putting None in for the broken module wouldn't be sufficient (you
could possibly get the broken module via another name).
Perhaps the import machinery could keep a (weak?) mapping from module
*object* to the ImportError it raised. If the module that would be
returned by the import is in the mapping, raise the corresponding
ImportError instead. The appropriate line, etc in the module would thus
be shown each time the module was imported.
I believe this would work properly for reload() as well.
Tim Delaney
[View Less]
I have added some documentation to msi.py, please let me know if
something is still missing.
I have also rearranged the versioning. msi.py now supports two
"product lines": snapshots, and releases. Snapshots can be generated
by anybody, whereas releases are only published by python.org.
Each line has their own ProductVersion scheme: snapshots use
major.minor.currentday; official releases use the version from the
Python DLL. The relevant information is now extracted from
patchlevel.h.
…
[View More]Accordingly, there is no need to specify current_version anymore
in config.py, and the "alpha" setting has been renamed to "snapshot".
Regards,
Martin
[View Less]