Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #60354 > unrolled thread

Re: Importing by file name

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Importing by file name Chris Angelico <rosuav@gmail.com> - 2013-11-24 19:07 +1100
    Re: Importing by file name Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-24 14:15 +0000
      Re: Importing by file name Chris Angelico <rosuav@gmail.com> - 2013-11-25 01:25 +1100
      Re: Importing by file name Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-24 16:30 +0000

#60354 — Re: Importing by file name

On Sun, Nov 24, 2013 at 7:00 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> The importer mechanism as far as I know only accepts module names, not
> filesystem paths; I believe this is by design.  You could imitate it by
> doing something like this:
>
> import imp
> import sys
>
> mod = imp.new_module('spam')
> exec(open('/path/to/spam.py').read(), mod.__dict__)
> sys.modules['spam'] = mod

That's a bit better than just working with a bare dictionary as I did,
but it's still getting a bit heavy-handed with the details. How is
__main__ imported? Presumably that one, at least, can be loaded from a
specific file. Or is that pure magic?

> Is 'spam' really the appropriate name for this module?  What if there is
> already a different module with the name 'spam'?  Presumably if the module
> is named 'spam' then it should be importable as 'spam', but then why the
> need for the path-based import?  Alternatively, you might name the module
> something like "</path/to/spam.py>", which surely won't collide with
> anything imported by the normal mechanism, but then what if the spam module
> is also imported by normal means?  You would end up with two copies of the
> same module with different names.

The same problem already exists with __main__ - I was hoping to
replicate that, not necessarily to solve all its problems :) I'm okay
with using a fixed name (either "__main__" or something that doesn't
collide with that), for the purposes of experimentation.

I know the recent Pythons give a lot of import power to the script.
But maybe I'm just asking too much, and some of this stuff really is
magical and implemented in C?

ChrisA

[toc] | [next] | [standalone]

#60370

On Sun, 24 Nov 2013 19:07:38 +1100, Chris Angelico wrote:

> I know the recent Pythons give a lot of import power to the script. But
> maybe I'm just asking too much, and some of this stuff really is magical
> and implemented in C?

That was the case up to 3.3, but Python 3.4 has the import machinery re-
written in pure Python (except for a tiny bit of bootstrapping machinery, 
if I understand correctly). I understand that nobody understood the 
import machinery in full (although there were a couple of people who 
understood most of it), and that moving it to Python was a Herculean job. 
If I remember correctly, it uncovered a number of undetected bugs and 
dark corners with unspecified behaviour.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#60374

On Mon, Nov 25, 2013 at 1:15 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 24 Nov 2013 19:07:38 +1100, Chris Angelico wrote:
>
>> I know the recent Pythons give a lot of import power to the script. But
>> maybe I'm just asking too much, and some of this stuff really is magical
>> and implemented in C?
>
> That was the case up to 3.3, but Python 3.4 has the import machinery re-
> written in pure Python (except for a tiny bit of bootstrapping machinery,
> if I understand correctly). I understand that nobody understood the
> import machinery in full (although there were a couple of people who
> understood most of it), and that moving it to Python was a Herculean job.
> If I remember correctly, it uncovered a number of undetected bugs and
> dark corners with unspecified behaviour.

Alright, I'll sit tight for 3.4 beta then... or maybe play with what's
currently in trunk (which is my 'python3' executable on Sikorsky). I
haven't seen anything that lets me replace the master in that way, but
there is a HUGE amount of Python's bootstrap that I have never even
peeked into.

ChrisA

[toc] | [prev] | [next] | [standalone]

#60387

On 24/11/2013 14:15, Steven D'Aprano wrote:
>
> That was the case up to 3.3, but Python 3.4 has the import machinery re-
> written in pure Python (except for a tiny bit of bootstrapping machinery,
> if I understand correctly). I understand that nobody understood the
> import machinery in full (although there were a couple of people who
> understood most of it), and that moving it to Python was a Herculean job.
> If I remember correctly, it uncovered a number of undetected bugs and
> dark corners with unspecified behaviour.
>

The import mechanism was rewritten in 3.3 see 
http://docs.python.org/3/whatsnew/3.3.html#importlib.  PEP 451 also does 
work on the import mechanism http://www.python.org/dev/peps/pep-0451/ 
This is in 3.4, see http://bugs.python.org/issue18864 and a rather long 
list of associated issues.

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web