Martin v. Löwis wrote:
Fernando Perez wrote:
So I think M.A. is right on the money here with his statement. Unless you
consider the Linux/64bit camp insignificant. But if that is the case, it
might be worth putting a big statement in the 2.5 release notes indicating
there is a good chance,
M.-A. Lemburg wrote:
I really don't understand why you put so much effort into
trying to argue that the ssize_t patch isn't going to break
extensions or that fixing compiler warnings is good enough.
Well, in *this* thread, my main point is that I don't want
to provide the list that you demand,
Ronald Oussoren wrote:
On 17-mrt-2006, at 22:14, M.-A. Lemburg wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these
definitions
could go into a new include file:
How would that include file be used? You would have to copy it
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Do you really think module authors do have a choice given that last
sentence ?
I really do. Most developers will not be confronted with 64-bit systems
for several years to come. That current hardware supports a 64-bit mode
is only one aspect:
Fernando Perez wrote:
So I think M.A. is right on the money here with his statement. Unless you
consider the Linux/64bit camp insignificant. But if that is the case, it
might be worth putting a big statement in the 2.5 release notes indicating
there is a good chance, if you use third party
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Since this change is going to affect a lot of 3rd party extensions,
I'd also like to see a complete list of public APIs that changed and
how they changed (including the type slots)
You can construct this list easily by comparing the header files
M.-A. Lemburg wrote:
I think it's only fair that I ask the patch authors to complete
the PEP, since the ssize_t patch is causing extension authors
enough trouble already.
Well, the PEP is complete as it stands. It's possible to provide
more guidelines, but the specification part of it says
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I think it's only fair that I ask the patch authors to complete
the PEP, since the ssize_t patch is causing extension authors
enough trouble already.
Well, the PEP is complete as it stands. It's possible to provide
more guidelines, but the
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I think it's only fair that I ask the patch authors to complete
the PEP, since the ssize_t patch is causing extension authors
enough trouble already.
Well, the PEP is complete as it stands. It's possible to provide
more guidelines, but the
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these definitions
could go into a new include file:
How would that include file be used? You would have to copy it into your
own source base, and include it, right?
Regards,
Martin
Martin v. Löwis wrote:
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these definitions
could go into a new include file:
How would that include file be used? You would have to copy it into your
own source base, and include it, right?
We could put it into a
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these definitions
could go into a new include file:
How would that include file be used? You would have to copy it into your
own source base, and include it, right?
We
M.-A. Lemburg wrote:
Changes to the public API must be documented somewhere,
either in Misc/NEWS or in the PEP.
Sure. They are documented in the PEP, which says
# All occurrences of index and length parameters and results are changed
# to use Py_ssize_t, including the sequence slots in type
Martin v. Löwis wrote:
Thomas Heller wrote:
BTW: Is a porting guide to make extension modules compatible with 2.5
available somewhere? PEP 353 scratches only the surface...
Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which
particular aspect are you missing?
I suggest to
Thomas Heller wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
BTW: Is a porting guide to make extension modules compatible with 2.5
available somewhere? PEP 353 scratches only the surface...
Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which
particular aspect are you
M.-A. Lemburg wrote:
Since this change is going to affect a lot of 3rd party extensions,
I'd also like to see a complete list of public APIs that changed and
how they changed (including the type slots)
You can construct this list easily by comparing the header files of
the previous and the
[tim.peters]
CField_repr(): PyString_FromFormat() understands the
C99 z qualifier on all platforms.
[Martin v. Löwis]
Unfortunately, only so in Python 2.5. If the code is also
meant to be used for earlier versions, it won't work there
at all.
Does that matter? I checked the patch in on
Tim Peters wrote:
Unfortunately, only so in Python 2.5. If the code is also
meant to be used for earlier versions, it won't work there
at all.
Does that matter?
I believe it does: the ctypes maintainer wants to keep the
code identical across releases (AFAICT).
has Py_ssize_t all over the
[Martin]
...
I believe it does: the ctypes maintainer wants to keep the
code identical across releases (AFAICT).
Fair enough -- I reverted the checkin. It's going to need #if'ery on
the Python version, though, if it wants to match a
Python-version-dependent data width with an appropriate
Tim Peters wrote:
[Martin]
...
I believe it does: the ctypes maintainer wants to keep the
code identical across releases (AFAICT).
Correct, that's why I listed it in PEP 291.
Fair enough -- I reverted the checkin. It's going to need #if'ery on
the Python version, though, if it wants to
Thomas Heller wrote:
BTW: Is a porting guide to make extension modules compatible with 2.5
available somewhere? PEP 353 scratches only the surface...
Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which
particular aspect are you missing?
Regards,
Martin
21 matches
Mail list logo
