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 :)
Regards,
Oliver
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
