Issue 32075: Expose ZipImporter Type Object in the include header files. (original) (raw)

Created on 2017-11-19 19:56 by Decorater, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 4470 closed Decorater,2017-11-19 20:33
Messages (8)
msg306513 - (view) Author: Decorater (Decorater) * Date: 2017-11-19 19:56
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.
msg306523 - (view) Author: Decorater (Decorater) * Date: 2017-11-20 02:10
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.
msg306524 - (view) Author: Decorater (Decorater) * Date: 2017-11-20 02:27
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.
msg306532 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-11-20 08:18
There is a plan of reimplementing zipimport in Python (see ). What are you going to do with this? I think that C extensions should use a common import API.
msg306533 - (view) Author: Decorater (Decorater) * Date: 2017-11-20 08:25
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.
msg306534 - (view) Author: Decorater (Decorater) * Date: 2017-11-20 08:40
Well since 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.
msg306536 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-11-20 09:02
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.
msg325719 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-09-19 07:20
zipimport have been rewritten in pure Python ().
History
Date User Action Args
2022-04-11 14:58:54 admin set github: 76256
2018-09-19 07:20:52 serhiy.storchaka set status: open -> closedresolution: out of datemessages: + stage: patch review -> resolved
2017-11-20 09:02:50 serhiy.storchaka set messages: +
2017-11-20 08:40:45 Decorater set messages: + versions: + Python 3.6, - Python 3.7, Python 3.8
2017-11-20 08:25:19 Decorater set messages: +
2017-11-20 08🔞03 serhiy.storchaka set nosy: + twouters, eric.snow, serhiy.storchaka, brett.cannon, ncoghlanmessages: +
2017-11-20 03:24:27 Decorater set assignee: docs@pythoncomponents: + Build, Documentationnosy: + docs@python
2017-11-20 02:27:48 Decorater set versions: - Python 3.6
2017-11-20 02:27:41 Decorater set messages: +
2017-11-20 02:10:21 Decorater set messages: +
2017-11-19 23:44:01 Decorater set type: behavior
2017-11-19 20:33:23 Decorater set keywords: + patchstage: patch reviewpull_requests: + <pull%5Frequest4402>
2017-11-19 19:56:09 Decorater create