[Csv] non-portable initialisation of types in _csv.c

[Andrew McNamara]

>>> 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/