[issue17177] Document/deprecate imp

[Brett Cannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

Changes by Brett Cannon :


--
dependencies: +Move imp.reload() to importlib

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

Changes by Brett Cannon :


--
dependencies: +Move imp.get_magic() to importlib

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Ezio Melotti]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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 things are now deprecated. That way  users of imp 
could just do::

with warnings.catch_warnings():
warnings.simplefilter("ignore")
import imp

and be done with it. This means still striving to deprecate every function in 
imp so that it can all be replaced with a single module-level deprecation is a 
reasonable goal to have.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

Changes by Brett Cannon :


--
dependencies: +Deprecate imp.new_module() in favour of types.ModuleType

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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
* cache_from_source(): relocate
* source_from_cache(): relocate
* get_tag(): deprecate
* lock_held()/acquire_lock()/release_lock(): deprecate
* NullImporter: deprecate

Everything else can stay undocumented as-is (deprecated or simply exposed 
through _imp which can stay undocumented).

I plan to make individual issues for these things as I solidify the decision of 
how to handle them.

--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[R. David Murray]

R. David Murray added the comment:

Should we back out that module level deprecation notice for the moment, then?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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 full-on yet. While it's documented as 
such, not all functionality has moved over to importlib, only bits and pieces.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[STINNER Victor]

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 constants, to be able to build my module even if executing the module 
fails (ex: because of a runtime dependency). I don't know how to change my code 
to use imp.load_source().

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[R. David Murray]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

Changes by Brett Cannon :


--
dependencies: +Deprecate imp.find_module()/load_module()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Ezio Melotti]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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 don't see how I can justify raising a 
DeprecationWarning for the whole thing.

But it's gone in Python 4. =)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Ezio Melotti]

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 imp would affect the somewhat popular imp.reload(), 
that has already been moved for Python 3, and will now be moved again (this 
also means that the -3 warnings on 2.7 will no longer be valid).

--
nosy: +ezio.melotti
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Éric Araujo]

É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 with the other VMs be a good idea?

--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17177] Document/deprecate imp

[Brett Cannon]

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()
  - cache_from_source()
* From sys
  - get_tag()
* Platform-implemented
  - lock_held()
  - acquire_lock()
  - release_lock()
  - Undocumented stuff related to builtins, frozen, and load_dynamic()
* Helper
  - reload()

The question is what to keep/expose in imp and what to deprecate. Basically I 
need to figure out what imp's role is supposed to be in the face of importlib. 
My gut says either expose platform-dependent stuff and reload() and move the 
rest to importlib/deprecate, or to completely do away with the module and force 
people to use the APIs in importlib for consistency (and to stop people from 
mucking around with import from outside of importlib).

--
assignee: brett.cannon
components: Library (Lib)
messages: 181849
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Document/deprecate imp
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com