[Python-Dev] PEP 393 Summer of Code Project

[Victor Stinner]

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