Re: [Zope3-dev] should schema.Date accectp datetime values
On 11/14/06, Bernd Dorn <[EMAIL PROTECTED]> wrote: i just saw that zope.schema.Date objects accept datetime values because the default validate implementation uses isinstance to check the value. this is a problem imho, because datetime is a subclass of date but instances can't be compmared to each other. Agreed. any problems with this? and if no, is it ok to backport it to 3.3 I don't know. It seems like a bug to me, but I'm no bastion of backward-compatibility. i also tried using type instead of instance in the base implementation of the validate method, but this affects i18n messages, because they are not unicode. The implementation is sensitive, I suppose. The patch you include looks fine to me. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] should schema.Date accectp datetime values
hi all i just saw that zope.schema.Date objects accept datetime values because the default validate implementation uses isinstance to check the value. this is a problem imho, because datetime is a subclass of date but instances can't be compmared to each other. so what are you guys thinking about handling this case in schema.Date any problems with this? and if no, is it ok to backport it to 3.3 i also tried using type instead of instance in the base implementation of the validate method, but this affects i18n messages, because they are not unicode. here my diffs, regards Bernd Index: tests/test_date.py === --- tests/test_date.py (revision 70847) +++ tests/test_date.py (working copy) @@ -17,7 +17,7 @@ """ from unittest import main, makeSuite from zope.schema import Date -from zope.schema.interfaces import RequiredMissing, InvalidValue +from zope.schema.interfaces import RequiredMissing, InvalidValue, WrongType from zope.schema.interfaces import TooSmall, TooBig from zope.schema.tests.test_field import FieldTestBase from datetime import datetime, date @@ -37,6 +37,7 @@ readonly=False, required=False) field.validate(None) field.validate(datetime.now().date()) +self.assertRaises(WrongType, field.validate, datetime.now()) def testValidateRequired(self): field = self._Field_Factory(title=u'Date field', description=u'', Index: _field.py === --- _field.py (revision 70847) +++ _field.py (working copy) @@ -205,6 +205,11 @@ __doc__ = IDate.__doc__ implements(IDate) _type = date + +def _validate(self, value): +super(Date, self)._validate(value) +if isinstance(value, datetime): +raise WrongType(value, self._type) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Martijn Faassen wrote: Martin Aspeli wrote: Martijn Faassen wrote: Oh, I disagree. It's much nicer to be able to be able to start with adapting classes, and introduce interfaces later, where necessary. Often they're not. In fact it's already possible to adapt classes and register views for classes. In ZCML I believe there's some limitations with one directive or other (a bug), at least there was, but the component architecture has allowed this for a long time. We've been very happily using this in grok. I see your point of view - and I guess there is a balance here. y'all agree. :) However, I think that one of the big benefits we see in Zope2/CMF/Plone over "the old way" is that people seem to take interfaces more seriously now, and with them internal documentation. Having well-thought-out and well-documented interfaces encouages API stability and re-use Yup, assuming that that is a goal. Sometimes, it isn't. and makes it easier to understand someone else's code. Likewise. :) >> By contrast, we often end up with jungles of APIs and no-one can quite decide whether they're stable or not, when programmers are given no hooks on which to hang their design. That can happen with interfaces too. Yes, but with Plone and CMF and Zope 2 we already have a lot of existing classes, so it makes sense to introduce interfaces: it is more clear what they should be. It's a lifecycle thing; early on in a project explicit interfaces may be overkill. If a project never grows beyond a certain size it might be permanent overkill, actually. Later on in a project where extensibility and explicit specification and programming by third parties and so on becomes important interfaces make lots of sense. Do as you wish, of course. I find that abstract discussions like this typically end up being a lot of talk over apparent disagreement that disappears when it comes down to practical design. Of course. It's all a matter of tradeoffs. Disagreement does exist in practical design as well though. In particular, the Zope 3 explicit interfaces and components everywhere approach sometimes leads to overengineering where simple Python patterns would've done much better. Let's please not call this the Zope 3 approach. As Pope, I officially declare that the Zope 3 approach is interfaces and components (and doctests) where appropriate. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3.3.1 release
Christian Theune wrote: Hi, Martijn Faassen wrote: originally we intended to do a Zope 3.3.1 release in November to get virtually bug free. I didn't see any momentum on this. How about a bug day? I'm supposed to be the release manager for this too. I was hoping someone else would volunteer but of course I already committed to this, so I should pick up on this myself. :) I wouldn't mind to do that, if you want to get some load off. It could let me exercise a bit for the next major release that I've taken over anyway. (OTOH we did agree to distribute the task amongst different people to have more people know about the release management process ...) Since I'm unfortunately not able to be there tomorrow at the bugday, I'd be very happy if you could take this load off my shoulders. I will definitely help with some release at *some* point in the future, though. :) Thanks! Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] z3c.widget.flashupload and compression? [bit OT]
Hello, I'm a little bit offtopic with my question here. We had here the idea to implement a compression algorhitm in the above package to save some precious upload bandwith. I'm not a flash professional, google did not spit out straightforward solutions. Any ideas, pointers, help is appreciated. -- Best regards, Adam mailto:[EMAIL PROTECTED] -- Quote of the day: Some are atheists by neglect; others are so by affectation; they that think there is no God at some times do not think so at all times. - Benjamin Whichcote ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] adaptation based on class rather than interface
Martin Aspeli wrote: Martijn Faassen wrote: Oh, I disagree. It's much nicer to be able to be able to start with adapting classes, and introduce interfaces later, where necessary. Often they're not. In fact it's already possible to adapt classes and register views for classes. In ZCML I believe there's some limitations with one directive or other (a bug), at least there was, but the component architecture has allowed this for a long time. We've been very happily using this in grok. I see your point of view - and I guess there is a balance here. However, I think that one of the big benefits we see in Zope2/CMF/Plone over "the old way" is that people seem to take interfaces more seriously now, and with them internal documentation. Having well-thought-out and well-documented interfaces encouages API stability and re-use and makes it easier to understand someone else's code. By contrast, we often end up with jungles of APIs and no-one can quite decide whether they're stable or not, when programmers are given no hooks on which to hang their design. Yes, but with Plone and CMF and Zope 2 we already have a lot of existing classes, so it makes sense to introduce interfaces: it is more clear what they should be. It's a lifecycle thing; early on in a project explicit interfaces may be overkill. If a project never grows beyond a certain size it might be permanent overkill, actually. Later on in a project where extensibility and explicit specification and programming by third parties and so on becomes important interfaces make lots of sense. Do as you wish, of course. I find that abstract discussions like this typically end up being a lot of talk over apparent disagreement that disappears when it comes down to practical design. Of course. It's all a matter of tradeoffs. Disagreement does exist in practical design as well though. In particular, the Zope 3 explicit interfaces and components everywhere approach sometimes leads to overengineering where simple Python patterns would've done much better. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] onlinehelp i18n aware
Hello, I meet a usecase that i don't really see how to solve. My users need some kind of contextual help and these help files need to be in different languages. I looked closer at onlinehelp but it seems that no i18n link have been done. I was wondering if you might have an idea on how to implement this in a nice way ? Early thanks a lot for you help. Jeff ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adaptation based on class rather than interface
On 11/13/06, Jean-Marc Orliaguet <[EMAIL PROTECTED]> wrote: yes, but if you register an adapter for a base class you don't have to register it for subclasses, do you? I don't know, but again you then need to either subclass or re-register for that calss, but if you register it for an interface, you can eiterh subclass or implement the interface. subclasses will pick up the same adapter. Provided that you use classes for typing your objects and not interfaces. Class and interfaces do different kinds of "typing". You do both, normally. > I'm not sure the proliferication (?) of marker interfaces is a big > risk. But if we get many of them, it still works better than the > options of magic __something__ attributes. :) but conceptually it is the same mess :-) i.e. a total lack of specification. I don't agree with that at all. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Chris Withers wrote: Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a "function" and a "class" Nope. It's a class since Python 2.2. ...hence the quotes. It's a "function" in that I want to use it as an adapter that doesn't need to be instantiated by a factory before being used. All adapters need to be instantiated. A function can serve as much as an adapter factory as a class. ...and factory="str" is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) Huh? You got that wrong. IString(1) will call str(1) if provideAdapter(str, (int,), IString). right, but factory="" registers and adapter factory, not an adapter and provideAdapter registers an adapter directly, correct? No. You always register a factory which is called upon lookup. That's because adapters are context-dependent and thus need to be instantiated every time you look them up. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
whit wrote: hello RuleDispatch... What's RuleDispatch? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: Heh, in this case using 'IString' is really a "trussed duck" (duck typing with B&D) ;) Python's duck typing breaks down with strings, because they can by "quack tested" like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. True, and I guess for my uses, I'd be wanting to register adapter both too and from basestr, since that'd cover unicodes too, unless that would be bad ;) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a "function" and a "class" Nope. It's a class since Python 2.2. ...hence the quotes. It's a "function" in that I want to use it as an adapter that doesn't need to be instantiated by a factory before being used. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... Not really. It's the ability to register the adapter, and change which adapter you choose to use that's important for me here. I think it should be fine to adapt to a class if you can adapt from a class. Is there anything in the implementation that actually prevents this? (which I, for one, would consider a bug) should be: provide="str" Wtf? Then why do you need an adapter? See above. I thought you wanted to say IString(1) instead of str(1) to be more flexible...? Hmm, I see your point, but there are other ways to get an adapter than by calling an interface ;-) (and I think I'd need to use those here, since there is no interface) ...and factory="str" is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) Huh? You got that wrong. IString(1) will call str(1) if provideAdapter(str, (int,), IString). right, but factory="" registers and adapter factory, not an adapter and provideAdapter registers an adapter directly, correct? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
