Repository navigation
Expose ZipImporter Type Object in the include header files. #76256
Description
| BPO | 32075 |
|---|---|
| Nosy | @Yhg1s, @brettcannon, @ncoghlan, @ericsnowcurrently, @serhiy-storchaka, @AraHaan |
| PRs |
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:
assignee = None
closed_at = <Date 2018-09-19.07:20:52.140>
created_at = <Date 2017-11-19.19:56:09.232>
labels = ['interpreter-core', 'type-bug', 'extension-modules', 'build', 'library', 'docs']
title = 'Expose ZipImporter Type Object in the include header files.'
updated_at = <Date 2018-09-19.07:20:52.139>
user = 'https://github.com/AraHaan'bugs.python.org fields:
activity = <Date 2018-09-19.07:20:52.139>
actor = 'serhiy.storchaka'
assignee = 'docs@python'
closed = True
closed_date = <Date 2018-09-19.07:20:52.140>
closer = 'serhiy.storchaka'
components = ['Build', 'Documentation', 'Extension Modules', 'Interpreter Core', 'Library (Lib)']
creation = <Date 2017-11-19.19:56:09.232>
creator = 'Decorater'
dependencies = []
files = []
hgrepos = []
issue_num = 32075
keywords = ['patch']
message_count = 8.0
messages = ['306513', '306523', '306524', '306532', '306533', '306534', '306536', '325719']
nosy_count = 7.0
nosy_names = ['twouters', 'brett.cannon', 'ncoghlan', 'docs@python', 'eric.snow', 'serhiy.storchaka', 'Decorater']
pr_nums = ['4470']
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue32075'
versions = ['Python 3.6']
Activity
AraHaan commentedon Nov 19, 2017
I would like to make an C extension module which basically would have the ZipImporter type defined in the
zipimport.cwhich defines most things related to ZipImporter to be public so that way one can set it to.tp_baseon their C extension.That should hopefully in the C side of things allow subclassing the zipimporter class outside of the Python layer as well. Otherwise I would have to manually copy the said definition from zipimport.c and that could be a huge risk if a bug or something in the ZipImporter was fixed that it wont automatically be fixed in the C version of the subclass. I want precisely this and for it to be exposed to other people who might want to subclass the zipimporter class outside of the Python layer as well.
AraHaan commentedon Nov 20, 2017
Seems that now this is detected as an smelly symbol:
./python Tools/scripts/smelly.py
+ nm -p libpython3.7dm.a
Ignored symbol types: b, d, r, t
Smelly symbol: ZipImporter_Type (type: D)
ERROR: Found 1 smelly symbols!
make: *** [smelly] Error 1
I think I need to find a fix to this now.
AraHaan commentedon Nov 20, 2017
After looking in the smelly tool it seems that now I got to rename the _Type to ZipImporter to have the
Pyprefix. Since this will be a probable breaking change this might not be a good idea on backporting to 3.6.serhiy-storchaka commentedon Nov 20, 2017
There is a plan of reimplementing zipimport in Python (see bpo-25711). What are you going to do with this?
I think that C extensions should use a common import API.
AraHaan commentedon Nov 20, 2017
That is true, but Well, I am using this in a project of mine currently where it loads up encrypted scripts from a zip file. However I must have the import hook itself be in an C extension and subclass the current zipimporter. However knowing a rewrite for it is best, I have not experienced any bugs with it so far actually.
AraHaan commentedon Nov 20, 2017
Well since bpo-25711 might be for 3.7 and newer I guess this patch might actually be for 3.6.4 or something then. And then the rewrite would take over on 3.7 and newer depending on if the rewrite makes it in to 3.7.
serhiy-storchaka commentedon Nov 20, 2017
The C API cann't be changed in a bugfix release. Unless for fixing bugs, but even in that case we should be very very careful. There is no a bug.
serhiy-storchaka commentedon Sep 19, 2018
zipimport have been rewritten in pure Python (bpo-25711).