This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | belopolsky |
|---|---|
| Recipients | belopolsky, brett.cannon, christian.heimes, dgreiman |
| Date | 2008年02月22日.21:46:05 |
| SpamBayes Score | 0.05710038 |
| Marked as misclassified | No |
| Message-id | <1203716767.23.0.888741062783.issue2135@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
First, let me state that I like the idea of a uniform approach to importing, but given the complexity of the task, Brett's approach (which I understand as implementing the builtin importer classes in Python) would make sense (as long as he can solve the chicken and egg problem). This said, here is my first question: Is there a reason why new importer classes are not subclassable while zipimporter is? >>> 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 a built-in importer class. In fact, I see a great deal of code duplication between the new importer classes that can be reduced by deriving from a common base class. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年02月22日 21:46:07 | belopolsky | set | spambayes_score: 0.0571004 -> 0.05710038 recipients: + belopolsky, brett.cannon, christian.heimes, dgreiman |
| 2008年02月22日 21:46:07 | belopolsky | set | spambayes_score: 0.0571004 -> 0.0571004 messageid: <1203716767.23.0.888741062783.issue2135@psf.upfronthosting.co.za> |
| 2008年02月22日 21:46:06 | belopolsky | link | issue2135 messages |
| 2008年02月22日 21:46:05 | belopolsky | create | |