making the import machinery explicit

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

making the import machinery explicit

Brett Cannon-2
To start off, what I am about to propose was brought up at the PyCon language summit and the whole room agreed with what I want to do here, so I honestly don't expect much of an argument (famous last words).

In the "ancient" import.c days, a lot of import's stuff was hidden deep in the C code and in no way exposed to the user. But with importlib finishing PEP 302's phase 2 plans of getting imoprt to be properly refactored to use importers, path hooks, etc., this need no longer be the case.

So what I propose to do is stop having import have any kind of implicit machinery. This means sys.meta_path gets a path finder that does the heavy lifting for import and sys.path_hooks gets a hook which provides a default finder. As of right now those two pieces of machinery are entirely implicit in importlib and can't be modified, stopped, etc.

If this happens, what changes? First, more of importlib will get publicly exposed (e.g. the meta path finder would become public instead of private like it is along with everything else that is publicly exposed). Second, import itself technically becomes much simpler since it really then is about resolving module names, traversing sys.meta_path, and then handling fromlist w/ everything else coming from how the path finder and path hook work.

What also changes is that sys.meta_path and sys.path_hooks cannot be blindly reset w/o blowing out import. I doubt anyone is even touching those attributes in the common case, and the few that do can easily just stop wiping out those two lists. If people really care we can do a warning in 3.3 if they are found to be empty and then fall back to old semantics, but I honestly don't see this being an issue as backwards-compatibility would just require being more careful of what you delete (which I have been warning people to do for years now) which is a minor code change which falls in line with what goes along with any new Python version.

And lastly, sticking None in sys.path_importer_cache would no longer mean "do the implicit thing" and instead would mean the same as NullImporter does now (which also means import can put None into sys.path_importer_cache instead of NullImporter): no finder is available for an entry on sys.path when None is found. Once again, I don't see anyone explicitly sticking None into sys.path_importer_cache, and if they are they can easily stick what will be the newly exposed finder in there instead. The more common case would be people wiping out all entries of NullImporter so as to have a new sys.path_hook entry take effect. That code would instead need to clear out None on top of NullImporter as well (in Python 3.2 and earlier this would just be a performance loss, not a semantic change). So this too could change in Python 3.3 as long as people update their code like they do with any other new version of Python.

In summary, I want no more magic "behind the curtain" for Python 3.3 and import: sys.meta_path and sys.path_hooks contain what they should and if they are emptied then imports will fail and None in sys.path_importer_cache means "no finder" instead of "use magical, implicit stuff".

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Eric Snow-2
On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon <[hidden email]> wrote:

> To start off, what I am about to propose was brought up at the PyCon
> language summit and the whole room agreed with what I want to do here, so I
> honestly don't expect much of an argument (famous last words).
>
> In the "ancient" import.c days, a lot of import's stuff was hidden deep in
> the C code and in no way exposed to the user. But with importlib finishing
> PEP 302's phase 2 plans of getting imoprt to be properly refactored to use
> importers, path hooks, etc., this need no longer be the case.
>
> So what I propose to do is stop having import have any kind of implicit
> machinery. This means sys.meta_path gets a path finder that does the heavy
> lifting for import and sys.path_hooks gets a hook which provides a default
> finder. As of right now those two pieces of machinery are entirely implicit
> in importlib and can't be modified, stopped, etc.
>
> If this happens, what changes? First, more of importlib will get publicly
> exposed (e.g. the meta path finder would become public instead of private
> like it is along with everything else that is publicly exposed). Second,
> import itself technically becomes much simpler since it really then is about
> resolving module names, traversing sys.meta_path, and then handling fromlist
> w/ everything else coming from how the path finder and path hook work.
>
> What also changes is that sys.meta_path and sys.path_hooks cannot be blindly
> reset w/o blowing out import. I doubt anyone is even touching those
> attributes in the common case, and the few that do can easily just stop
> wiping out those two lists. If people really care we can do a warning in 3.3
> if they are found to be empty and then fall back to old semantics, but I
> honestly don't see this being an issue as backwards-compatibility would just
> require being more careful of what you delete (which I have been warning
> people to do for years now) which is a minor code change which falls in line
> with what goes along with any new Python version.
>
> And lastly, sticking None in sys.path_importer_cache would no longer mean
> "do the implicit thing" and instead would mean the same as NullImporter does
> now (which also means import can put None into sys.path_importer_cache
> instead of NullImporter): no finder is available for an entry on sys.path
> when None is found. Once again, I don't see anyone explicitly sticking None
> into sys.path_importer_cache, and if they are they can easily stick what
> will be the newly exposed finder in there instead. The more common case
> would be people wiping out all entries of NullImporter so as to have a new
> sys.path_hook entry take effect. That code would instead need to clear out
> None on top of NullImporter as well (in Python 3.2 and earlier this would
> just be a performance loss, not a semantic change). So this too could change
> in Python 3.3 as long as people update their code like they do with any
> other new version of Python.
>
> In summary, I want no more magic "behind the curtain" for Python 3.3 and
> import: sys.meta_path and sys.path_hooks contain what they should and if
> they are emptied then imports will fail and None in sys.path_importer_cache
> means "no finder" instead of "use magical, implicit stuff".

