Nick Coghlan, 06.08.2013 07:35:
If you wanted to reboot this thread on import-sig, that would probably
be a good thing :)
Sigh. Yet another list to know about and temporarily follow...
The import-sig list doesn't seem to be mirrored on Gmane yet. Also, it
claims to be dead w.r.t. Py3.4:
The
On 6 August 2013 16:03, Stefan Behnel stefan...@behnel.de wrote:
Seriously, wouldn't python-dev be just fine for this? It's not like the
import system is going to be rewritten for each minor release from now on.
We currently use it whenever we're doing a deep dive into import
system arcana, so
Nice idea, but some of those may break 3rd party libraries like Boost. Python
that have their own equilavent of the Python/C API. Or Even SWIG might
experience trouble in one or two of those.
Stefan Behnel stefan...@behnel.de wrote:
Hi,
let me revive and summarize this old thread.
Stefan
Ryan, 06.08.2013 17:02:
Nice idea, but some of those may break 3rd party libraries like Boost.
Python that have their own equilavent of the Python/C API. Or Even SWIG
might experience trouble in one or two of those.
Te idea is that this will be an alternative way of initialising a module
that
Hi,
let me revive and summarize this old thread.
Stefan Behnel, 08.11.2012 13:47:
I suspect that this will be put into a proper PEP at some point, but I'd
like to bring this up for discussion first. This came out of issues 13429
and 16392.
http://bugs.python.org/issue13429
On 6 August 2013 15:02, Stefan Behnel stefan...@behnel.de wrote:
Alternatives I see:
1) Expose a struct that points to the extension module's PyModuleDef struct
and the init function and expose that struct instead.
2) Expose both the PyModuleDef and the init function as public symbols.
3)
Hi,
I suspect that this will be put into a proper PEP at some point, but I'd
like to bring this up for discussion first. This came out of issues 13429
and 16392.
http://bugs.python.org/issue13429
http://bugs.python.org/issue16392
Stefan
The problem
===
Python modules and extension
M.-A. Lemburg, 08.11.2012 14:01:
On 08.11.2012 13:47, Stefan Behnel wrote:
I suspect that this will be put into a proper PEP at some point, but I'd
like to bring this up for discussion first. This came out of issues 13429
and 16392.
http://bugs.python.org/issue13429
Stefan Behnel, 08.11.2012 14:20:
M.-A. Lemburg, 08.11.2012 14:01:
On 08.11.2012 13:47, Stefan Behnel wrote:
I suspect that this will be put into a proper PEP at some point, but I'd
like to bring this up for discussion first. This came out of issues 13429
and 16392.
On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel stefan...@behnel.de wrote:
Hi,
I suspect that this will be put into a proper PEP at some point, but I'd
like to bring this up for discussion first. This came out of issues 13429
and 16392.
http://bugs.python.org/issue13429
Hi Brett,
thanks for the feedback.
Brett Cannon, 08.11.2012 15:41:
On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
I propose to split the extension module initialisation into two steps in
Python 3.4, in a backwards compatible way.
Step 1: The current module init function can be reduced
On Thu, Nov 8, 2012 at 10:00 AM, Stefan Behnel stefan...@behnel.de wrote:
Hi Brett,
thanks for the feedback.
Brett Cannon, 08.11.2012 15:41:
On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
I propose to split the extension module initialisation into two steps in
Python 3.4, in a
Brett Cannon, 08.11.2012 16:06:
On Thu, Nov 8, 2012 at 10:00 AM, Stefan Behnel stefan...@behnel.de wrote:
Hi Brett,
thanks for the feedback.
Brett Cannon, 08.11.2012 15:41:
On Thu, Nov 8, 2012 at 7:47 AM, Stefan Behnel wrote:
I propose to split the extension module initialisation into
13 matches
Mail list logo
