Question about import hooks

2013-11-23 Thread Ed Schofield
Hi all, 

I am the author of the ``future`` package for Python 2/3 compatibility 
(http://python-future.org). A bug report has recently been posted about its use 
of import hooks that I don't yet have an answer for, and I am looking for some 
guidance on how to customize the import mechanism in a safer way.

The current interface is as follows:

>>> from future import standard_library

Any subsequent import statements using Python 3-style module names are mapped 
onto the relevant Python 2-style names (or, where needed, backported modules 
provided by ``future``). For example, these then work in the same way on both 
Python 2 and Python 3:

>>> from http.client import HttpConnection
>>> import html.parser
>>> import queue

>>> import configparser

Although this is a nice interface, reminiscent of ``from __future__ import 
...``, the problem is that the current implementation, which appends finder 
objects to the ``sys.meta_path`` list 
(http://docs.python.org/2/library/sys.html#sys.meta_path) renders the import 
hooks globally, even for modules imported by other modules. What I want instead 
is for the import hooks to apply only to a particular module, so that a script 
containing:

from future import standard_library
import requests

would not apply the import hooks to modules imported within the ``requests`` 
module, merely to import statements in the script itself.

There is a note in the Python 3.3 documentation (and the current Python 3.4 
draft) that I had hoped would provide the answer for how to implement this:

"When calling __import__() 
(http://docs.python.org/3/library/functions.html#__import__)
as part of an import statement, the import system first checks the module 
global namespace for a function by that name. If it is not found, then the 
standard builtin __import__() 
(http://docs.python.org/3/library/functions.html#__import__)
is called."


If this were true, it would be possible to change the interface to something 
like this:

>>> from future.standard_library import __import__

which would then override the ``__import__`` function in ``builtins`` or 
``__builtin__`` affecting subsequent ``import`` statements only in that module. 
The interface wouldn't be quite as nice, but it wouldn't cause the import hooks 
to bleed into other modules that don't need them. However, the docs seem to be 
wrong; defining __import__ as a global seems to have no effect on imports in 
Py3.3, and ``future`` needs to implement this for Python 2 anyway.

Can you think of a way to implement import hooks safely, for one particular 
module, while providing a nice clean interface? Preferably this would remain 
accessible through a one-line import like ``from future import 
standard_library``.

Thanks in advance for any ideas!

Best wishes,
Ed


-- 
Dr. Edward Schofield
(M) +61 (0)405 676 229
Python Charmers
http://pythoncharmers.com


-- 
https://mail.python.org/mailman/listinfo/python-list


[Announce] Python-Future v0.13; cheatsheet for Python 2/3 compatible code

2014-08-12 Thread Ed Schofield
Hi all,

I am happy to announce an update to Python-Future for Python 2/3 compatibility 
and a new cheat-sheet for writing code compatible with both versions.

Here’s the "What’s New" page for v0.13:

http://python-future.org/whatsnew.html

Here’s the Py2/3 compatibility cheat-sheet:

http://python-future.org/compatible_idioms.html

or as a PDF:

http://python-future.org/compatible_idioms.pdf

The cheat-sheet accompanies a talk I gave at PyCon AU 2014 last weekend called 
“Writing Python 2/3 compatible code”. I will add a link to the video and slides 
from the cheat-sheet page when they are online.

I would be happy to accept pull requests for additions or changes to the Py2/3 
cheat-sheet. The source is here:


https://github.com/PythonCharmers/python-future/blob/master/docs/notebooks/Writing%20Python%202-3%20compatible%20code.ipynb

Best wishes,
Ed


--
Dr. Edward Schofield
Python Charmers
http://pythoncharmers.com

-- 
https://mail.python.org/mailman/listinfo/python-list