Against PEP 240

[Robin Becker]

In article <0E0E06297253FE1B.D13D6C3BAEE41AD8.4A273FCB042833CB at lp.airnew
s.net>, Cameron Laird <claird at starbase.neosoft.com> writes
>Let's be precise:  extensions that pass float-
>ing point data will all be broken.  I don't
>regard broken extensions lightly; I know what
>a cost it can be to reassemble all the parts
>just to recreate what one had before.  Do you
>agree there'd be value in adding a coda to the
>PEP about how to rewrite extensions?  Shall
>part of the PEP be a function on the C side
>that helps ease the task?
>>
well thinking about this a bit it seems that direct arguments will have
an f type argument flag and then the conversion should be supplied by
the interface mechanisms. Indirect arguments will be the problem and
therefore stuff that used to be fine eg

myextension.func([1.4,2.3]) will very likely need to be looked at.

If I had made the assumption that these were numbers then it's likely
that some kind of conversion to float is already present. The problem is
then whether that works when rationals are added to the mix. Since the
above [f0,f1,....] kind of thing is fairly common some kind of support
for converting this list to a vector of x would probably be most useful.
We already have a tuple format indicator, but this requires explicit
format indicators for everything inside.

I guess we should really ask the Numpy authors to comment on things they
would like to see in the C api. I know that a lot of extension writing
is about getting the arguments in and out and they have a bunch of
mechanisms for doing that.
-- 
Robin Becker