Re: [Zope-dev] adapting to None
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, and why is None somehow a valid field type? 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
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 ___ 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Christian > Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? > [Re:zope.browser?] > > On 2008-12-15 13:44:43 +0100, "Roger Ineichen" > said: > > > Hi Christian > > > >> Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: > >> zope.browser?] > > > > [...] > > > A deprecation warning isn't bad. But I think we should not > >> deprecate > the use of ITerms from zope.app.form. I don't see a gain > >> in this API > change. > >>> Imo it's a bad idea to keep exactly the same interface in 2 > >> places. At > >>> least i don't see an improvement or convenience in keeping it. > >>> > >>> the only real reason to keep it is for legacy reasons, but import > >>> adoption should not be that hard ;) > >> > >> No it is not. I just question why we force everybody to > use the new > >> location when we did not do so with ISite. It is exactly the same > >> issue with two different outcomes. > >> > >> The canonical location for ISite is zope.location now. It used to > >> reside in zope.app.component but was moved to zope.location w/o > >> deprecating the use from zope.app.location to keep the API > backward > >> compatible. I really do not see a differrence to ITerms here. > > > > This doesn't have to do with bachward compatibility. Deprecated > > imports are backward compatible too. I think someone just missed to > > deprecate that interface. > > Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html > > > > > > > The reason why we should deprecate interfaces is: If a > package still > > points to the old interface location, this package whould > bring in the > > old dependency we tried to remove. > > Depends. See below. > > > > > I guess, since you are asking for support the old location, this > > doesn't hurt you because you are using both packages. > > Others don't. Any other packages which doesn't adjust the import to > > the new location will hurt others which do not use both packages. > > If there is a packe which uses ITerms but not zope.app.form > this must be updated then. For packages which use > zope.app.form this is not so important. I think they will be > updated sooner or later when code is touched anyway because > the new import is much shorter. But the deprecation *forces* > everybody to update now. And this interface is used in *many* places. > > > > > I see that this makes it more a good thing for others then for > > yourself. But I think that's fine. Isn't it? > > > > > > > In my point of view, deprecation messages are a great concept to > > announce changes/improvments without to break compatibility. > > Without such announcements our code can get very quick out > of date and > > we have no change to know about that. > > Yes, for necessary API changes which do not need to be > shipped immeadiately I can see that. > > > > > > btw, > > we also should deprecate the ISite interface at the old location. > > Same question: what would you gain here? Packages are slowly migrated > to using the new ISite import but nobody is forced to change all the > code right now to get rid of all the deprecation warnings. All I can say about that is: If there is an improvment in the API we need to announce that. Otherwise other developer will not follow or follow at a time they think it's better for them. Or even worse, they don't know about that. Deprecation messages will kick them a little bit and they get forced to update their code in a acceptable way ;-) The question now is, should we be lazy and skip this information and support nice deprecation free test output or support developer with information about the newest API changes in form of deprecation message hints? Regards Roger Ineichen ___ 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] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On 2008-12-15 13:44:43 +0100, "Roger Ineichen" said: > Hi Christian > >> Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: >> zope.browser?] > > [...] > A deprecation warning isn't bad. But I think we should not >> deprecate the use of ITerms from zope.app.form. I don't see a gain >> in this API change. >>> Imo it's a bad idea to keep exactly the same interface in 2 >> places. At >>> least i don't see an improvement or convenience in keeping it. >>> >>> the only real reason to keep it is for legacy reasons, but import >>> adoption should not be that hard ;) >> >> No it is not. I just question why we force everybody to use >> the new location when we did not do so with ISite. It is >> exactly the same issue with two different outcomes. >> >> The canonical location for ISite is zope.location now. It >> used to reside in zope.app.component but was moved to >> zope.location w/o deprecating the use from zope.app.location >> to keep the API backward compatible. I really do not see a >> differrence to ITerms here. > > This doesn't have to do with bachward compatibility. Deprecated > imports are backward compatible too. I think someone just missed > to deprecate that interface. Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html > > > The reason why we should deprecate interfaces is: If a package > still points to the old interface location, this package whould > bring in the old dependency we tried to remove. Depends. See below. > > I guess, since you are asking for support the old location, > this doesn't hurt you because you are using both packages. > Others don't. Any other packages which doesn't adjust the > import to the new location will hurt others which do not use > both packages. If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places. > > I see that this makes it more a good thing for others then > for yourself. But I think that's fine. Isn't it? > > In my point of view, deprecation messages are a great concept > to announce changes/improvments without to break compatibility. > Without such announcements our code can get very quick out > of date and we have no change to know about that. Yes, for necessary API changes which do not need to be shipped immeadiately I can see that. > > btw, > we also should deprecate the ISite interface at the old location. Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings. -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
Hi Christian > Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: > zope.browser?] [...] > >> A deprecation warning isn't bad. But I think we should not > deprecate > >> the use of ITerms from zope.app.form. I don't see a gain > in this API > >> change. > > Imo it's a bad idea to keep exactly the same interface in 2 > places. At > > least i don't see an improvement or convenience in keeping it. > > > > the only real reason to keep it is for legacy reasons, but import > > adoption should not be that hard ;) > > No it is not. I just question why we force everybody to use > the new location when we did not do so with ISite. It is > exactly the same issue with two different outcomes. > > The canonical location for ISite is zope.location now. It > used to reside in zope.app.component but was moved to > zope.location w/o deprecating the use from zope.app.location > to keep the API backward compatible. I really do not see a > differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. btw, we also should deprecate the ISite interface at the old location. Regards Roger Ineichen ___ 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 Sun Dec 14 12:00:00 2008 UTC to Mon Dec 15 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: Sun Dec 14 20:33:54 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010655.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sun Dec 14 20:35:24 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010656.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sun Dec 14 20:27:53 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010651.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:29:23 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010652.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:30:54 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010653.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:32:24 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010654.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 )
[Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On 2008-12-12 16:04:09 +0100, Robert Niederreiter said: > Hi, > > Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick: >> On 2008-12-12 14:24:09 +0100, Martijn Faassen said: >> >>> Hey, >>> >>> Christian Zagrodnick wrote: >>> [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. >>> >>> Why is such a deprecation warning bad? Wouldn't this encourage people to >>> update their code? >> >> >> A deprecation warning isn't bad. But I think we should not deprecate >> the use of ITerms from zope.app.form. I don't see a gain in this API >> change. > Imo it's a bad idea to keep exactly the same interface in 2 places. At > least i don't see an improvement or convenience in keeping it. > > the only real reason to keep it is for legacy reasons, but import > adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
