On Tue, Aug 23, 2011 at 7:41 PM, Torsten Becker
<torsten.bec...@gmail.com> wrote:
> On Tue, Aug 23, 2011 at 10:08, Antoine Pitrou <solip...@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.
+1
> Also, common, now simple, checks for "unicode->str == NULL" would look
> more ambiguous with a union ("unicode->str.latin1 == NULL").
You could add an extra union field for that:
unicode->str.voidptr == NULL
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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
