2008/5/29 Nick Coghlan <[EMAIL PROTECTED]>:
> it would still be nice if the PyBytes_* symbols
> were visible to the linker as well as the preprocessor.
If this is not a strict requirement but a useful extra, then it might
be done in an unportable way. GCC has an 'alias' attribute:
http://gcc.gnu.
Stefan Behnel wrote:
Nick Coghlan wrote:
Stefan Behnel wrote:
Besides, how likely is it that users set a breakpoint on the
PyBytes/PyString functions?
Not very likely at all - but it would still be nice if the PyBytes_*
symbols were visible to the linker as well as the preprocessor.
Right, t
Nick Coghlan wrote:
> Stefan Behnel wrote:
>> Besides, how likely is it that users set a breakpoint on the
>> PyBytes/PyString functions?
>
> Not very likely at all - but it would still be nice if the PyBytes_*
> symbols were visible to the linker as well as the preprocessor.
Right, that's a nice
Stefan Behnel wrote:
M.-A. Lemburg wrote:
If you use PyBytes APIs, you expect to find PyBytes functions in
the libs and also set breakpoints on these.
AFAICT, the PyBytes_* functions are in both Py2.6 and Py3 now, so no problem
here.
The PyBytes_* functions appear to be there, but a preproc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
| If you use PyBytes APIs, you expect to find PyBytes functions in
| the libs and also set breakpoints on these.
Very good point.
- --
Jesus Cea Avion _/_/ _/_/_/_/_/_/
[EMAIL PROTECTED] - ht
M.-A. Lemburg wrote:
You are probably talking about the great renaming between 1.4 and 1.5.
That was different, since it changes almost all C APIs in Python.
And it used the standard practice... from rename2.h in Python 1.5:
/* This file contains a bunch of #defines that make it possible to use
