Eric Snow added the comment:
Importers are a PEP 302 API. In the context of pkgutil, they are path hooks
(see http://www.python.org/dev/peps/pep-0302/#id24), aka path importers. A
path hook is a callable that takes a path and returns a finder. Path hooks are
stored in sys.path_hooks and
Eric Snow added the comment:
This appears to be a misunderstanding about special-method lookup which,
honestly, isn't super obvious at first. It helps to remember that classes are
objects like everything else in Python and thus are instances of some type
(their metaclass).
Anyway, h
Changes by Eric Snow :
--
components: +Interpreter Core -None
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Eric Snow added the comment:
Yay!
--
___
Python tracker
<http://bugs.python.org/issue15167>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Eric Snow added the comment:
hurray!
--
___
Python tracker
<http://bugs.python.org/issue13959>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15242>
___
___
Eric Snow added the comment:
Your plan sounds good, Nick.
--
___
Python tracker
<http://bugs.python.org/issue13475>
___
___
Python-bugs-list mailing list
Unsub
New submission from Eric Snow :
When running make_a_box.py:
Fetching Mercurial ...
make_a_box.py:197: ResourceWarning: unclosed
file_url = self._download_url()
Traceback (most recent call last):
File "make_a_box.py", line 323, in
ins.create()
File "make_a_box.py
Eric Snow added the comment:
I'm re-running it from a clean directory one more time just to make sure.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13238>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
I just got the same error with a clean install. I'll have to poke at it some
other time.
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
FYI: the .pyc magic number is now built/kept in Lib/importlib/_bootstrap.py, so
updates to it will trigger a rebuild of frozen importlib during make.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.
Eric Snow added the comment:
What I mean is, shouldn't changes to marshal have an accompanying bump to the
pyc magic number?
--
___
Python tracker
<http://bugs.python.org/is
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue10399>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
is __sizeof__ part of the language or just an implementation detail?
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15
Eric Snow added the comment:
issue2898 smells like an implementation detail to me. Also, sys.getsizeof()
isn't necessarily authoritative here, since the sys module is full of all sorts
of implementation details.
I'm not saying __sizeof__ shouldn't be made an official part
Eric Snow added the comment:
Brian, perhaps the problem described in issue15431 ("Cannot build importlib.h
on Windows") is part of the problem for you here.
--
___
Python tracker
<http://bugs.python.o
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15368>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Awesome addition, Barry! Bless you for slogging through this. Here are some
thoughts (prepare one grain of salt for each):
* (glossary.rst) finder: should also reference PEP 420.
* (glossary.rst) module: s/contain/containing/
* (glossary.rst) path importer: I
Eric Snow added the comment:
> I suggest the opposite: never emit TYPE_INT64 at all. For
> compatibility, we can still support reading it in 3.3 (and drop
> that support in 3.4).
+1 essentially we maintain the status quo
--
nosy: +
Changes by Eric Snow :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue15466>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue15425>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Looks like the Misc/NEWS entry got truncated. Also, does this change need a
new PYC magic number (now in Lib/importlib/_bootstrap.py)?
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Eric Snow:
issue15110 introduced a new private function, _exec_module(), to the default
loaders in Lib/importlib/_bootstrap.py. Doing so helped hide importlib frames
from the traceback. A related fix is likely required for issue15425.
Should some general form of
Eric Snow added the comment:
Perhaps this should be split into two issues, as the fix will likely be
different for the two.
For the first part (SyntaxError), my initial impression is that this will
require a similar fix, or extension of it, to the one in issue15110. That fix
was limited
Eric Snow added the comment:
Issue15425 is related. I'm looking into an exception chaining approach that
could be applied for this issue too.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
> I don't see why a new pyc magic number should be necessary. Python
> continues to support the existing files.
Good point.
--
___
Python tracker
<http://bugs.python.
Eric Snow added the comment:
Here's a trivial patch that demonstrates what I mean. Yet, in light of
exception chaining, I wonder if we should consider actually making ImportError
supercede the inner exception. I'll still try coming up with something
similar, but propagates
Eric Snow added the comment:
See issue14592 (particularly msg158466).
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15482>
___
___
Python-bug
Eric Snow added the comment:
> I certainly struggled with this term. I almost picked PathFinder (or "path
> finder") since that's the name of the actual class used in the implementation,
> but then I thought this might be too implementation specific.
Considering that t
Eric Snow added the comment:
patch LGTM. Nice and clean.
--
___
Python tracker
<http://bugs.python.org/issue15486>
___
___
Python-bugs-list mailing list
Unsub
Eric Snow added the comment:
Sounds good to me. As I understood them:
1. default path importer (a.k.a PathFinder),
2. path hook (lives on sys.path_hooks),
3. path entry handler (finder look-alike that a path hook returns),
4. module loader (business as usual).
A "path entry handler&q
Eric Snow added the comment:
More on import-related terms.
Given Nick's recommendation, here's a broader view, as related to the import
state:
sys.meta_path:
"meta path finder" -> "module loader"
sys.meta_path[-1] (initially):
"default path importer&q
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
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
Eric Snow added the comment:
For instance,
http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7214/steps/test/logs/stdio
4 cases of "ImportError: No module named '_parent_foo'". Failing on "import
_parent_foo.bar" and "from _parent_foo import b
Eric Snow added the comment:
This isn't going to be worth it.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.
Eric Snow added the comment:
Part of the problem with the import nomenclature is that PEP 302 doesn't really
nail it down and mixes the terms up a bit. This is understandable considering
it broken ground in some regard. However, at this point we have a more
comfortable relationship wit
Eric Snow added the comment:
Looks like both XP buildbots are happy now. (one is failing, but not for
test_import).
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issu
Changes by Eric Snow :
--
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue15425>
___
___
Python-bugs-list mailing list
Unsubscri
Eric Snow added the comment:
Well, I'm more -0 than -1 on "path importer", though I do like "default path
importer" better. As to the rest, sounds good to me.
--
___
Python tracker
<http:
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
New submission from Eric Snow:
1. add to importlib.machinery
2. register on importlib.abc.Finder
patch in a moment.
--
components: Interpreter Core
keywords: needs review
messages: 167074
nosy: brett.cannon, eric.snow, loewis
priority: normal
severity: normal
stage: patch review
status
Changes by Eric Snow :
--
keywords: +patch
Added file: http://bugs.python.org/file26636/issue15519_expose_importer.diff
___
Python tracker
<http://bugs.python.org/issue15
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26636/issue15519_expose_importer.diff
___
Python tracker
<http://bugs.python.org/issue15519>
___
___
Pytho
Changes by Eric Snow :
Added file: http://bugs.python.org/file26637/issue15519_expose_importer.diff
___
Python tracker
<http://bugs.python.org/issue15519>
___
___
Pytho
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 resol
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
<http://bugs.python.org/issue15
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
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26639/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Added file: http://bugs.python.org/file26640/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26640/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Added file: http://bugs.python.org/file26641/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
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
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26641/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
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
sta
Eric Snow added the comment:
Also, WindowsRegistryImporter is misnamed. It should be WindowsRegistryFinder
(see issue15502). Depending on the patch there, I'll update the one here.
--
dependencies: +Meta path finders and path entry finders are different, but
share a
Eric Snow added the comment:
I guess the real question here is if anyone has problems with adding
WindowsRegistryFinder to importlib.machinery (and to the importlib docs). If
it should stay private than I'd like to throw a _ on the name of the class.
The change to importlib.abc would l
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 an
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26642/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Eric Snow added the comment:
Regarding deprecating importlib.abc.Finder, I'll add a DeprecationWarning to
the patch later.
--
___
Python tracker
<http://bugs.python.org/is
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
<http://bugs.python.org/issue15
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26653/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Added file:
http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff
___
Python tracker
<http://bugs.python.org/issue15
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26654/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Added file: http://bugs.python.org/file26656/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
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 :
Added file: http://bugs.python.org/file26658/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Removed file: http://bugs.python.org/file26656/issue15502_new_abc.diff
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bug
Changes by Eric Snow :
Removed file:
http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff
___
Python tracker
<http://bugs.python.org/issue15
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
<http://bugs.python.org/is
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 l
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
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 t
Eric Snow added the comment:
Not to detract from the fun 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&#
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
actu
Changes by Eric Snow :
--
Removed message: http://bugs.python.org/msg167252
___
Python tracker
<http://bugs.python.org/issue15502>
___
___
Python-bugs-list mailin
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?
--
__
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
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 separa
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue14905>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Meador, is this still a problem? There was a flurry of activity in this area.
--
___
Python tracker
<http://bugs.python.org/issue15
Changes by Eric Snow :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue15576>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15576>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
I'd missed that unary + (new in 3.3). That's pretty cool.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.o
Eric Snow added the comment:
I agree with Benjamin. The name is not bound due to the from-import statement.
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15
New submission from Eric Snow:
The path hook associated with importlib.machinery.FileFinder hides away its
loader details in a closure. This is less than ideal for the purposes of
introspection and general hacking.
Here's a simple patch that exposes the loader details as an attribute o
Eric Snow added the comment:
Addressed question of introspecting loader_details in issue 15600. (see
msg167632)
--
___
Python tracker
<http://bugs.python.org/issue15
Eric Snow added the comment:
The alternative is this:
path_hook.__closure__[1].cell_contents
--
___
Python tracker
<http://bugs.python.org/issue15600>
___
___
Eric Snow added the comment:
> Changing the macro's expansion would be good enough IMO.
Sounds good to me.
> PyImport_ImportModuleLevel() is part of the stable API...
>From what I understand, as long as the function header has not changed, the
>stable ABI is still stable.
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15365>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
I have just the thing for this, but haven't had a chance to put a patch
together. I might be able to get to it in the next week if Dave "bitey"
Beazley isn't too much of a distraction. :)
--
___
P
Eric Snow added the comment:
I was able to reproduce the error using a fresh build from tip (34d5ec8a1019):
/tmp/test$ PYTHON=/opt/python3.3/bin/python3 ./test.sh
['__main__', '_bisect', '_codecs', '_collections', '_frozen_importlib',
'
Eric Snow added the comment:
The files, post-run:
$ find /tmp/test/
/tmp/test/
/tmp/test/my_test_package
/tmp/test/my_test_package/__init__.cpython-33dm.so
/tmp/test/my_test_package/a.cpython-33dm.so
/tmp/test/my_test_package/a.c
/tmp/test/my_test_package/a.py
/tmp/test/my_test_package/__init__
Eric Snow added the comment:
Traceback when run verbosely:
Traceback (most recent call last):
File "", line 1, in
File "", line 1529, in _find_and_load
File "", line 1496, in _find_and_load_unlocked
File "", line 583, in _check_name_wrapper
F
Eric Snow added the comment:
in ___init__.c:963+, prior to executing the module proper (Python2 and PyPy
handling removed):
/*--- Module creation code ---*/
__pyx_m = PyModule_Create(&__pyx_moduledef);
if (!__pyx_m) {...};
__pyx_b = PyImport_AddModule(__Pyx_NAM
Eric Snow added the comment:
This smells like a case of where sys.modules got replaced by another mapping,
but import.c continues using interp->modules. I won't be able to investigate
until tomorrow.
--
___
Python tracker
<http://bugs
Eric Snow added the comment:
That's helpful, Meador. With regards to the following, there's more to the
story:
> With 3.3 a _frozen_importlib.ExtensionFileLoader loader gets created
> against 'my_test_package/__init__.so'. This doesn't work because
> Ex
Eric Snow added the comment:
While this is a regression, 3.3 definitely puts an increased emphasis on using
importlib.import_module() instead of builtins.__import__(). Any reason why
import_module() isn't used?
As to the regression, while the current behavior makes more sense,
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue15716>
___
___
Python-bugs-list mailing list
Unsubscribe:
1501 - 1600 of 2629 matches
Mail list logo
