[Python-Dev] PEP 393 Summer of Code Project (original) (raw)

Victor Stinner victor.stinner at haypocalc.com
Wed Aug 24 10:10:17 CEST 2011

Le 24/08/2011 04:41, Torsten Becker a écrit :

On Tue, Aug 23, 2011 at 10:08, Antoine Pitrou<solipsis at pitrou.net> wrote:

Macros are useful to shield the abstraction from the implementation. If you access the members directly, and the unicode object is represented differently in some future version of Python (say e.g. with tagged pointers), your code doesn't compile anymore. I agree with Antoine, from the experience of porting C code from 3.2 to the PEP 393 unicode API, the additional encapsulation by macros made it much easier to change the implementation of what is a field, what is a field's actual name, and what needs to be calculated through a function. So, I would like to keep primary access as a macro but I see the point that it would make the struct clearer to access and I would not mind changing the struct to use a union. But then most access currently is through macros so I am not sure how much benefit the union would bring as it mostly complicates the struct definition.

An union helps debugging in gdb: you don't have to cast manually to unsigned char*/Py_UCS2*/Py_UCS4*.

Also, common, now simple, checks for "unicode->str == NULL" would look more ambiguous with a union ("unicode->str.latin1 == NULL").

We can rename "str" to something else, to "data" for example.

Victor

More information about the Python-Dev mailing list