M.-A. Lemburg wrote:
* Why can't we have both PyString *and* PyBytes exposed in 2.x,
with one redirecting to the other ?
We do have that - the PyString_* names still work perfectly fine in 2.x.
They just won't be used in the Python core codebase anymore - everything
in the Python core will use either PyBytes_* or PyUnicode_* regardless
of which branch (2.x or 3.x) you're working on. I think that's a good
thing for ease of maintenance in the future, even if it takes people a
while to get their heads around it right now.
* 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
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
