Re: [Zope-dev] adapting to None
Chris Withers wrote at 2008-12-13 10:42 +: > ... > 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fwd: Help with RelStorage ...
Gareth Bult wrote: > I'm having a bit of a problem that looks like a 32 bit vs 64 bit issue > with RelStorage, can anyone help? We need to get more people to use RelStorage so more people can help. :-) This looks like a good clue: > == > FAIL: checkLoadBefore (__main__.MySQLTests) > ———- > Traceback (most recent call last): > File > “/opt/Plone-3.1/Python-2.4/lib/python2.4/site-packages/ZODB3-3.8.1-py2.4-linux-x86_64.egg/ZODB/tests/RevisionStorage.py”, > > line 62, in checkLoadBefore > assert prev < middle < cur # else the snooze() trick failed > AssertionError To debug this, I would add a pdb.set_trace() near this line and examine the variables when this code fails. Apparently prev >= cur, which suggests MySQL might be generating bad timestamps. Ooooh... how about this: ensure the MySQL server and the client are set to the same time zone and have synchronized clocks (using NTP), then run the tests again. If that solves the problem, then we need to add a note about clocks in the documentation. MySQL does not provide a fine grained current_timestamp() function, so RelStorage has a workaround that uses the client's timestamp instead. The workaround is disabled if the client and server are more than 60 seconds apart. I forgot to call this out in the documentation, and I would really like to find a better solution. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Fri Dec 12 12:00:00 2008 UTC to Sat Dec 13 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 12 20:37:00 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010643.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Fri Dec 12 20:38:30 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010644.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Fri Dec 12 20:30:59 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010639.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 12 20:32:29 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010640.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 12 20:34:00 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010641.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Fri Dec 12 20:35:30 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010642.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
On Sat, Dec 13, 2008 at 10:42:09AM +, 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 signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers wrote at 2008-12-13 10:18 +: >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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers wrote at 2008-12-13 02:17 +: >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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
