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
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
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14905
___
___
Python-bugs-list
Eric Snow added the comment:
Meador, is this still a problem? There was a flurry of activity in this area.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15352
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15576
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15576
___
___
Python-bugs-list
Eric Snow added the comment:
I'd missed that unary + (new in 3.3). That's pretty cool.
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14182
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 rep...@bugs.python.org
http://bugs.python.org/issue15598
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
Eric Snow added the comment:
Addressed question of introspecting loader_details in issue 15600. (see
msg167632)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15576
Eric Snow added the comment:
The alternative is this:
path_hook.__closure__[1].cell_contents
--
___
Python tracker rep...@bugs.python.org
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.
Can't we just drop
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15365
___
___
Python-bugs-list
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. :)
--
___
Python tracker rep
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',
'_functools', '_heapq', '_imp', '_io', '_locale', '_sre
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 string, line 1, in module
File frozen importlib._bootstrap, line 1529, in _find_and_load
File frozen importlib._bootstrap, line 1496, in _find_and_load_unlocked
File frozen importlib
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_NAMESTR
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 rep...@bugs.python.org
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
ExtensionFileLoader does *not* fixup
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 ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15716
___
___
Python-bugs-list
Eric Snow added the comment:
The failure output with -v:
...
# /home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc
matches /home/esnow/projects/cpython/Lib/http/__init__.py
# code object from
/home/esnow/projects/cpython/Lib/http/__pycache__/__init__.cpython-33.pyc
Eric Snow added the comment:
Here's a simple patch the allows bogus names in the fromlist. I'm going to
verify that this matches the 3.2 semantics, which may not be so cut-and-dry.
--
keywords: +patch
Added file: http://bugs.python.org/file26876/issue15715.diff
Eric Snow added the comment:
The following seems to indicate that an ImportError should be raised as
expected. I'm guessing that somewhere along the line the exception gets
silently eaten.
--
(3.2) Python/import.c:ensure_fromlist() [1]
submod = import_submodule
Eric Snow added the comment:
When people want to import modules with runtime names, they regrettably turn
to __import__() and likely will for a while. What a source of headaches!
If it were less convenient to use __import__(), perhaps fewer people would use
it. Could we remove it from
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14905
New submission from Eric Snow:
When people want to import modules with runtime names, they regrettably turn
to __import__(), have done so for many years, and likely will for a while.
If it were less convenient to use __import__(), fewer people would use it. I'm
putting together a patch
Eric Snow added the comment:
I've taken the tanget over to issue15720.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15715
___
___
Python-bugs
Eric Snow added the comment:
Here's the deal. import_module_level() gets called for v1 from sa (where
globals comes from). In that function it first calls get_parent(), which
returns a borrowed reference to the sa module object. Then that parent object
is passed to load_next() where
Eric Snow added the comment:
Would issue14803 be sufficient? Certainly not quite as concise, but deferring
to that solution would limit the proliferation of command-line arguments to the
interpreter.
--
___
Python tracker rep...@bugs.python.org
Eric Snow added the comment:
Ah, __import__() is used all over the place in the stdlib. I won't have time
right away to put together the patch then. However, here's what I'm planning:
* expose builtin___import__() (from Python/bltinmodule.c) as imp.__import__().
* expose one used
Eric Snow ericsnowcurren...@gmail.com added the comment:
No problem, Stefan. :) The main motivation was to capture the discussion at
the time so that something actually came of it.
Adding info to the devguide, essentially the catalog/how-to of core dev
activities, was meant to simply
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13961
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13977
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13991
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Ran into this bug today in 2.7 (building python-sybase with freetds). The fix
in msg121260 took care of it (didn't try the patch). Thanks, Éric.
Is this something that could get patched in the upcoming micro releases? It's
not so
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14043
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14040
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14057
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14067
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13447
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14080
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1116520
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8706
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13797
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11477
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue992389
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14226
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14209
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1469629
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4199
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14328
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14331
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11105
___
___
Python-bugs-list
New submission from Eric Snow ericsnowcurren...@gmail.com:
The imp.init_frozen() function was removed from the documentation prior to 3.2
(changeset 2cf7bb2bbfb8). One reference to the function was left behind. I've
attached a very intricate patch. wink
--
assignee: docs@python
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
title: imp module should omit references to init_frozen - imp module docs
should omit references to init_frozen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14355
Eric Snow ericsnowcurren...@gmail.com added the comment:
Here's an incomplete (though essentially test-passing) patch that flips more of
imp into importlib. It builds on Brett's patch. The gist is that imp.py is a
minimal wrapper around importlib, which uses _imp directly.
Ultimately
Eric Snow ericsnowcurren...@gmail.com added the comment:
Here's a listing of the places where import-ish modules are used in CPython.
Once things all the import stuff currently on the table is wrapped up, I'll
probably work on switching things over to using importlib directly
Eric Snow ericsnowcurren...@gmail.com added the comment:
Of note for my patch is the addition of SUFFIXES and MODE to the 3 main file
loader classes. I did this to reverse the dependence on imp.get_suffixes().
As well, a couple of extra functions are added to
Python/importlib/_bootstrap.py
Eric Snow ericsnowcurren...@gmail.com added the comment:
Sounds good. It will be a while before we get there, but at that point I was
already planning on getting in touch with the maintainers of relevant modules
before messing with them
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14386
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
+0 as long as the linked pages don't go anywhere. They've been great
resources, containing some information that is not located elsewhere.
--
nosy: +eric.snow
___
Python tracker rep
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14381
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
It's been a while and I probably need to clean up that last patch a little. I
also need to address the questions of:
1. f_func for class/module execution
2. thread-safety
see:
http://mail.python.org/pipermail/python-ideas/2011-August
Eric Snow ericsnowcurren...@gmail.com added the comment:
for reference, a related issue:
http://bugs.python.org/issue13672
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12857
Eric Snow ericsnowcurren...@gmail.com added the comment:
(Éric, I'd reply in the review if reitveld recognized my current username --
see http://psf.upfronthosting.co.za/roundup/meta/issue402. FYI, I also did not
get an email for your review, which is likely related to that issue.)
Regarding
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14494
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14500
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14551
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6380
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1590864
___
___
Python-bugs
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14578
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Yeah, that's one part of imp.find_module that I kind of set aside too (the
#ifdef MS_COREDLL sections in Python/import.c). For now would it be sufficient
to expose _PyWin_FindRegisteredModule() privately with a wrapper in the imp
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14581
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
big +1! I went quite a while before realizing that loader.load_module() was
supposed to return the module, due to this specific issue.
--
nosy: +eric.snow
___
Python tracker rep
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14580
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14583
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14585
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14592
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14594
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14593
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
This is a mostly-working sketch of find_module() in imp.py. I've run out of
time tonight, but wanted to get it up in case it's useful to anyone else (a.k.a
Brett). If nobody's touched it before then, I'll finish it up tomorrow
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14604
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14605
___
___
Python-bugs-list
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12599
___
___
Python-bugs-list
Eric Snow ericsnowcurren...@gmail.com added the comment:
Loaders are in charge of adding the module to sys.modules (per PEP 302).
importlib codifies this in the module_for_loader() decorator, which the default
loaders use.
--
nosy: +eric.snow
Eric Snow ericsnowcurren...@gmail.com added the comment:
3.3.0a2+:
import x
x
module 'x' from './x.py'
import sys
sys.modules['x']
5
x
5
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14609
Eric Snow ericsnowcurren...@gmail.com added the comment:
_find_and_load() in importlib._bootstrap returns whatever the loader returns,
which is the new module object. The old code in import.c pulled it from
sys.modules rather than using what the loader returned. In both cases the
respective
Eric Snow ericsnowcurren...@gmail.com added the comment:
2 problems with that last patch:
* the types of the loaders that get returned by _bootstrap._find_module() are
not the classes in _bootstrap (e.g. _frozen_importlib._SourceFileLoader). That
doesn't smell right.
* tokenize.get_encoding
Eric Snow ericsnowcurren...@gmail.com added the comment:
rather, tokenize.detect_encoding()
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13959
Eric Snow ericsnowcurren...@gmail.com added the comment:
that's a pretty sneaky hack, but I can see the (weak) point of it. So, to keep
backward compatibility, importlib._bootstrap._find_and_load() would have to
return sys.modules[fullname] instead of the module returned
Eric Snow ericsnowcurren...@gmail.com added the comment:
I would advocate breaking any compatability.
Did you mean against breaking any compatability? The problem is that it's
just one more sticky little detail that adds to the complexity of understanding
the import system. It's things
Eric Snow ericsnowcurren...@gmail.com added the comment:
On the _frozen_importlib point, I'm fine with that. It was just
counter-intuitive that the importlib._bootstrap functions were returning
loaders whose classes weren't also defined there.
I'll have another look at that test tonight
Eric Snow ericsnowcurren...@gmail.com added the comment:
The original motivator:
http://mail.python.org/pipermail/python-dev/2011-July/112497.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12633
Eric Snow ericsnowcurren...@gmail.com added the comment:
The patch is out of date, but the question is still somewhat applicable.
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12598
New submission from Eric Snow ericsnowcurren...@gmail.com:
Once the dust clears from the issue 2377 and issue 13959, we should consider
what import-state-related members of PyInterpreterState (Include/pystate.h) can
be removed. This is in the interest of simplifying the interpreter state
Eric Snow ericsnowcurren...@gmail.com added the comment:
also, issue 14615 is related to making sys.modules authoritative.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12633
Eric Snow ericsnowcurren...@gmail.com added the comment:
Curse you, undocumented API that we have to support! It could still wrap a
simple get() on sys.modules, roughly like this:
PyObject*
PyState_FindModule(struct PyModuleDef* m)
{
PyObject* modules, module;
modules
401 - 500 of 2619 matches
Mail list logo
