[Csv] non-portable initialisation of types in _csv.c
Andrew McNamara
andrewm at object-craft.com.au
Fri Feb 14 07:03:18 CET 2003
>>> John> /* aarrgghh PyObject_HEAD_INIT(&PyType_Type) */
[...]
>>The offending code is strictly not correct C -- the initialiser is not a
>>constant; it's the address of a gadget not declared in the current source
>>file. However some compiler/linker combinations can nut it out. Some
>>compilers take advantage of this; some can't or won't; Windows compilers
>>seem to be in the can't or won't category.
Indeed - thanks for picking this up. I can only assume it was a
cut-n-paste accident, because it was originally PyObject_HEAD_INIT(0).
>>Skip, what's sauce for the first goose is also sauce for the second and
>>subsequent geese. You seem to have sauced all 3 birds in rev 1.30.
Thanks Skip - all three needed doing.
>>I notice that it seems to work without the "FooType.ob_type =
>>&PyType_Type;" incantation in the module initialisation. Perhaps
>>PyType_Ready() fixes this up.
>
>Yes, that's one of the things it does. Perhaps it would have been better
>named as "PyType_MakeReady".
And the consequences of *not* calling PyType_Ready() are particularly
obscure. There's enough information to allow the Python core to assert
if a type hasn't been finalised - I wonder why it doesn't?
>The issue of 8-bit next-to-godliness will probably have to be
>addressed once Unicode is tackled.
Definitely not this go around, anyway. I doubt it's lack is a big deal
(lack of unicode is a bigger deal) - since CSV is a text format, finding
a null in the input would be very unusual (and I wouldn't be surprised
if excel choked too... 8-).
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
More information about the Csv
mailing list