This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: smart module import
Type: enhancement Stage:
Components: None Versions:
process
Status: closed Resolution: later
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: christian.heimes, david_abrahams, georg.brandl
Priority: normal Keywords:

Created on 2001-11-30 16:09 by david_abrahams, last changed 2022-04-10 16:04 by admin. This issue is now closed.

Messages (4)
msg61073 - (view) Author: David Abrahams (david_abrahams) Date: 2001-11-30 16:09
In my work on Boost.Python (www.boost.org) a colleague 
suggested the implementation of "cross-module 
overloading". Boost.Python allows function overloading 
within a module or class as a way of reflecting the 
structure of the C++ program being wrapped. That 
means, for example, that in:

  import MyExtensionModule
  MyExtensionModule.f("hello there")
  MyExtensionModule.f(42) 
  MyExtensionModule.f("this", "way", "please")

The invocations of f() might all call different 
functions.

How would this work "cross-module"?

    from MyExtension1 import f
    from MyExtension2 import f

    f(42)      # calls MyExtension1.f
    f("hello") # calls MyExtension2.f

We can't do this right now because the second import 
will unconditionally overwrite the current definition 
of f. I propose that we give the modules some control 
over what happens when their names are imported into 
an existing namespace. If that were possible, the 
second import might notice that there was already a 
callable object named "f" and replace the name being 
imported with some collection of functions which 
implemented the overloading (that's how the single-
module overloading mechanism works now).

So, as a straw man, let me propose a syntax. If a 
module defines an __import__ function as follows:

   __import__(source-module, source-name, target-
module, target-name)

it will be called for each name being imported from 
that module into another. In other words, source-
module will always be the module in which the 
__import__ function is defined, and target-module will 
be the module into which the names are being imported. 
source-name is distinguished from target-name in order 
to support "from Module import A as B".

-- 
===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org) 
          email: david.abrahams@rcn.com
===================================================
msg61281 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-01-20 12:29
Chris, is this something that could be done with your post-import hooks?
msg61292 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-20 13:56
It is possible to re-use post import hooks for the purpose but really,
this is a job for PEP 3124 "Overloading, Generic Functions, Interfaces,
and Adaptation".
msg61295 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-01-20 14:11
I agree. In any case, this issue will be handled by one of the PEPs.
History
Date User Action Args
2022-04-10 16:04:42adminsetgithub: 35637
2008-01-20 14:11:18georg.brandlsetstatus: open -> closed
resolution: later
messages: + msg61295
2008-01-20 13:56:46christian.heimessetmessages: + msg61292
2008-01-20 12:29:24georg.brandlsetassignee: christian.heimes
messages: + msg61281
nosy: + georg.brandl, christian.heimes
2001-11-30 16:09:53david_abrahamscreate