WIP-pyshapelib-Unicode issues

[Bram de Greve]

Bernhard Reiter wrote:
> Hi Bram,
>
> On Wednesday 09 January 2008 11:47, Bram de Greve wrote:
>   
>> I've committed some changes to the unicode branch.  I've fixed copyright
>> infos and headers, the README, added an entry in NEWS for 0.4, and did some
>> other work on the source code as well.  The compiler warnings should be
>> gone.
>>     
>
> cool, I saw some of the commits happening, but hunted the empty shape file 
> problem. (Does somebody know, btw, if such a shape file is legitimate at 
> all?)
>
>   
Why would it not be legitimate?  I've skimmed the specs and found no
such thing (about being illegal).
>> *
>> test_transientdb.TestTransientTable.{test_auto_transient_table|test_transie
>> nt_table}:
>>
>> the shapelib C library returns integer numerical fields with more than 10
>> digits as double (in order to avoid an overflow with the C int).  This is
>> causing the test to fail as an 'int' is expected for column 3, and an
>> 'double' is found.  Bernard Herzog suggests to let pyshapelib convert them
>> back to Python long integers.  On the Python API level this can easily be
>> done using PyLong_FromDouble.  Is it OK to mix long integers and "short"
>> integers, or should all integers coming from pyshapelib be converted to
>> long ints?
>>     
>
> Probably one class of objects should always have the same representation,
> so if "long" is sufficient for ids, so why not use it for all ids?
> This seems consistent. If there are values where (int *) is sufficient, 
> we could use this. 
>
>   
It turns out dbfopen.c reads all numbers as double anyway.  Only if it
things it's an integer and will fit in a C int (and thus be of type
FTInteger), it casts the double to an int at the very last moment
possible.  I'm skipping that cast now and use PyLong_FromDouble to
_always_ cast doubles to long integers iif the number of decimals is
zero.  That's two errors less in the unittests =)


Cheers,
Bramz