Bob Ippolito wrote:
I was talking about PYTHON_API_VERSION, hence "forced" in quotes.
Nobody likes to see an ugly error message.
Ah, that... If PYTHON_API_VERSION changes, it is because there is
a real incompatibility, somewhere. It is not automatically bumped
with each release. So it is safe to
Bob Ippolito wrote:
Yes, of course, I was talking about the executable, not extensions. On
Mac OS X 10.3+, the linker flag -undefined dynamic_lookup allows
extensions to link to no Python whatsoever.
It's the same on SysV ELF shared libraries, and in most other unices.
The extensions will just
On Dec 12, 2004, at 1:09 PM, Martin v. Löwis wrote:
Bob Ippolito wrote:
Yes, of course, I was talking about the executable, not extensions.
On Mac OS X 10.3+, the linker flag -undefined dynamic_lookup allows
extensions to link to no Python whatsoever.
It's the same on SysV ELF shared libraries,
On Dec 12, 2004, at 11:02 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
I believe this is not implementable: How can the DLL know which
Python
DLL to use?
Well for py2app on Mac OS X, I wrote an executable stub that chooses
a Python runtime from an XML file, looks up and binds a few symbols
fro
Bob Ippolito wrote:
I believe this is not implementable: How can the DLL know which Python
DLL to use?
Well for py2app on Mac OS X, I wrote an executable stub that chooses a
Python runtime from an XML file, looks up and binds a few symbols from
it dynamically, and then starts doing stuff.
While
On Dec 11, 2004, at 3:39 AM, Martin v. Löwis wrote:
Chui G. Tey wrote:
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functions such
as
PyArgParseTuple, PyString_AsString etc regardless of which python the
user is runnin
Chui G. Tey wrote:
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functions such as
PyArgParseTuple, PyString_AsString etc regardless of which python the
user is running. This would be similar to the COM approach. You can
>Raymond:
>
>Acceptance for Py2.4 partially hinges on how quickly third party apps
>have their binaries updated.
>
>I wonder if there is anything we can do to help.
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functio
