Brett Cannon wrote:
> The old-hands on python-dev know this is where I plug my import
> rewrite vaporware. It will be in 3.1, and as part of it there will be
> a new API for handling direct imports. Jacob Kaplan-Moss and I have
Sounds good. I can finally rest in peace :) . May I suggest
that y
> If __import__ was replaced with a version with NON compatible interface,
> "import x.y.z" would break.
But it is not. The proposed __import__(name, submodule=True) has
a compatible interface. All tests pass with
http://bugs.python.org/file12136/issue4438.diff .
As for the imp approach, I've al
Nick Coghlan wrote:
As Hrvoje has pointed out, 'sys' is part of the internal interpreter
machinery - it's there as soon as the interpreter starts. The import
call for it just grabs it out of the module cache and creates a
reference to it in the current namespace.
I understand that, but
Explici
The variant proposed by Hrvoje Niksic:
>>> __import__(modname)
>>> mod = sys.modules[modname]
looks more appealing, but comes with the drawback that sys has to be
imported for that purpose only.
That is not a real drawback, as "sys" will certainly be present in the
system, so the "importin
Nick Coghlan wrote:
i.e.
"from foo.bar import baz" >
= __import__('foo.bar', globals(), locals(), ['baz'], -1)
baz = .baz
When there are multiple names being imported or an 'as' clause is
involved, I hope the reasons for doing it this way become more obvious:
"from foo.bar import baz, bo
Python programmers need to dynamically load submodules instead of
top-level modules -- given a string with module hierarchy, e.g.
'foo.bar.baz', access to the tail module 'baz' is required instead
of 'foo'.
Currently, the common hack for that is to use
modname = 'foo.bar.baz' mod = __import__(m
When I looked through that list a week or so ago, I noticed that some
issues were obviously related to the Python distribution itself, but
others were appeared to be Python application problems.
I looked through the list now and weeded out irrelevant CVEs (by putting them
into
the ignore list
I created a script that parses the
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=python
Python-related CVE list and classifies the CVEs as follows:
* "ok" -- CVE has references to bugs.python.org
* "warnings" -- CVE has references to Python SVN revisions
or an issue in bugs.python.org refers
Hello!
Does someone systematically track the CVE vulnerability list?
Ideally, Python security officers would have close collaboration with
whoever
manages CVE (like distribution security officers do), so that
* every CVE issue would have a corresponding ticket on Python bug tracker
(perhaps