This is great, Brett.  About sys.meta_path and sys.path_hooks, I see
only one potential backwards-compatibility problem.

Those implicit hooks were fallbacks, effectively always at the end of
the list, no matter how you manipulated the them.  Code that appended
onto those lists would now have to insert the importers/finders in the
right way.  Otherwise the default hooks would be tried first, which
has a good chance of being the wrong thing.

That concern aside, I'm a big +1 on your proposal.

-eric
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Paul Moore
In reply to this post by Brett Cannon-2
On 14 April 2012 21:03, Brett Cannon <[hidden email]> wrote:
> So what I propose to do is stop having import have any kind of implicit
> machinery. This means sys.meta_path gets a path finder that does the heavy
> lifting for import and sys.path_hooks gets a hook which provides a default
> finder.

+1 to your proposal. And thanks for all of your work on importlib - it
makes me very happy to see the ideas Just and I thrashed out in PEP
302 come together fully at last.

Paul.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Brett Cannon-2
In reply to this post by Eric Snow-2


On Sat, Apr 14, 2012 at 17:12, Eric Snow <[hidden email]> wrote:
On Sat, Apr 14, 2012 at 2:03 PM, Brett Cannon <[hidden email]> wrote:
> To start off, what I am about to propose was brought up at the PyCon
> language summit and the whole room agreed with what I want to do here, so I
> honestly don't expect much of an argument (famous last words).
>
> In the "ancient" import.c days, a lot of import's stuff was hidden deep in
> the C code and in no way exposed to the user. But with importlib finishing
> PEP 302's phase 2 plans of getting imoprt to be properly refactored to use
> importers, path hooks, etc., this need no longer be the case.
>
> So what I propose to do is stop having import have any kind of implicit
> machinery. This means sys.meta_path gets a path finder that does the heavy
> lifting for import and sys.path_hooks gets a hook which provides a default
> finder. As of right now those two pieces of machinery are entirely implicit
> in importlib and can't be modified, stopped, etc.
>
> If this happens, what changes? First, more of importlib will get publicly
> exposed (e.g. the meta path finder would become public instead of private
> like it is along with everything else that is publicly exposed). Second,
> import itself technically becomes much simpler since it really then is about
> resolving module names, traversing sys.meta_path, and then handling fromlist
> w/ everything else coming from how the path finder and path hook work.
>
> What also changes is that sys.meta_path and sys.path_hooks cannot be blindly
> reset w/o blowing out import. I doubt anyone is even touching those
> attributes in the common case, and the few that do can easily just stop
> wiping out those two lists. If people really care we can do a warning in 3.3
> if they are found to be empty and then fall back to old semantics, but I
> honestly don't see this being an issue as backwards-compatibility would just
> require being more careful of what you delete (which I have been warning
> people to do for years now) which is a minor code change which falls in line
> with what goes along with any new Python version.
>
> And lastly, sticking None in sys.path_importer_cache would no longer mean
> "do the implicit thing" and instead would mean the same as NullImporter does
> now (which also means import can put None into sys.path_importer_cache
> instead of NullImporter): no finder is available for an entry on sys.path
> when None is found. Once again, I don't see anyone explicitly sticking None
> into sys.path_importer_cache, and if they are they can easily stick what
> will be the newly exposed finder in there instead. The more common case
> would be people wiping out all entries of NullImporter so as to have a new
> sys.path_hook entry take effect. That code would instead need to clear out
> None on top of NullImporter as well (in Python 3.2 and earlier this would
> just be a performance loss, not a semantic change). So this too could change
> in Python 3.3 as long as people update their code like they do with any
> other new version of Python.
>
> In summary, I want no more magic "behind the curtain" for Python 3.3 and
> import: sys.meta_path and sys.path_hooks contain what they should and if
> they are emptied then imports will fail and None in sys.path_importer_cache
> means "no finder" instead of "use magical, implicit stuff".

