Hi All, I have a need to be able to adapting certain objects to None, eg: def some_adapter(obj): if something: return None return somethingelse This is tricky, since returning None from an adapter results in a TypeError. I eventually came up with the idea of having a subclass of Interface do what I needed: empty = object() class IFieldType(Interface): def __call__(self,*args,**kw): r = Interface.__call__(*args,**kw) if r is empty: return None return r I suspect this would work with the python implementation of Interface, but it certainly doesn't with the C implementation. What am I doing wrong and how can I achieve what I'm after? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2008-12-13 02:17 +0000:
I have a need to be able to adapting certain objects to None, eg:
def some_adapter(obj): if something: return None return somethingelse
Your use case seems to abuse adaptation: Adaptation to an interface must always return an object which provides the interface. "None", by default, only provides very few interfaces (not sure whether you can extend this set with 'alsoProvides'). I think that in some cases, it would be useful for an adapter factory to say 'I cannot handle this case' and then the adapter lookup is continued. Maybe, this is already supported? Then, maybe, you can use it? -- Dieter
Dieter Maurer wrote:
I think that in some cases, it would be useful for an adapter factory to say 'I cannot handle this case' and then the adapter lookup is continued. Maybe, this is already supported? Then, maybe, you can use it?
That's exactly what returning None indicates...
def some_adapter(obj): if something: return None return somethingelse
Your use case seems to abuse adaptation:
Adaptation to an interface must always return an object which provides the interface. "None", by default, only provides very few interfaces
...indeed, however, I really do want to return None here. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2008-12-13 10:18 +0000:
Dieter Maurer wrote:
I think that in some cases, it would be useful for an adapter factory to say 'I cannot handle this case' and then the adapter lookup is continued. Maybe, this is already supported? Then, maybe, you can use it?
That's exactly what returning None indicates...
def some_adapter(obj): if something: return None return somethingelse
Your use case seems to abuse adaptation:
Adaptation to an interface must always return an object which provides the interface. "None", by default, only provides very few interfaces
...indeed, however, I really do want to return None here.
Then, use something different from adaptation (as adaptation does not fit your wishes). I expect that your adapter factory can raise "ComponentLookupError" when it cannot handle the adaptation and then the "default" argument of the adapter lookup will take effect. adapter = IMyInterface(obj, None) if adapter is None: # adaptation impossible .... def adapter_factory(...): ... raise ComponentLookupError() -- Dieter
Dieter Maurer wrote:
Then, use something different from adaptation (as adaptation does not fit your wishes).
This is what I'm trying to do with subclassing, and my question was why that subclassing wasn't working...
I expect that your adapter factory can raise "ComponentLookupError" when it cannot handle the adaptation and then the "default" argument of the adapter lookup will take effect.
adapter = IMyInterface(obj, None)
...which might work, except I'd want that None to be the default and with no need to specify it. The pythonic way to do this would be to make IMyInterface a subclass of Interface (which it is) and tweak the implementation of whatever implements IMyInterface(...), which is exactly what I'm trying to do. From looking at the python implementation of Interface, __call__ is indicated to be the method to override, but with the C-based Interface, this has no effect. Why is that? *That's* what I'm looking for help with, not judgement on whether adapting to None is a good idea or not ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Sat, Dec 13, 2008 at 10:42:09AM +0000, Chris Withers wrote:
Dieter Maurer wrote:
Then, use something different from adaptation (as adaptation does not fit your wishes).
This is what I'm trying to do with subclassing, and my question was why that subclassing wasn't working...
Subclassing is not always the one true solution for all problems.
I expect that your adapter factory can raise "ComponentLookupError" when it cannot handle the adaptation and then the "default" argument of the adapter lookup will take effect.
adapter = IMyInterface(obj, None)
...which might work, except I'd want that None to be the default and with no need to specify it.
The pythonic way to do this would be to make IMyInterface a subclass of Interface (which it is) and tweak the implementation of whatever implements IMyInterface(...), which is exactly what I'm trying to do.
I don't think this is the right solution. It makes one interface very different from all the other interfaces. It is a Zope Component Architecture invariant that if adapter = ISomeInterface(something) doesn't fail with an exception, I can assume that ISomeInterface.providedBy(adapter) and I can access methods and call attributes on ``adapter``. Now, it's perfectly understandable that you want something that doesn't act this way, but I'd suggest you make it not look like adaptation then. How about defining def GetItOrDontBother(obj): return IMyInterface(obj, None) once and using it instead? Or, if you want to distinguish "my adapter returned None" from "I forgot to register the adapter in my test fixture", how about def my_adapter(obj): if something: ... else: return NotImplemented def GetItOrDontBother(obj): adapter = IMyInterface(obj) if adapter is NotImplemented: adapter = None return adapter
*That's* what I'm looking for help with, not judgement on whether adapting to None is a good idea or not ;-)
Could you please describe the real problem you're solving? We can't help being judgemental when you seem to be asking the equivalent of "I want to use a glass bottle to pound a nail, how can I make sure it won't shatter? (Trust me, I really want to use a glass bottle here.)" -- http://pov.lt/ -- Zope 3 consulting and development
Marius Gedminas wrote:
doesn't fail with an exception, I can assume that
ISomeInterface.providedBy(adapter)
...which in this case should return True, as None does indeed implement the interface in question.
*That's* what I'm looking for help with, not judgement on whether adapting to None is a good idea or not ;-)
Could you please describe the real problem you're solving?
I have a generic IFieldType (well, could arguably be called IFieldValue) adapter, which subclasses, eg: class IFieldType(Interface): pass class number(IFieldType): pass class text(IFieldType): pass class date(IFieldType): pass class empty(IFieldType): pass ...etc.. The idea being that you can do things like: text(anything) ...and if there's an adapter for it, it gets called and you get back something that implements IFieldType. This couples nicely with, for example: classImplements(unicode,text_type) classImplements(int,number_type) classImplements(float,number_type) classImplements(date,date_type) classImplements(type(None),empty) def str_to_date(str): return parse(str,dayfirst=True) provideAdapter(str_to_date,(str,),date) Now, you could, for example, then do: IFieldType([]) ...which should return None. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Shane Hathaway wrote:
Chris Withers wrote:
Now, you could, for example, then do:
IFieldType([])
...which should return None.
I don't understand your example: what is a field type,
It's a shortened naem for "Type of Field Value", as I said, it could arguably be called IFieldValue, or maybe even IValue or IValueType...
and why is None somehow a valid field type?
None occurs quite often as a default value for fields and types of fields. (like NULL in relational databases). This is all interesting discussion, but I'd *really* like to know why subclassing an interface when the C-based implentation is in use doesn't work. Does *anyone* actually know the answer to this? (rather than avoiding it by trying to make the problem something else ;-) ) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
This is all interesting discussion, but I'd *really* like to know why subclassing an interface when the C-based implentation is in use doesn't work.
Does *anyone* actually know the answer to this? (rather than avoiding it by trying to make the problem something else ;-) )
This is a completely different question, so I've changed the subject line for you. Shane
Chris Withers wrote at 2008-12-13 10:42 +0000:
... From looking at the python implementation of Interface, __call__ is indicated to be the method to override, but with the C-based Interface, this has no effect. Why is that?
*That's* what I'm looking for help with, not judgement on whether adapting to None is a good idea or not ;-)
I am very pleased that adaptation poses some resistance to the abuse of its semantics ;-) I *DO* want that I can rely on the result of "IInterface(...)" really providing "IInterface" (and not be forced to check against all potential values others invented to circumvent the adaptation semantics). Thus, I hope, you will not get your wish :-) -- Dieter
Dieter Maurer wrote:
I *DO* want that I can rely on the result of "IInterface(...)" really providing "IInterface" (and not be forced to check against all potential values others invented to circumvent the adaptation semantics). Thus, I hope, you will not get your wish :-)
FFS, I'm not asking for the semantics of the Interface class to change, I'm asking why subclassing (which is a pretty fundamental part of the python language!) doesn't work correctly with interfaces... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers <chris <at> simplistix.co.uk> writes:
Hi All,
I have a need to be able to adapting certain objects to None, eg:
def some_adapter(obj): if something: return None return somethingelse
This is tricky, since returning None from an adapter results in a TypeError.
I eventually came up with the idea of having a subclass of Interface do what I needed:
empty = object()
class IFieldType(Interface): def __call__(self,*args,**kw): r = Interface.__call__(*args,**kw) if r is empty: return None return r
I suspect this would work with the python implementation of Interface, but it certainly doesn't with the C implementation.
What am I doing wrong and how can I achieve what I'm after?
If the result of an adaptation is None, it means something very specific to the CA. That TypeError is specifically a 'Could not adapt' TypeError, which is similar to a ComponentLookupError but with a slightly different meaning (not sure why the CA doesn't use a custom exception for this). This feature allows you to create an adapter which is capable of inspecting its arguments and determining that it's not capable of adapting those particular objects. Because an adapter that returns None has this specific meaning, you can't actually adapt something to None. You'll have to use queryAdapter or explicitly handle the exception. Alec
Alec Mitchell wrote:
class IFieldType(Interface): def __call__(self,*args,**kw): r = Interface.__call__(*args,**kw) if r is empty: return None return r
I suspect this would work with the python implementation of Interface, but it certainly doesn't with the C implementation.
What am I doing wrong and how can I achieve what I'm after?
If the result of an adaptation is None, it means something very specific to the CA.
Indeed, which is why I'm trying to subclass this interface so that its subclasses behave slightyl differently...
That TypeError is specifically a 'Could not adapt' TypeError, which is similar to a ComponentLookupError but with a slightly different meaning (not sure why the CA doesn't use a custom exception for this).
...because it provides more information about what went wrong, which is extremely useful.
This feature allows you to create an adapter which is capable of inspecting its arguments and determining that it's not capable of adapting those particular objects. Because an adapter that returns None has this specific meaning, you can't actually adapt something to None. You'll have to use queryAdapter or explicitly handle the exception.
Yeah, except that creates duplicate code expressions all over the place. Why doesn't subclassing work? (this is the one and only question I've been looking to get an answer to for the whole of this thread ;-) ) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (5)
-
Alec Mitchell -
Chris Withers -
Dieter Maurer -
Marius Gedminas -
Shane Hathaway