Expose ZipImporter Type Object in the include header files.

[AraHaan]

BPO	32075
Nosy	@Yhg1s, @brettcannon, @ncoghlan, @ericsnowcurrently, @serhiy-storchaka, @AraHaan
PRs	bpo-32075: Expose ZipImporter Type Object in the include header files. #4470

^{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']

[AraHaan]

I would like to make an C extension module which basically would have the ZipImporter type defined in the zipimport.c which defines most things related to ZipImporter to be public so that way one can set it to .tp_base on 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]

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]

After looking in the smelly tool it seems that now I got to rename the _Type to ZipImporter to have the Py prefix. Since this will be a probable breaking change this might not be a good idea on backporting to 3.6.

[serhiy-storchaka]

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]

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]

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.