[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: This has been resolved by PEP 489, issue 24268. The module initialisation process receives the complete ModuleSpec now, starting with CPython 3.5, and can do with it whatever it likes, before executing any user code. -- resolution: -> duplicate stage:

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: Triggered discussion on python-dev: http://thread.gmane.org/gmane.comp.python.devel/135764 -- ___ Python tracker ___ ___

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: I'm increasing the target version as this didn't change anything for 3.3. However, for 3.4, it might be possible to work around this by splitting the module init function into two parts, one that gets executed in order to create the module object (and do safe C

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: Any comments on the last patch? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: As MvL noted in his response to issue 13431, simply adding a parameter to the module init function cannot safely be done before Python 4. So we are back to the idea of passing the information through to the module creation function, i.e. this very issue. A va

[issue13429] provide __file__ to extension init function

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: Replying to myself: > I think the right fix for Python 4 would be to simply pass > a context struct into the module init function. Actually, this doesn't have to wait for Python 4. Changing the module init function to take a parameter should be backwards compat

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: Updated patch that does not reset _Py_ModuleImportContext after use. -- Added file: http://bugs.python.org/file23728/ext_module_init_file_path_2.patch ___ Python tracker __

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: I'm aware that these things happen, that's why I said it. Actually, wouldn't it rather be *correct* for __file__ to be set to the same file path for all modules that an extension module creates in its init function? That would suggest that _Py_ModuleImportCont

[issue13429] provide __file__ to extension init function

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue13429] provide __file__ to extension init function

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue13429] provide __file__ to extension init function

Amaury Forgeot d'Arc added the comment: > ... and the module init function could create and register a > different module first, and ... Actually, this *does* happen, the PIL module is written this way. And I don't agree with the "best effort" argument. If there is a slight chance that this do

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: ... and the module init function could create and register a different module first, and ... Well, yes, it's a best effort thing. It's rather unlikely that the GIL would get released in between the call to the init function and the creation of the module with

[issue13429] provide __file__ to extension init function

Amaury Forgeot d'Arc added the comment: But the GIL can be released in many places (e.g. a Py_DECREF), and another thread can enter the same function and update the same static variable. -- ___ Python tracker ___

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: I don't know how the import lock applies here. Would it have to be protected by it? The lifetime is restricted to the call of the extension module init function, and its value is saved recursively if the init function triggers further imports. It works exactl

[issue13429] provide __file__ to extension init function

Amaury Forgeot d'Arc added the comment: I suppose that the value of _Py_ModuleImportContext is protected by the import lock? -- nosy: +amaury.forgeotdarc ___ Python tracker ___

[issue13429] provide __file__ to extension init function

Stefan Behnel added the comment: Here is an extension to the patch that implements the protocol also for extension module reinitialisation, so that the module creation can also set __file__ and the proper package in that case. Currently without tests (and users, I guess). -- Added fi

[issue13429] provide __file__ to extension init function

Changes by Stefan Behnel : -- keywords: +patch nosy: +loewis Added file: http://bugs.python.org/file23725/ext_module_init_file_path.patch ___ Python tracker ___ _

[issue13429] provide __file__ to extension init function

New submission from Stefan Behnel : In Python modules, the top-level module code sees the __file__ variable and can use it to refer to resources in package subdirectories, for example. This is not currently possible in extension modules, because __file__ is only set after running the module in