[Python-Dev] PEP 393 Summer of Code Project

Torsten Becker torsten.becker at gmail.com
Wed Aug 24 04:41:20 CEST 2011


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.

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


Regards,
Torsten


More information about the Python-Dev mailing list