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:
Stefan Behnel added the comment:
Triggered discussion on python-dev:
http://thread.gmane.org/gmane.comp.python.devel/135764
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
___
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
Stefan Behnel sco...@users.sourceforge.net added the comment:
Any comments on the last patch?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
___
Stefan Behnel sco...@users.sourceforge.net 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,
Stefan Behnel sco...@users.sourceforge.net 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
Stefan Behnel sco...@users.sourceforge.net 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
Stefan Behnel sco...@users.sourceforge.net 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
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
___
___
Python-bugs-list mailing list
New submission from Stefan Behnel sco...@users.sourceforge.net:
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
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file23725/ext_module_init_file_path.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
Stefan Behnel sco...@users.sourceforge.net 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
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
I suppose that the value of _Py_ModuleImportContext is protected by the import
lock?
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
Stefan Behnel sco...@users.sourceforge.net 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
Amaury Forgeot d'Arc amaur...@gmail.com 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
Stefan Behnel sco...@users.sourceforge.net 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
Amaury Forgeot d'Arc amaur...@gmail.com 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
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
___
___
Python-bugs-list
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13429
___
19 matches
Mail list logo
