Brett Cannon added the comment:
I still need a core committer to double-check me on Eric's patch to make sure
the ABC changes are acceptable. I can handle the commit if someone will just
sign off.
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
Done. Only substantive comment was that Finder should be registered with both
of the more specific metaclasses, but there were a couple of docs comments as
well.
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
Oh, and +1 for Eric's path-based finder. States clearly that it is a finder
that *uses* import paths, rather than finding them.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
Brett Cannon added the comment:
Thanks for the review, Nick! I will get this patch committed sometime today
with your comments integrated.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
Brett Cannon added the comment:
Actually there is one issue with PathEntryFinder inheriting from Finder; it
doesn't need to implement find_module() if it doesn't want to in Python 3.3. So
I will need to stick in a dummy find_module() on the class that calls
find_loader() and then returns any
Nick Coghlan added the comment:
Sounds good. Perhaps steal the impl from FileFinder.find_module (i.e. the one
with the ImportWarning).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
Roundup Robot added the comment:
New changeset 0a75ce232f56 by Brett Cannon in branch 'default':
Issue #15502: Finish bringing importlib.abc in line with the current
http://hg.python.org/cpython/rev/0a75ce232f56
--
___
Python tracker
Changes by Brett Cannon br...@python.org:
--
assignee: - brett.cannon
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
Brett Cannon added the comment:
I will go back and steal the FileFinder.find_module implementation after I
finish the current patch I'm working on.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
Roundup Robot added the comment:
New changeset e7a67f1bf604 by Brett Cannon in branch 'default':
Issue #15502: Refactor some code.
http://hg.python.org/cpython/rev/e7a67f1bf604
--
___
Python tracker rep...@bugs.python.org
Brett Cannon added the comment:
Eric's latest patch LGTM except for the missing patch for
test.test_importlib.test_abc to fix the inheritance checks.
Nick, Eric Smith, or Barry: can you double-check the patch is good? About the
only thing that might be questionable is having MetaPathFinder
Eric Snow added the comment:
This patch implements most of Brett's recommendation. I've held off on
actually deprecating Finder just yet. However, it would probably entail a
message in the docs like this:
The API signatures for meta path finders and path entry finders
were separated by PEP
Nick Coghlan added the comment:
In reviewing Eric's changes, I found what I consider a good reason to keep
Finder as the root of the hierarchy: *all* finders, both meta path and path
entry, will continue to share the optional invalidate_caches API.
I'll commit a variant that has the
Roundup Robot added the comment:
New changeset 184700df5b6a by Nick Coghlan in branch 'default':
Issue #15502: Bring the importlib ABCs into line with the current state of the
import protocols given PEP 420. Original patch by Eric Snow.
http://hg.python.org/cpython/rev/184700df5b6a
--
Nick Coghlan added the comment:
Specifically, what I did was to drop find_module from the Finder ABC, but
keep the ABC itself as a way to document the common invalidate_caches API.
The ABC definition no longer cares whether you implement find_module() or not.
MetaPathFinder then enforces
Nick Coghlan added the comment:
I also dealt with #15519
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
___
Python-bugs-list mailing
Roundup Robot added the comment:
New changeset 1f8351cf00f3 by Nick Coghlan in branch 'default':
Issue #15502: Bring the importlib.PathFinder docs and docstring more in line
with the new import system documentation, and fix various parts of the new docs
that weren't quite right given PEP 420
Nick Coghlan added the comment:
OK, that last commit (along with one I did earlier for the import statement)
brought over all the fixes I was previously overly hasty in committing to
Barry's importdocs branch.
I've decided I can live with regular packages as the term for initialised
packages
Barry A. Warsaw added the comment:
What about Path Scanner? Came to me in a dream, so it has to be perfect,
right? :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
Regarding the ABCs, I'm okay with it as long as invalidate_caches() is meant to
be a part of meta path finders. I had considered this while writing the patch,
so how I had it wasn't a fluke. The fluke was that I didn't bring it up for
discussion like I had meant
Barry A. Warsaw added the comment:
On Aug 02, 2012, at 11:33 AM, Nick Coghlan wrote:
Specifically, what I did was to drop find_module from the Finder ABC, but
keep the ABC itself as a way to document the common invalidate_caches
API. The ABC definition no longer cares whether you implement
Eric Snow added the comment:
I wish path subsystem finder weren't so long. Then PathFinder would probably
still be appropriate for the class name (as FileFinder is appropriate for
FilePathEntryFinder :).
--
___
Python tracker
Eric Snow added the comment:
Maybe we need an @abc.optionalabstractmethod decorator?
Perhaps you are kidding, but I've had a similar thought on a number of
occasions. For kicks, I'll float this by python-ideas. :)
--
___
Python tracker
Brett Cannon added the comment:
In terms of invalidate_caches(), it could easily be changed to walk
sys.meta_path and to call the method on the meta path finders. Not sure if that
generalization is reasonable or not, though.
--
___
Python tracker
Eric Snow added the comment:
Not to detract from the fun wink terminology discussion, but I have lingering
concerns with the ABC inheritance model here.
Looking over changeset 184700df5b6a, I'm still fine with the change if
invalidate_caches() is appropriate for both. If not or if we don't
Brett Cannon added the comment:
I guess the question is how extensive do we want this cache validation to go?
Do we think that only path entry finders stored in sys.path_importer_cache will
have stuff to be cleared, or do we think stuff on sys.meta_path or
sys.path_hooks will have things that
Eric V. Smith added the comment:
I think the cache invalidation should be moved to the sys.meta_path level.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
Good points, Brett. While I still favor my posted patch, wouldn't Nick's
commit still be okay (once invalidate_cache() is added appropriately)? Or
would it be confusing to people to have this Finder class that no one is
actually supposed to use?
--
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
Removed message: http://bugs.python.org/msg167252
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
Good points, Brett. While I still favor my posted patch, wouldn't Nick's
commit still be okay? Or would it be confusing to people to have this Finder
class that no one is actually supposed to use?
--
___
Python
Brett Cannon added the comment:
Nick's current patch is fine, although I would add back in invalidate_caches()
into MetaPathFinder and PathEntryFinder where they do nothing but return
NotImplemented as a form of no-op. I know you have a python-ideas discussion
going about optional
Brett Cannon added the comment:
As for Finder containing nothing significant, that's a side-effect of the
cleanup and why Finder should get deprecated, especially since the contract
that a Finder implements find_module() is no longer being enforced. Tying
MetaPathFinder and PathEntryFinder
Phillip J. Eby added the comment:
Per Nick's request that I redirect this here instead of #15295...
(w/already-fixed things deleted):
Hope I'm not too late to the bikeshed painting party; just wanted to chip in
with the suggestion of self-contained package for non-namespace packages.
Nick Coghlan added the comment:
On the self-contained packages point, I was going to suggest that name, but
the ability to set __path__ from __init__.py messes with it. Regular packages
isn't great, but I'm willing to tolerate it (mainly because it was the
terminology used in the approved PEP
Eric Snow added the comment:
The more I think about it the more I think there needs to be a harder
separation between the import system proper and the path-based subsystem. I
hadn't really thought of it this way until the discussion of the last few days,
but it has really clicked in my mind.
Nick Coghlan added the comment:
See my comment above about explicitly defining the path import subsystem and
renaming the path importer to be the path import finder. I think the
subsystem is well worth calling out explicitly, as when most people think of
Python's import system, they're far
Eric Snow added the comment:
Backwards compatibility requirements still apply to the importlib API -
while the default import system won't call FileFinder.find_module() any
more, third party import reimplementations are still free to do so.
Except that a good portion of the importlib API is
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26641/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Nick Coghlan added the comment:
Fair point. However, the find_module() variant of the API isn't dead yet, so we
should still support it. find_module() likely won't die completely until 4.0.
--
___
Python tracker rep...@bugs.python.org
Barry A. Warsaw added the comment:
I've mostly run out of time to work on the docs, but I do want to say that I
thought long and hard about all the terminology decisions. Please don't
change them lightly, and definitely don't change them until you've tried to go
through the documentation and
Brett Cannon added the comment:
So just to weigh in on this, I think meta path finder and path entry finder
(as Barry stated in the glossary already) clearly delineate what is from
sys.meta_path and what is from some path entry hook by having a clarifying word
to go with finder (either kind
Eric Snow added the comment:
@Barry: I'm fine with what you've said. My big concern is that we be really
consistent here because of the complexity of the import system. Things are at
a point that I think we're pretty close in the regard, so I'm mostly fine if we
stay put. My only real
Brett Cannon added the comment:
The patch will have Finder break all subclasses that don't define find_loader
which is backwards-incompatible. And if you really want to deprecate Finder you
should have a warning in an __init__ method (as one would hope people are
calling super() as
Nick Coghlan added the comment:
As a final attempt at giving the path import machinery the emphasis it
deserves without misusing the importer term, how about:
1. path import subsystem for that whole section of the import machinery;
and
2. path import finder specifically for the meta path finder
Barry A. Warsaw added the comment:
On Aug 01, 2012, at 10:03 PM, Nick Coghlan wrote:
1. path import subsystem for that whole section of the import machinery;
and
2. path import finder specifically for the meta path finder that
importlib calls PathFinder and the new docs currently call path
Nick Coghlan added the comment:
The problem with path importer is it's just plain *wrong*. That object is
not an importer and thus calling it one makes it much harder to learn the
finder/loader/importer distinctions correctly. import finder is only
slightly longer than importer and has the huge
Barry A. Warsaw added the comment:
On Aug 01, 2012, at 10:44 PM, Nick Coghlan wrote:
The problem with path importer is it's just plain *wrong*. That object is
not an importer and thus calling it one makes it much harder to learn the
finder/loader/importer distinctions correctly.
The term
Eric Snow added the comment:
The patch will have Finder break all subclasses that don't define
find_loader which is backwards-incompatible.
How so? Finder is registered against PathEntryFinder. It doesn't inherit, so
it doesn't get the abc.ABCMeta as a metaclass and thereby there is no
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26642/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
Regarding deprecating importlib.abc.Finder, I'll add a DeprecationWarning to
the patch later.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Nick Coghlan added the comment:
As far as path import finder goes, it's no more wrong than meta path finder
and path entry finder. A meta path finder is a finder that gets installed
on sys.meta_path, a path entry finder is one that finds loaders based on a
specific path entry, and the path
Eric Snow added the comment:
Okay, while the dust clears, I am going to separate the two parts into
different patches. :)
--
Added file: http://bugs.python.org/file26654/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26653/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Added file:
http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26654/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Added file: http://bugs.python.org/file26656/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
While ungainly a name change, this patch at least demonstrates the places that
the name would have to change.
--
Added file:
http://bugs.python.org/file26657/issue15502_file_path_entry_finder_of_doom.diff
___
Python
Changes by Eric Snow ericsnowcurren...@gmail.com:
Added file: http://bugs.python.org/file26658/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26656/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file:
http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
didn't mean to yank that one.
--
Added file:
http://bugs.python.org/file26659/issue15502_windows_registry_finder.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
Eric Snow added the comment:
Yeah, but right now the API of importlib.abc.Finder is strictly
find_module(name, path=None). I would expect that to remain the same for
MetaPathFinder (bikeshedding aside :). So what would be left in
importlib.abc.Finder if the ultimate plan is that
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
___
Python-bugs-list mailing
Brett Cannon added the comment:
So I think Nick has the inheritance inverted and I would have Finder inherit
from everything to stay backwards-compatible and to ease future deprecation
(which could potentially happen starting in Python 3.3), although my approach
weakens the usefulness of the
Nick Coghlan added the comment:
I would largely use Brett's proposed interface for MetaPathFinder (but keep
the path argument optional) and his PathImporter interface for
PathEntryHandler.
Finder can then just become a legacy alias for MetaPathFinder.
--
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Eric Snow added the comment:
I'm working up a patch. My intention is to match up the names to those that
Barry has pushed out to the updated glossary: MetaPathFinder and
PathEntryFinder. I'll also include doc changes.
I'm going to toy with not having any inheritance between the 3, but I'm
Nick Coghlan added the comment:
(With the draft docs now comitted, this issue is the home for thrashing out the
terminology. I'm not going to propose taking this to import-sig or python-dev,
because the bikeshed would end up being fuschia or pink-with-yellow-polkadots
or something)
However
Nick Coghlan added the comment:
Further thoughts:
1. Let's keep Finder as a generic base class for things which find module
loaders, with its current implementation but an updated docstring and
documentation.
2. The reason both the MetaPathFinder and PathEntryHander ABCs need to preserve
Nick Coghlan added the comment:
Reading through What's New, I withdraw the suggestion of changing the path
entry finder term. It's just not worth the hassle.
That also simplifies things a lot. All that needs to change to make things
consistent:
1. Switch the docs over to using path finder
Eric Snow added the comment:
Here's a patch that addresses Nick's 2 3. I think I found a satisfactory
solution for the inheritance that is both correct and backward compatible.
One question for now: does FileFinder need to keep its find_module() method?
That should be resolved before 3.3
Eric Snow added the comment:
I just noticed that WindowsRegistryImporter does not have load_module(). If we
are going for consistency, we should change the name to WindowsRegistryFinder.
--
___
Python tracker rep...@bugs.python.org
Eric Snow added the comment:
With the draft docs now comitted, this issue is the home for thrashing
out the terminology.
In my mind the key is consistency. While a worthy goal regardless, for the
import system and its attendant complexity, consistency is crucial.
(importer == finder +
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26639/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Added file: http://bugs.python.org/file26640/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Removed file: http://bugs.python.org/file26640/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
Added file: http://bugs.python.org/file26641/issue15502_new_abc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
Nick Coghlan added the comment:
Reading the 3.3 What's New reminded me that we aren't really as free to
redefine this terminology as we might hope (or as I claimed on the previous
issue). We can still try, of course, but the PEP 302 naming scheme has been
around for 10 years, and there are
New submission from Nick Coghlan:
In the review of #15295, Brett noted that the APIs of meta path finders and
path entry finders have now diverged substantially thanks to PEP 420, thus it's
rather dubious that they continue to share a single Finder ABC in importlib.
--
components:
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15502
___
___
Python-bugs-list
Eric Snow added the comment:
Would importlib.abc.Finder become something like MetapathHandler, or would we
just add a new one (like PathEntryHandler)? Obviously the actual names would
depend on the outcome of issue15295, but the fate of importlib.abc.Finder is
independent of the names.
Nick Coghlan added the comment:
As we want to eventually deprecate find_module in the PathEntryHandler API, I'd
suggest two new subclasses, MetaPathFinder and PathEntryHandler, both
inheriting from Finder.
Current path hooks would be updated to inherit from PathEntryHandler, meta path
hooks
82 matches
Mail list logo
