On Thu, May 29, 2008 at 3:57 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > M.-A. Lemburg wrote: >> * Why should the 2.x code base turn to hacks, just because 3.x wants >> to restructure itself ? > > With the better explanation from Greg of what the checked in approach > achieves (i.e. preserving exact ABI compatibility for PyString_*, while > allowing PyBytes_* to be used at the source code level), I don't see what > has been done as being any more of a hack than the possibly more common > "#define <oldname> <newname>" (which *would* break binary compatibility). > > The only things that I think would tidy it up further would be to: > - include an explanation of the approach and its effects on API and ABI > backward and forward compatibility within 2.x and between 2.x and 3.x in > stringobject.h > - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
Yes that is the only complaint I believe I really see left at this point. It is easy enough to fix. Change the current stringobject.h "#define PyBytes_Foo PyString_Foo" approach into a .c file that defines one line stub functions for all PyString_Foo() functions to call actual PyBytes_Foo() functions. I'd even go so far as to put the one line alternate name stubs in the Objects/bytesobject.c and .h file right next to the PyBytes_Foo() method definitions so that its clear from reading a single file that they are the same thing. The performance implications of this are minor all things considered (a single absolute jmp given a good compiler) and regardless of what we do should only apply to extension modules, not the core. If we do the above in trunk will this thread end? I'm personally not really clear on why we need PyBytes_Foo to show up in the -binary- ABI in 2.6. The #define's are enough for me but I'm happy to make this compromise. No 2.x books, documentation or literature will be invalidated by the changes regardless. -gps _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
