Changes by Brett Cannon br...@python.org:
--
dependencies: +Move imp.get_magic() to importlib
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Changes by Brett Cannon br...@python.org:
--
dependencies: +Move imp.reload() to importlib
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Brett Cannon added the comment:
There should now be issues for each of the required relocations to make imp
redundant.
--
dependencies: +Move imp.source_from_cache/cache_from_source to importlib
___
Python tracker rep...@bugs.python.org
Brett Cannon added the comment:
Just to keep on top of what is left to do for this to happen:
* get_magic(): expose in importlib
* find_module()/load_module(): eliminate all uses in the stdlib and fully
deprecate
* new_module(): use types.ModuleType() instead
* reload(): relocate
*
Changes by Brett Cannon br...@python.org:
--
dependencies: +Deprecate imp.new_module() in favour of types.ModuleType
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Brett Cannon added the comment:
While thinking about asking on G+ for feedback, I realized that if I get this
to the point of a module-level warning, it won't be a big deal. It would be
just like warnings you deal with when supporting old versions of Python along
with newer versions where
Ezio Melotti added the comment:
This might be OK, however you won't be able to point to the alternatives in the
deprecation message (e.g. new_module() is deprecated, use types.ModuleType()
instead).
This can still be done in the docs though.
--
___
Brett Cannon added the comment:
Right, the docs would say the imp modules is deprecated; please see the module
documentation for alternatives or something.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Brett Cannon added the comment:
The deprecation warnings for the explicitly deprecated functions already have
the instructions on how to port. A note could probably be added to turn on
deprecation warnings if one needs help with moving code over.
But the deprecation isn't even officially
R. David Murray added the comment:
Should we back out that module level deprecation notice for the moment, then?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Brett Cannon added the comment:
Nah, consider it motivation for me to get it done in Python 3.4 else I have to
back it out before release.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
R. David Murray added the comment:
The documentation deprecation has been added as part of issue 17135.
Leaving this open to address Ezio's last comment.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
If the imp module is marked as deprecated, it would help to explain how to port
code from imp to importlib. As it was done for os.spawn(), platform.popen(),
etc.
I'm using imp.load_source() in my setup.py to load a version.py file which only
contains
STINNER Victor added the comment:
I don't know how to change my code to use imp.load_source().
Woops, I mean to use importlib.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Changes by Brett Cannon br...@python.org:
--
dependencies: +Deprecate imp.find_module()/load_module()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17177
___
Éric Araujo added the comment:
I’ve always perceived imp as an implementation detail of the import system that
people were sometimes forced to use to get to some things. Now that we have
importlib, deprecating (with a nice long compatibility-with-warnings period)
sounds good.
Would checking
Brett Cannon added the comment:
Checking with the other VMs wouldn't benefit anyone. They still have to
implement whatever is necessary from _imp in order for importlib to work.
Otherwise it's just another stdlib module.
--
___
Python tracker
Ezio Melotti added the comment:
Basically I need to figure out what imp's role is supposed to be in the face
of importlib.
If it's not even clear for you, even if you eventually figure that out, having
two import-related modules is likely to be confusing for users.
OTOH deprecating/removing
Brett Cannon added the comment:
I would probably document the deprecation but otherwise leave it alone at the
module level. Considering I only documented imp.find_module() and
.load_module() as documented thanks to their funky interfaces making nearly
impossible to do a direct translation I
Ezio Melotti added the comment:
If you move them to importlib and just leave an alias in imp, you should still
add a DeprecationWarning IMHO, even if you plan to remove them in Python 4.
--
___
Python tracker rep...@bugs.python.org
New submission from Brett Cannon:
I need a make a decision as to what (if anything) belongs in imp and then
document what stays and deprecate everything else.
Everything in imp falls into one of the following categories:
* From importlib
- get_magic()
- source_from_cache()
-
22 matches
Mail list logo
