Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Martijn Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] Hey there, Roger Ineichen wrote: [snip] I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode? I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB. I don't like the use of devmode for that, especially as I hardly ever use devmode for anything (Grok doesn't really do much with it as far as I know). I prefer a tool that's external to the source code in question. You could base it off something like that importchecker (see pypi) does. It'd analyze what imports take place and whether it's importing from a place that marks itself as deprecated. Your mention of the ZODB issue brings up a good point. We'd also need a ZODB-level tool that can do this reporting in this case. The current deprecation system already covers this case, though, right? Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. The benefit is also that it'd be thorough and find all instances, not just those that happen to be in use by a particular application. I'm fine with any implementation. I just don't like to loose this (for me) important feature. Note; I think nobody is able to develop an application which does the cleanup right if objects get removed. At least I don't know any application where all objects get correct removed and I know different apps developed from different companies. Also my own apps don't do the cleanup correct right now. Or does someone remove items (e.g. dublin core) from the annotations for removed objects or the annotation container itself etc. etc? There is also an issue with interface references in the adapter registry. Interfaces (pickle) do not get removed. This means we really need deprecation warnings in running applications. Probably a good start whould be a script which allows to access every object in the ZODB by iter all objects and see if something raises a deprecation warning. Regards Roger Ineichen Regards, Martijn ___ 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 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?]
Martijn Faassen wrote: Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. Thrawl = thrashing crawl? Never heard that word before, but it's apt. 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Shane Hathaway wrote: Martijn Faassen wrote: Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. Thrawl = thrashing crawl? Never heard that word before, but it's apt. Unfortunately just a misspelling of 'trawl', which according to the jargon file means: trawl v. To sift through large volumes of data (e.g., Usenet postings, FTP archives, or the Jargon File) looking for something of interest. Regards, Martijn ___ 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?]
Hey there, Roger Ineichen wrote: [snip] I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode? I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB. I don't like the use of devmode for that, especially as I hardly ever use devmode for anything (Grok doesn't really do much with it as far as I know). I prefer a tool that's external to the source code in question. You could base it off something like that importchecker (see pypi) does. It'd analyze what imports take place and whether it's importing from a place that marks itself as deprecated. Your mention of the ZODB issue brings up a good point. We'd also need a ZODB-level tool that can do this reporting in this case. The current deprecation system already covers this case, though, right? Besides an import checker you'd need a system that would be able to thrawl through a ZODB and report deprecated classes. The drawback is that it'd need to thrawl through a ZODB, so that's rather costly. The benefit is also that it'd be thorough and find all instances, not just those that happen to be in use by a particular application. Regards, Martijn ___ 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-22 18:48:47 +0100, Martijn Faassen faas...@startifact.com said: Hi there, All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them. I think we need to think of some way to signal that the preferred import location of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely. Right. May I remove the deprecation warning then? I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the right public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end. A correctly crafted BBB together with some simple grep-like tool would be sufficient, would it not? -- 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: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] On 2008-12-22 18:48:47 +0100, Martijn Faassen faas...@startifact.com said: Hi there, All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them. I think we need to think of some way to signal that the preferred import location of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely. Right. May I remove the deprecation warning then? Yes, but only after someone implemented another concept for notify about old import location ;-) I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the right public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end. A correctly crafted BBB together with some simple grep-like tool would be sufficient, would it not? What is grep ;-) I don't like that. Probably we should use the existing devmode or something like that? Devmode whould allow us to use it at runtime and during testing. What about a deprecation mode? I really like to use such deprecation messages in production too. I think it's a must that we can use them on productive servers and see what happens with things stored the ZODB. Regrads 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?]
Hi there, All right, I was getting a bit confused when it appeared you were arguing against moving things at all, but you're basically in favor of leaving the old APIs intact without explicitly breaking them. I think we need to think of some way to signal that the preferred import location of something has changed that doesn't result in deprecation warnings. It's clear from this discussion that this should be done upon request, not during runtime. The old import location can then stay around indefinitely. I'd like a tool that I can point at a package and it'll sort through whatever it imports and tell me which ones are not importing from the right public location. Each package should have some way to indicate to that tool whether certain imports are better made from somewhere else if one is in the business of reducing dependencies. Perhaps a # BBB comment is enough, though what it looks like exactly depends a bit on how the tool will work in the end. Regards, Martijn ___ 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 there, Tres, please tell me what I should be doing as opposed to moving things around and deprecating them. I want a version of Grok with far less dependencies than it pulls in now. I believe there are a lot of advantages in doing that, and I'm not going to go into them here as I'm sure you can imagine them yourself. There are two ways I can go about that: a) break everybody's APIs and rewrite parts of Zope 3 itself so we have less dependencies for Grok. b) refactor Zope 3 itself so that there are less spurious dependencies that get pulled in. You're complaining that b) is going to cause people trouble as they see deprecation warnings. Fine, we can evolve towards a system to do deprecation warnings better. But you also seem to be suggesting we shouldn't even do b) in the first place. a) is a much greater break with the past than b), however. What is the alternative that I'm missing? Or are you suggesting we break everybody's code and go for a)? Why then arguing a smaller refactoring that tries hard to keep things working? (I expect the Grok project will involve a combination of a) and b) in the end, but hopefully as little a) as possible). It's not a theoretical cleanliness we're talking about here. zope.app.form is *not* a dependency of z3c.form anymore, and I consider this a win for z3c.form. Less code installed, and people who wade through the code won't run into the very misleading zope.app.form anymore. I've also noticed a similar win with z3c.saconfig. I forget the details, but I was very careful not to pull in a certain dependency as that pulled in all of Zope 3, and I wanted to keep dependencies under control. Then someone added a feature that needed that dependency. Then it turned out that in the mean time a new version of the dependency had been released that *didn't* pull all of Zope 3. That made me happy, as it strikes to me that a lot of small improvements like that may significantly reduce the set of dependencies many Zope 3 installations require. Regards, Martijn ___ 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?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, Tres, please tell me what I should be doing as opposed to moving things around and deprecating them. I want a version of Grok with far less dependencies than it pulls in now. I believe there are a lot of advantages in doing that, and I'm not going to go into them here as I'm sure you can imagine them yourself. There are two ways I can go about that: a) break everybody's APIs and rewrite parts of Zope 3 itself so we have less dependencies for Grok. b) refactor Zope 3 itself so that there are less spurious dependencies that get pulled in. You're complaining that b) is going to cause people trouble as they see deprecation warnings. Fine, we can evolve towards a system to do deprecation warnings better. But you also seem to be suggesting we shouldn't even do b) in the first place. Doing b) is fine. What I am objecting to is the part where we (plan to) break imports of symbols from their old locations, instead of just leaving them importable from that place *forever*. Note that we would *not* be adding deprecation warnings in the old location if the code there (where the symbols used to live) actually used the now-refactored-to-another module symbols. a) is a much greater break with the past than b), however. What is the alternative that I'm missing? Or are you suggesting we break everybody's code and go for a)? Why then arguing a smaller refactoring that tries hard to keep things working? (I expect the Grok project will involve a combination of a) and b) in the end, but hopefully as little a) as possible). It's not a theoretical cleanliness we're talking about here. zope.app.form is *not* a dependency of z3c.form anymore, and I consider this a win for z3c.form. Less code installed, and people who wade through the code won't run into the very misleading zope.app.form anymore. I consider that a win, too. What I'm objecting to is the idea that we release a new version of *zope.app.form* which breaks imports of the symbols which used to live there. Instead, I'm arguing that we leave the BBB imports of that symbol in the old location, forever. Note that the new zope.app.form depends already on the new location of those symbols, so we aren't adding any cruft beyond a single line per symbol, along the lines of the following (I think it would be in zope.app.form.interfaces):: from zope.browser.interfaces import ITerm # BBB I've also noticed a similar win with z3c.saconfig. I forget the details, but I was very careful not to pull in a certain dependency as that pulled in all of Zope 3, and I wanted to keep dependencies under control. Then someone added a feature that needed that dependency. Then it turned out that in the mean time a new version of the dependency had been released that *didn't* pull all of Zope 3. That made me happy, as it strikes to me that a lot of small improvements like that may significantly reduce the set of dependencies many Zope 3 installations require. I'm in favor of reducing dependencies, and actively in favor of the refactoring which breaks apart the dependable bits (e.g., into the new zope.browser package) from the others. I just don't want to emit deprecation warnings now, or ImportErrors later, for imports from the old location. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJTyER+gerLs4ltQ4RAlmIAJ9SXtb8G00l9SXrxhpLFTFPEg1bOwCeLuVj +Xl2O6vkZsrLMEt4ScFgwOI= =wo9Y -END PGP 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] If we that there is a real goal other than future cleanliness for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer. I think it's more then future cleanliness. My goal is to reuse as much as we can. This means, if we deprecate zope.app.form.browser.interface.ITerms. And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects. If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts. I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base. And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do. Reegards 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?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] If we that there is a real goal other than future cleanliness for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer. I think it's more then future cleanliness. My goal is to reuse as much as we can. This means, if we deprecate zope.app.form.browser.interface.ITerms. And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects. If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts. I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base. And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do. You lose the reusability of any existing packages which supply the old interface / location once you finally remove the interface from the deprecated location. Unless their maintainers issue new versions of their packages (as Fred did in my example, to keep from sleeping outside with Dino in ;), your code will not be able to use both the new version of the framework *and* the old plugin at the same time. Refactor mercilessly is a mantra of a methodology which is specifically focused on building applications, rather tha libraries / frameworks. Once you have downstream users who are not actively involved in the development of your package, the costs of refactoring go up. As an example from outside Zope land: Linux developers fiercely defend their practice that there is no stable ABI in the kernel; out-of-tree modules have to be recompiled to be compatible with new kernel versions, including refactorings, etc. However, they are equally fierce in the policy that a user-space API, once released, is maintained *forever*. User-space code which uses such an API *must* continue to work. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJTYlG+gerLs4ltQ4RAqd7AKCpf4om3G6gpx0ilfiw1/83JgoxUgCgjBBP GBHZ4dF3Ts2UmVWKEZD5+IE= =RCah -END PGP 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] One issue is that adding deprecation messages for importing symbols from the old makes all downstream code add ugly BBB warts in order to suppress them when run against multiple versions. Yes, that's exactly what deprecation message do. Deprecation messages in tests do not have to win a beauty award. The goal of a deprecation message is to inform developers about upcomming changes. This ugly BBB output is very important to me! This allows us to schedule our work and we don't run into removed backward compatibility issues. This makes deprecation messages something like a reminder and nothing which we should ignore. If we don't use deprecation messages we can not do future cleanup because we can't remove old not deprecated code. This means using deprecation message or not depends on the need for a future cleanup. If we like to support an old interface location then we don't need deprecation messages. But if we like to remove the interface at the old location in the future then we need to deprecate them. This has nothing to do with beautify our test output. I think you missed my point: third-party developers who want their code *not* to emit the deprecation warnings when used across both old and new versions of our library have to add nasty BBB cruft to *their* code: we've shifted the BBB burden to them, often for a small marginal benefit to ourselves. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJSUMo+gerLs4ltQ4RAuncAKCS9HL5XlvjHQoI1Y/6IwVJ2+c7iACfSFcj wyqDo/8Qgd1Om79oyLjy7yA= =kenJ -END PGP 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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Tres Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] [...] One issue is that adding deprecation messages for importing symbols from the old makes all downstream code add ugly BBB warts in order to suppress them when run against multiple versions. Yes, that's exactly what deprecation message do. Deprecation messages in tests do not have to win a beauty award. The goal of a deprecation message is to inform developers about upcomming changes. This ugly BBB output is very important to me! This allows us to schedule our work and we don't run into removed backward compatibility issues. This makes deprecation messages something like a reminder and nothing which we should ignore. If we don't use deprecation messages we can not do future cleanup because we can't remove old not deprecated code. This means using deprecation message or not depends on the need for a future cleanup. If we like to support an old interface location then we don't need deprecation messages. But if we like to remove the interface at the old location in the future then we need to deprecate them. This has nothing to do with beautify our test output. 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?]
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 d...@projekt01.ch 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 )