This is great, Brett.  About sys.meta_path and sys.path_hooks, I see
only one potential backwards-compatibility problem.

Those implicit hooks were fallbacks, effectively always at the end of
the list, no matter how you manipulated the them.  Code that appended
onto those lists would now have to insert the importers/finders in the
right way.  Otherwise the default hooks would be tried first, which
has a good chance of being the wrong thing.

That concern aside, I'm a big +1 on your proposal.

Once again, it's just code that needs updating to run on Python 3.3 so I don't view it as a concern. Going from list.append() to list.insert() (even if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Eric Snow-2
On Sat, Apr 14, 2012 at 4:16 PM, Brett Cannon <[hidden email]> wrote:
> Once again, it's just code that needs updating to run on Python 3.3 so I
> don't view it as a concern. Going from list.append() to list.insert() (even
> if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.

I'm fine with that.  It's not a big deal either way, especially with
how few people it directly impacts.

-eric
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Matt Joiner
In reply to this post by Brett Cannon-2

+1! Thanks for pushing this.

On Apr 15, 2012 4:04 AM, "Brett Cannon" <[hidden email]> wrote:
To start off, what I am about to propose was brought up at the PyCon language summit and the whole room agreed with what I want to do here, so I honestly don't expect much of an argument (famous last words).

In the "ancient" import.c days, a lot of import's stuff was hidden deep in the C code and in no way exposed to the user. But with importlib finishing PEP 302's phase 2 plans of getting imoprt to be properly refactored to use importers, path hooks, etc., this need no longer be the case.

So what I propose to do is stop having import have any kind of implicit machinery. This means sys.meta_path gets a path finder that does the heavy lifting for import and sys.path_hooks gets a hook which provides a default finder. As of right now those two pieces of machinery are entirely implicit in importlib and can't be modified, stopped, etc.

If this happens, what changes? First, more of importlib will get publicly exposed (e.g. the meta path finder would become public instead of private like it is along with everything else that is publicly exposed). Second, import itself technically becomes much simpler since it really then is about resolving module names, traversing sys.meta_path, and then handling fromlist w/ everything else coming from how the path finder and path hook work.

What also changes is that sys.meta_path and sys.path_hooks cannot be blindly reset w/o blowing out import. I doubt anyone is even touching those attributes in the common case, and the few that do can easily just stop wiping out those two lists. If people really care we can do a warning in 3.3 if they are found to be empty and then fall back to old semantics, but I honestly don't see this being an issue as backwards-compatibility would just require being more careful of what you delete (which I have been warning people to do for years now) which is a minor code change which falls in line with what goes along with any new Python version.

And lastly, sticking None in sys.path_importer_cache would no longer mean "do the implicit thing" and instead would mean the same as NullImporter does now (which also means import can put None into sys.path_importer_cache instead of NullImporter): no finder is available for an entry on sys.path when None is found. Once again, I don't see anyone explicitly sticking None into sys.path_importer_cache, and if they are they can easily stick what will be the newly exposed finder in there instead. The more common case would be people wiping out all entries of NullImporter so as to have a new sys.path_hook entry take effect. That code would instead need to clear out None on top of NullImporter as well (in Python 3.2 and earlier this would just be a performance loss, not a semantic change). So this too could change in Python 3.3 as long as people update their code like they do with any other new version of Python.

In summary, I want no more magic "behind the curtain" for Python 3.3 and import: sys.meta_path and sys.path_hooks contain what they should and if they are emptied then imports will fail and None in sys.path_importer_cache means "no finder" instead of "use magical, implicit stuff".

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Nick Coghlan
In reply to this post by Brett Cannon-2
Hooray for finally having this to the point where it has been pushed to trunk :)

On Sun, Apr 15, 2012 at 8:16 AM, Brett Cannon <[hidden email]> wrote:
> Once again, it's just code that needs updating to run on Python 3.3 so I
> don't view it as a concern. Going from list.append() to list.insert() (even
> if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.

I'm not sure you can so blithely wave away the "check this before the
standard hooks" problem. If the recommended approach becomes to insert
new hooks at the *start* of path_hooks and meta_path, then that should
work fairly well, since the new additions will take precedence
regardless of what other changes have already been made. However,
trying to be clever and say "before the standard hooks, but after
everything else" is fraught with peril, since there may be hooks
present in the lists *after* the standard ones so naive counting
wouldn't work.

