New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restructure import.c into PEP 302 importer objects #46388
Comments
This patch reorganizes import.c to move functionality into two new PEP-302-style Importer objects. I attempted to change as little as BuiltinImporter: handles C_BUILTIN and PY_FROZEN modules BuiltinImporter is put on sys.meta_path, DirectoryImporter is put on To preserve backward compatibility of methods like imp.find_module(), Character encoding issues were substantial. The existing code was Areas for discussion: Naming: Names of the importer classes, names of variables, etc sys: I added three variables to sys. Is there a better alternative? ModuleInfo: The importers use a somewhat tricky way to store an open semantics: There are many import corner cases where the semantics are Frozen packages: the __path__ of a frozen package is a string rather |
I've noticed that the proposed patch adds const qualifier to many C-API I would recommend to separate const qualifier changes into a separate I promise, I will make substantive comments soon. :-) |
The patch breaks test_import on Mac OS 10.4: $ ./python.exe -E -tt -bb ./Lib/test/regrtest.py test_import
test_import
test test_import failed -- Traceback (most recent call last):
File "./Lib/test/regrtest.py", line 1199, in <module>
main()
File "./Lib/test/regrtest.py", line 405, in main
huntrleaks)
File "./Lib/test/regrtest.py", line 562, in runtest
huntrleaks, debug)
File "./Lib/test/regrtest.py", line 614, in runtest_inner
print("test", test, "failed --", msg)
File "/Users/sasha/Work/python-svn/py3k/Lib/io.py", line 1247, in
write
b = encoder.encode(s)
File "/Users/sasha/Work/python-svn/py3k/Lib/encodings/ascii.py", line
22, in encode
return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode characters in position
211-214: ordinal not in range(128) |
Sorry I have not commented on this sooner; been swamped. First, the error Alexander is seeing is probably caused by a source file Second, I am the wrong person to be reviewing this as I have something |
First, let me state that I like the idea of a uniform approach to This said, here is my first question: Is there a reason why new importer classes are not subclassable while >>> class x(imp.BuiltinImporter):pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: type 'imp.BuiltinImporter' is not an acceptable base type
>>> class x(imp.DirectoryImporter): pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
>>> class x(zipimport.zipimporter): pass
... Users might want to overload find_module while reusing load_module from In fact, I see a great deal of code duplication between the new importer |
Brett, I wrote my patch thinking that the next step would be to rewrite Alexander, The const thing: I went on a bit of a const rampage after an The non-subclassable aspect was an oversight. I thought about having I don't have a Mac setup, but I think the error you're seeing is |
On Fri, Feb 22, 2008 at 5:21 PM, Douglas Greiman <report@bugs.python.org> wrote:
You can drop it if you want, but I just don't know how long it will
I use the imp module to handle the actual loading, but the importers |
Interesting - I'll try to find the time to take a look at this. (I also |
Closed at Doug's request. My importlib work, once it lands, will supplant |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: