Marc-Andre Lemburg <m...@egenix.com> added the comment: Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg <m...@egenix.com> added the comment: > > STINNER Victor wrote: >> >> STINNER Victor <victor.stin...@haypocalc.com> added the comment: >> >> I'm reposting my patch from #12751. I think that it's simpler than >> belopolsky's patch: it doesn't add public macros in unicodeobject.h and >> don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private >> macros in unicodeobject.c to factorize the code. >> >> I don't want to add public macros because with the stable API and with the >> PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject >> internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside >> unicodeobject.c. > > PEP 393 is an optional feature for extension writers. If they don't > need PEP 393 style stable ABIs and want to use the macros, they > should be able to. I'm therefore -1 on making them private.
Sorry, I mean PEP 384, not PEP 393. Whether PEP 393 will turn out to be a workable solution has yet to be seen, but that's a different subject. In any case, Py_UNICODE and access macros for PyUnicodeObject are in wide-spread use, so trying to hide them won't work until we reach Py4k. > Regarding separating adding the various surrogate macros and > the next-macros: I don't see a problem with adding both in > Python 3.3. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10542> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