As far as the guidelines for managing the import state go, it may be
worth having public "importlib.default_path_hooks" and
"importlib.default_meta_path" attributes.

Then "clearing" the hooks would just be a matter of resetting them
back to defaults: "sys.path_hooks[:] = importlib.default_path_hooks".
You could also locate them in the hooks list correctly by checking
"for i, hook in enumerate(sys.path_hooks): if hook is
importlib.default_path_hooks[0]: break"

Alternatively, it may be simpler to just expose a less granular
"reset_import_hooks()" function that restores meta_path and path_hooks
back to their default state (the defaults could then be private
attributes rather than public ones) and invalidates all the caches.

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Brett Cannon-2


On Sun, Apr 15, 2012 at 07:26, Nick Coghlan <[hidden email]> wrote:
Hooray for finally having this to the point where it has been pushed to trunk :)

On Sun, Apr 15, 2012 at 8:16 AM, Brett Cannon <[hidden email]> wrote:
> Once again, it's just code that needs updating to run on Python 3.3 so I
> don't view it as a concern. Going from list.append() to list.insert() (even
> if its ``list.insert(hook, len(list)-2)``) is not exactly difficult.

I'm not sure you can so blithely wave away the "check this before the
standard hooks" problem. If the recommended approach becomes to insert
new hooks at the *start* of path_hooks and meta_path, then that should
work fairly well, since the new additions will take precedence
regardless of what other changes have already been made. However,
trying to be clever and say "before the standard hooks, but after
everything else" is fraught with peril, since there may be hooks
present in the lists *after* the standard ones so naive counting
wouldn't work.

Well, I personally say always insert to the front of sys.meta_path because getting precedence right is always difficult when you are trying to insert into the middle of a list. I mean this issue could happen in any application that have multiple meta path finders and their is an explicit order that is desired that does not simply fall through from the way code is called.
 

As far as the guidelines for managing the import state go, it may be
worth having public "importlib.default_path_hooks" and
"importlib.default_meta_path" attributes.

I don't think it is. ``importlib.default_meta_path = [importlib.machinery.PathFinder]`` and ``importlib.default_path_hooks = [importlib.machinery.some_name_I_have_not_chosen_yet, zipimport.whatever_its_called]`` is not exactly complicated and if people are not reading the docs closely enough to realize that is what the defaults are they are already asking for trouble when mucking around with import.
 

Then "clearing" the hooks would just be a matter of resetting them
back to defaults: "sys.path_hooks[:] = importlib.default_path_hooks".
You could also locate them in the hooks list correctly by checking
"for i, hook in enumerate(sys.path_hooks): if hook is
importlib.default_path_hooks[0]: break"

You do realize people will forget the [:] and end up simply screwing up that original list, right? =)
 

Alternatively, it may be simpler to just expose a less granular
"reset_import_hooks()" function that restores meta_path and path_hooks
back to their default state (the defaults could then be private
attributes rather than public ones) and invalidates all the caches.

What about sys.path_importer_cache: all of it or just NullImporter/None entries (or should that be a boolean to this function)? And shouldn't it be called reset_import() with the level of changes you are proposing the function make?

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Nick Coghlan
On Mon, Apr 16, 2012 at 2:31 AM, Brett Cannon <[hidden email]> wrote:
> What about sys.path_importer_cache: all of it or just NullImporter/None
> entries (or should that be a boolean to this function)? And shouldn't it be
> called reset_import() with the level of changes you are proposing the
> function make?

Hmm, perhaps the simpler suggestion is: "If you want a clean import
state, use multiprocessing or the subprocess module to invoke a new
instance of python" :)

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Brett Cannon-2


On Sun, Apr 15, 2012 at 22:03, Nick Coghlan <[hidden email]> wrote:
On Mon, Apr 16, 2012 at 2:31 AM, Brett Cannon <[hidden email]> wrote:
> What about sys.path_importer_cache: all of it or just NullImporter/None
> entries (or should that be a boolean to this function)? And shouldn't it be
> called reset_import() with the level of changes you are proposing the
> function make?

Hmm, perhaps the simpler suggestion is: "If you want a clean import
state, use multiprocessing or the subprocess module to invoke a new
instance of python" :)


Yeah, kinda. =) This is why testing import (as you know) is such an utter pain.

