On Jan 27, 2010, at 10:55 AM, Oliver Tonnhofer wrote:
>
> On 27.01.2010, at 10:01, Sean Gillies wrote:
>> We could version the base class as well. The advantage being that
>> versioned classes wouldn't advertise methods that aren't implemented
>> and you could test capabilities with hasattr(). The disadvantage is
>> more code to maintain and potential for surprises when the base class
>> of our geometries isn't determined until run time. I was planning to
>> save those surprises for version 2.0 ;)
>>
>> I could be persuaded that the new project and interpolate methods be
>> decorated to raise NotImplementedError if there's no support in the
>> proxy. But that doesn't help the case where one wants to test with
>> hasattr(). I suppose we remove unsupported methods from the base
>> class's __dict__ at runtime (at the end of base.py). Any of these
>> approaches appeal to you?
>
>
> I would prefer the second approach, keep one base class and allow
> hasattr() checks.
>
> What about the GEOS/CAPI version checks? I guess I failed to make
> myself clear. One part is what happens when someone tries to use a
> feature that is not available. hasattr() checks would be great for
> that. That's all fine, but the other part is that shapely does not
> start at all when the ctypes_declaration tries to set argument/result
> specs for functions that are not available. That's what happens with
> the current 1.2 branch version and GEOS 3.1.1.
>
> Maybe we should remove all geos_c_version checks. Then we just catch
> all AttributeErrors in ctypes_declaration and build a feature
> dictionary with that information ({'prepared': True, 'project':
> False}). This dict could then be used internally to check if a feature
> is supported, i.e. if a method should be added to the base class, etc.
> A little hackish, maybe, i don't know :)
Yes, I overlooked #202, but have a fix for it in r1533 that I tested
with GEOS 3.1.1.
A map of shapely method names to lgeos functions would be handy in a
couple places, and lets us further hide the implementation details
from base.py, so I don't think this would be a bad idea at all.
--
Sean
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
