Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py Officially deprecate the BBB methods on the iterator and add a note
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Log message for revision 68231: Officially deprecate the BBB methods on the iterator and add a note regarding our plans for the other iterator BBB code
Changed: U Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py
-=- Modified: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py =================================================================== --- Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py 2006-05-22 01:08:55 UTC (rev 68230) +++ Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/Expressions.py 2006-05-22 01:17:43 UTC (rev 68231) @@ -35,6 +35,7 @@
# BBB 2005/05/01 -- remove after 12 months import zope.deprecation +from zope.deprecation import deprecate zope.deprecation.deprecated( ("StringExpr", "NotExpr", "PathExpr", "SubPathExpr"), "Zope 2 uses the Zope 3 ZPT engine now. Expression types can be " @@ -98,7 +99,12 @@
__allow_access_to_unprotected_subobjects__ = True
- # these used to be properties in ZTUtils.Iterator.Iterator + # The things below used to be attributes in + # ZTUtils.Iterator.Iterator, however in zope.tales.tales.Iterator + # they're methods. We need BBB on the Python level so we redefine + # them as properties here. Eventually, we would like to get rid + # of them, though, so that we won't have to maintain yet another + # iterator class somewhere.
@property def index(self): @@ -116,18 +122,27 @@ def item(self): return super(ZopeIterator, self).item()
- # these aren't in zope.tales.tales.Iterator, but were in - # ZTUtils.Iterator.Iterator + # The following things were in ZTUtils.Iterator.Iterator but + # aren't anymore in zope.tales.tales.Iterator. For a good reason. + # They're just insane.
+ # BBB 2005/05/01 -- to be removed after 12 months + @property + @deprecate("The 'nextIndex' method has been deprecated and will disappear " + "in Zope 2.12. Use 'iterator.index+1' instead.") def nextIndex(self): return self.index + 1
+ @deprecate("The 'first' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'start' property instead.") def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item)
+ @deprecate("The 'last' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'end' property instead.") def last(self, name=None): if self.end: return True
I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html):
+ Note that 'first' and 'last' are intended for use with sorted + sequences. They try to divide the sequence into group of items + with the same value. If you provide a path, then the value + obtained by following that path from a sequence item is used for + grouping, otherwise the value of the item is used. You can + provide the path by passing it as a parameter, as in + "python:repeat['item'].first('color')", or by appending it to the + path from the repeat variable, as in "repeat/item/first/color". +
I'm pretty sure that such changes ought to be proposed on the 'zpt' list, as they are germane outside Zope's own ZPT implementation. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEcS80+gerLs4ltQ4RAgMJAKCApnKFQfGOsPmvXDwu52S0cPqnmACeLK6i gkrqn4HkVCFaEG+5QCIgTzE= =OSnn -----END PGP SIGNATURE-----
Tres Seaver wrote:
+ @deprecate("The 'last' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'end' property instead.") def last(self, name=None): if self.end: return True
I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html):
Yeah, what Tres said ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Tres Seaver wrote:
+ @deprecate("The 'first' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'start' property instead.") def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item)
+ @deprecate("The 'last' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'end' property instead.") def last(self, name=None): if self.end: return True
I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html):
This sounds sensible. Thanks for the pointer. I'll undeprecate them :). Philipp
Philipp von Weitershausen wrote:
Tres Seaver wrote:
+ @deprecate("The 'first' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'start' property instead.") def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item)
+ @deprecate("The 'last' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'end' property instead.") def last(self, name=None): if self.end: return True
I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html):
This sounds sensible. Thanks for the pointer. I'll undeprecate them :).
I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them. Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
Tres Seaver wrote:
+ @deprecate("The 'first' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'start' property instead.") def first(self, name=None): if self.start: return True return not self.same_part(name, self._last, self.item)
+ @deprecate("The 'last' method has been deprecated and will disappear " + "in Zope 2.12. Use the 'end' property instead.") def last(self, name=None): if self.end: return True
I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html):
This sounds sensible. Thanks for the pointer. I'll undeprecate them :).
I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them.
This is a case for *expanding* what Z3 has: it isn't "right by default", you know, especially when it comes to pieces of Z2 technology which it has forked. For instance, I know of several DTML fixes done since Z3 forked off zope.documenttemplate: they should be "forward-ported", but may languish due to lack of care. ZPT is different: is has been in heavy production use, with *lots* more attention to "real world" use cases than the Z3 version would have gotten until only recently. Let's use some caution about harmonizing the two. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEchHL+gerLs4ltQ4RAif7AKCM7ge713kNc+uW2xECLewHDGk45QCeKNOw tpC42LYQMBinUalgw+gGxzI= =Q8H2 -----END PGP SIGNATURE----- -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
Tres Seaver wrote:
> + @deprecate("The 'first' method has been deprecated and will disappear " > + "in Zope 2.12. Use the 'start' property instead.") > def first(self, name=None): > if self.start: > return True > return not self.same_part(name, self._last, self.item) > > + @deprecate("The 'last' method has been deprecated and will disappear " > + "in Zope 2.12. Use the 'end' property instead.") > def last(self, name=None): > if self.end: > return True > I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html): This sounds sensible. Thanks for the pointer. I'll undeprecate them :).
I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them.
This is a case for *expanding* what Z3 has:
and expanding the spec...
it isn't "right by default", you know, especially when it comes to pieces of Z2 technology which it has forked.
Oh, I know. That's why I was actually going back to the spec since that's what counts at the end of day.
For instance, I know of several DTML fixes done since Z3 forked off zope.documenttemplate: they should be "forward-ported", but may languish due to lack of care.
You're comparing apples and oranges. DTML was maintained in Zope 2 and never really needed in Zope 3. ZPT on the other hand was mostly maintained in Zope 3. Plus, the goal is to use the Zope 3 implementation everywhere so there must be some advantages in the Zope 3 implementation over the Zope 2 one... otherwise we wouldn't be doing this...
ZPT is different: is has been in heavy production use, with *lots* more attention to "real world" use cases than the Z3 version would have gotten until only recently. Let's use some caution about harmonizing the two.
Sure. That's why I'm discussing these things here... Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
Tres Seaver wrote:
>>+ @deprecate("The 'first' method has been deprecated and will disappear " >>+ "in Zope 2.12. Use the 'start' property instead.") >> def first(self, name=None): >> if self.start: >> return True >> return not self.same_part(name, self._last, self.item) >> >>+ @deprecate("The 'last' method has been deprecated and will disappear " >>+ "in Zope 2.12. Use the 'end' property instead.") >> def last(self, name=None): >> if self.end: >> return True >>
I don't think deprecating 'first' and 'last' is appropriate here: they *aren't* synonyms for 'start' and 'end; they are used to implement sort-break processing. Here is the comment from the checkin which initially documented them (http://mail.zope.org/pipermail/zpt/2001-December/002598.html):
This sounds sensible. Thanks for the pointer. I'll undeprecate them :).
I'll add nonetheless that neither 'first' nor 'last' nor 'nextIndex' are required by the ZPT spec (http://www.zope.org/Wikis/DevSite/Projects/ZPT/RepeatVariable). Hence, Zope 3 just doesn't have them. I can still see a use case for 'first' and 'last' which is why I'll do my best to continue to support them.
This is a case for *expanding* what Z3 has:
and expanding the spec...
it isn't "right by default", you know, especially when it comes to pieces of Z2 technology which it has forked.
Oh, I know. That's why I was actually going back to the spec since that's what counts at the end of day.
For instance, I know of several DTML fixes done since Z3 forked off zope.documenttemplate: they should be "forward-ported", but may languish due to lack of care.
You're comparing apples and oranges. DTML was maintained in Zope 2 and never really needed in Zope 3. ZPT on the other hand was mostly maintained in Zope 3.
Not really. It was forked, but had very little "maintenance" on either side, actually. The Z3 version is *known* to be missing a few features of the Z2 version.
Plus, the goal is to use the Zope 3 implementation everywhere so there must be some advantages in the Zope 3 implementation over the Zope 2 one... otherwise we wouldn't be doing this...
We want *one* implementation, preferably with all the advantages / features needed by both forks.
ZPT is different: is has been in heavy production use, with *lots* more attention to "real world" use cases than the Z3 version would have gotten until only recently. Let's use some caution about harmonizing the two.
Sure. That's why I'm discussing these things here...
Yup, agreed. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEciDG+gerLs4ltQ4RAq7cAKDD1A9Gs5OgP8YiI9W9Ny/W2tksKwCgvIKp LYflg/ttuoojtOZ1GSWxBjw= =hfEH -----END PGP SIGNATURE-----
Philipp von Weitershausen wrote:
maintained in Zope 3. Plus, the goal is to use the Zope 3 implementation everywhere so there must be some advantages in the Zope 3 implementation over the Zope 2 one... otherwise we wouldn't be doing this...
This logic is faulty. The merge is desirable because it stops problems like the one in question here occurring in the first place ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (3)
-
Chris Withers -
Philipp von Weitershausen -
Tres Seaver