On Sun, Nov 30, 2008 at 05:02, Mart Somermaa <[EMAIL PROTECTED]> wrote:
> 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 a
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
Mart Somermaa wrote:
But it is not. The proposed __import__(name, submodule=True) has
a compatible interface.
Actually, it's not. Keep in mind that __import__ isn't
a particular function, it's a defined interface to a
family of functions. If that interface is extended, any
replacement __import
On Sat, 29 Nov 2008 01:56:00 pm Nick Coghlan wrote:
> Steven D'Aprano wrote:
> > Should this be reported as a documentation bug? Given the new
> > import hooks, would it be fair to say that the main reason for
> > __import__ is to use it to import a module whose name is only known
> > at runtime?
>
Guido van Rossum wrote:
> On Fri, Nov 28, 2008 at 6:56 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Steven D'Aprano wrote:
>>> Should this be reported as a documentation bug? Given the new import
>>> hooks, would it be fair to say that the main reason for __import__ is
>>> to use it to import a m
On Fri, Nov 28, 2008 at 6:56 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano wrote:
>> Should this be reported as a documentation bug? Given the new import
>> hooks, would it be fair to say that the main reason for __import__ is
>> to use it to import a module whose name is only known
Steven D'Aprano wrote:
> Should this be reported as a documentation bug? Given the new import
> hooks, would it be fair to say that the main reason for __import__ is
> to use it to import a module whose name is only known at runtime?
Only known at runtime, and for some reason you want an actual
On Sat, 29 Nov 2008 05:20:01 am Alex Martelli wrote:
> On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano <[EMAIL PROTECTED]>
wrote:
> > On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote:
> > ...
> >
> >> May I point you to the two leading underscores? The name
> >> '__import__' clearly suggest
Mart Somermaa wrote:
> But I'm still +1 for adding 'tail'/'submodule'/'tailmodule'
> argument to __import__ instead of providing an almost identical
> copy in imp.import_module().
>
> Let me know which of the approaches is desired (if any) and I'll
> add tests and update docs.
Have you considered
Mart Somermaa wrote:
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 .
Your approach complicates the interface. Every implementation of Python
and every replacement __import__ would hav
On Fri, Nov 28, 2008 at 11:07, Mart Somermaa <[EMAIL PROTECTED]> wrote:
>> 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
> htt
> 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
On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote:
> ...
>> May I point you to the two leading underscores? The name '__import__'
>> clearly suggests that the function is part of Python's internals. By
>> definition
On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote:
...
> May I point you to the two leading underscores? The name '__import__'
> clearly suggests that the function is part of Python's internals. By
> definition all attributes of the form __*__ are not meant to be used
> directly.
What about
Steven D'Aprano wrote:
However, having disagreed with your arguments, I will say this: I think
a "tail" argument to __import__ would be more elegant:
z = __import__('x.y.z', tail=True) # or submodule in your initial post
I think that it is unintuitive that __import__(x.y.z) returns module x
On Fri, 28 Nov 2008 11:59:39 pm Mart Somermaa wrote:
> 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 refere
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
Mart Somermaa wrote:
>>> 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 cert
Mart Somermaa wrote:
I meant that you have to
import sys
only to access sys.modules (i.e. importing sys may not be necessary otherwise).
I understand that, but I'm arguing that that's a non-problem. Importing
sys is a regular thing in Python, not an exception. You need sys to get
to sys
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
Mart Somermaa wrote:
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
sy
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
Mart Somermaa wrote:
__import__('foo.bar', globals(), locals(), ['baz'], -1)
>
>
> i.e. 'bar' is imported, not 'baz' (or 'ham' and not 'eggs').
You're reading it wrong. 'baz' *is* imported, but 'bar' is returned from
the function call. You will find that the import statement generates
some
Mart Somermaa wrote:
There at least two workarounds:
* the getattr approach documented in [3]
I can't comment on the rest, but the getattr seems overly complicated.
If you need just the module, what's wrong with:
__import__(modname)
modobj = sys.modules[modname]
___
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
25 matches
Mail list logo
