pyshapelib and unicode (was: release number?)

Bram de Greve bram.degreve at gmail.com
Thu Dec 6 12:16:25 CET 2007


Bernhard Herzog wrote:
> pyshapelib was primarily meant to be a python wrapper for shapelib.  As such 
> it should be reasonably close to shapelib itself and reasonably compatible 
> with older pyshapelib releases.  Automatic translation between unicode and 
> the dbf file's encoding is not necessarily important in pyshapelib itself.  
> However, unicode will be the preferred data type for text in Python 3 and 
> builtin support for it is probably a good idea in pyshapelib.  At the same 
> time, pyshapelib should provide access to all features of shapelib, so a way 
> to get at the raw bytestrings might be important too.
>   

I can completely agree with that ...

>   
>> OTOH, I might do it in a configurable way.  For example: dbflib returns
>> raw encoded strings by default, unless you do something like this:
>>
>> import dbflib
>> dbflib.return_unicode = True
>>
>> or even individually on each file:
>>
>> dbf = dbflib.open(u"foobar", return_unicode=True)
>>     
>
> The latter version is much better.  Such settings should not be globals in a 
> library.
>
>   
I very much favor the latter version as well.  It just seems neater that
way: maximum control.  OTOH, most applications would want to use the
same style all over the place.  So, if they want to return unicode all
over the place, then specifying return_unicode=True might prove a burden
and be errorprone.  Then, a global setting that can be overridden on
individual files might be more useful.  But then again, that's just as
much error prone when two pieces of code are merged that think otherwise
about the default.  So yes, I'll agree with you.  The all-unicode guys
can always write a wrapper if they want.   udbflib.py =)

Bram




More information about the Thuban-devel mailing list

This site is hosted by Intevation GmbH (Datenschutzerklärung und Impressum | Privacy Policy and Imprint)