-Brett

 
Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Brett Cannon-2
In reply to this post by Brett Cannon-2
The only people to bring up worries about this thread were Eric and Nick and they both seem fine with making stuff explicit and changing the meaning of None in sys.path_importer_cache, so I have created http://bugs.python.org/issue14605 and will plan on implementing the ideas for it before Python 3.3 goes out.

On Sat, Apr 14, 2012 at 16:03, Brett Cannon <[hidden email]> wrote:
To start off, what I am about to propose was brought up at the PyCon language summit and the whole room agreed with what I want to do here, so I honestly don't expect much of an argument (famous last words).

In the "ancient" import.c days, a lot of import's stuff was hidden deep in the C code and in no way exposed to the user. But with importlib finishing PEP 302's phase 2 plans of getting imoprt to be properly refactored to use importers, path hooks, etc., this need no longer be the case.

So what I propose to do is stop having import have any kind of implicit machinery. This means sys.meta_path gets a path finder that does the heavy lifting for import and sys.path_hooks gets a hook which provides a default finder. As of right now those two pieces of machinery are entirely implicit in importlib and can't be modified, stopped, etc.

If this happens, what changes? First, more of importlib will get publicly exposed (e.g. the meta path finder would become public instead of private like it is along with everything else that is publicly exposed). Second, import itself technically becomes much simpler since it really then is about resolving module names, traversing sys.meta_path, and then handling fromlist w/ everything else coming from how the path finder and path hook work.

What also changes is that sys.meta_path and sys.path_hooks cannot be blindly reset w/o blowing out import. I doubt anyone is even touching those attributes in the common case, and the few that do can easily just stop wiping out those two lists. If people really care we can do a warning in 3.3 if they are found to be empty and then fall back to old semantics, but I honestly don't see this being an issue as backwards-compatibility would just require being more careful of what you delete (which I have been warning people to do for years now) which is a minor code change which falls in line with what goes along with any new Python version.

And lastly, sticking None in sys.path_importer_cache would no longer mean "do the implicit thing" and instead would mean the same as NullImporter does now (which also means import can put None into sys.path_importer_cache instead of NullImporter): no finder is available for an entry on sys.path when None is found. Once again, I don't see anyone explicitly sticking None into sys.path_importer_cache, and if they are they can easily stick what will be the newly exposed finder in there instead. The more common case would be people wiping out all entries of NullImporter so as to have a new sys.path_hook entry take effect. That code would instead need to clear out None on top of NullImporter as well (in Python 3.2 and earlier this would just be a performance loss, not a semantic change). So this too could change in Python 3.3 as long as people update their code like they do with any other new version of Python.

In summary, I want no more magic "behind the curtain" for Python 3.3 and import: sys.meta_path and sys.path_hooks contain what they should and if they are emptied then imports will fail and None in sys.path_importer_cache means "no finder" instead of "use magical, implicit stuff".


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Philip Jenvey-3
In reply to this post by Brett Cannon-2

On Apr 14, 2012, at 1:03 PM, Brett Cannon wrote:

> And lastly, sticking None in sys.path_importer_cache would no longer mean "do the implicit thing" and instead would mean the same as NullImporter does now (which also means import can put None into sys.path_importer_cache instead of NullImporter): no finder is available for an entry on sys.path when None is found.

Isn't it more explicit to cache the NullImporter instead of None?

--
Philip Jenvey

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Brett Cannon-2


On Tue, Apr 17, 2012 at 13:45, Philip Jenvey <[hidden email]> wrote:

On Apr 14, 2012, at 1:03 PM, Brett Cannon wrote:

> And lastly, sticking None in sys.path_importer_cache would no longer mean "do the implicit thing" and instead would mean the same as NullImporter does now (which also means import can put None into sys.path_importer_cache instead of NullImporter): no finder is available for an entry on sys.path when None is found.

Isn't it more explicit to cache the NullImporter instead of None?

I disagree. NullImporter is just another finder that just so happens to always fail. None is explicitly not a finder and thus obviously not going to do anything. Isn't it clearer to say ``sys.path_importer_cache[path] is None`` than ``isinstance(sys.path_importer_cache[path], imp.NullImporter)``? I mean we have None to represent something is nothing which is exactly what I want to convey; None in sys.path_importer_cache means there is no finder for that path.

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: making the import machinery explicit

Terry Reedy
On 4/17/2012 2:01 PM, Brett Cannon wrote:
> Isn't it clearer to say
> ``sys.path_importer_cache[path] is None`` than
> ``isinstance(sys.path_importer_cache[path], imp.NullImporter)``?

Yes. Great work. Thanks for helping with the Idle breakage.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com