[Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0

[Guido van Rossum]

I will freely admit that I haven't followed this thread in any detail,
but if it were up to me, I'd have the 2.6 internal code use PyString
(as both what the linker sees and what the human reads in the source
code) and the 3.0 code use PyBytes for the same thing. Let the merges
be damed -- most changes to 2.6 these days seem to be blocked
explicitly from being merged anyway. I'd prefer the 2.6 code base to
stay true to 2.x, and the 3.0 code base start afresh where it makes
sense. We should reindent more of the 3.0 code base to use
4-space-indents in C code too.

I would also add macros that map the PyBytes_* APIs to PyString_*, but
I would not start using these internally except in code newly written
for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
for 8-bit strings containing text, and PyBytes for 8-bit strings
containing binary data. For 8-bit strings that could contain either
text or data, I'd use PyString, in the spirit of 2.x.

--Guido

On Mon, Jun 2, 2008 at 3:21 PM, Gregory P. Smith <greg at krypto.org> wrote:
>
>
> On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>
>>> Okay, how about this?  http://codereview.appspot.com/1521
>>>
>>> Using that patch, both PyString_ and PyBytes_ APIs are available using
>>> function stubs similar to the above.  I opted to define the stub
>>> functions right next to the ones they were stubbing rather than
>>> putting them all at the end of the file or in another file but they
>>> could be moved if someone doesn't like them that way.
>>
>> Thanks. I was working on a similar patch. Looks like you beat
>> me to it.
>>
>> The only thing I'm not sure about is having the wrappers in the
>> same file - this is likely to cause merge conflicts when doing
>> direct merging and even with an automated renaming approach,
>> the extra code would be easier to remove if it were e.g. at
>> the end of the file or even better: in a separate file.
>>
>> My patch worked slightly differently: it adds wrappers PyString*
>> that forward calls to the PyBytes* APIs and they all live in
>> stringobject.c. stringobject.h then also provides aliases
>> so that recompiled extensions pick up the new API names.
>>
>> While working on my patch I ran into an issue that I haven't
>> been able to resolve: the wrapper functions got optimized away
>> by the linker and even though they appear in the libpython2.6.a,
>> they don't end up in the python binary itself.
>>
>> As a result, importing Python 2.5 in the resulting 2.6
>> binary still fails with a unresolved PyString symbol.
>>
>> Please check whether that's the case for your patch as well.
>
> I think that is going to happen no matter which approach is used (yours or
> mine) unless we force some included code to call each of the stubs
> (needlessly inefficient).  One way to do that is to reference them all from
> a section of code called conditionally based upon an always false condition
> that the compiler and linker can never predetermine is false so that it
> cannot be eliminated as dead code.
>
> Given that, should we bother?  I don't think we really need PyBytes_ to show
> up in the binary ABI for 2.x even if that is how we write the calls in the
> python internals code.  The arguments put forth that debugging is easier if
> you can just set a breakpoint on what you read may be true but including
> stub functions doesn't help this when most of the time they're compiled
> under the alternate name using #defines so a breakpoint set on the stub name
> will not actually trigger.
>
> API wise we're really providing the PyBytes* names to make module author's
> work of writing code that targets 2.6 and 3.x easier but isn't it reasonable
> for authors to just be told that they're just #defined aliases for
> PyString*.  There is no goal, nor should there be, of a module binary
> compiled against 2.x loading and working in 3.x.
>
> I expect most module authors, code generators and such will want to target
> Python 2.x earlier than 2.6 as well so should we provide PyBytes_ names as a
> public API in 2.6 at all?  (regardless of if we use the PyBytes names
> internally for any reason)
>
> -gps
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)