On 4/21/06, Andreas Jung <[EMAIL PROTECTED]> wrote: > > > --On 21. April 2006 07:09:45 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote: > > In general, I think that new features in bug-fix releases are a bad idea. > > Of course, the line between bug-fix and feature is not always crisp. > > Something that is really a new feature should wait for a feature release. > > > > Sure, in this particular case the issue is bug for Alec and Philipp, others > consider it a feature :-) A behavior introduced because by some > implementation bug is likely to be considered as a bug (this justifies the > change in Five 1.3.3)....
Perhaps it's just my perspective here, but I think it's a stretch to describe the fix I've committed as a "feature". Before the fix, when a __bobo_traverse__ method returned an object obtained via acquisition it was treated very differently than an object returned by normal traversal, and when that object had an acquisition wrapper everything works (there is very explicit code and tests that ensure this), however if the object returned has no Acquisition wrapper (because it is a method, string, etc) then a very cryptic Unauthorized error is raised ("Container None has no security assertions"). It's hard for me to see this as anything but a bug, and the fact that it causes serious problems for anyone who wants to use attribute acquisition with Five makes it a rather serious one. Dieter's proposed fix introduces feature (which I think is the source of this bug/feature confusion). Though as he says, it is one which has close to no consequences because it has no effect until product developers (Five included) take advantage of it by raising a new exception from their __bobo_traverse__ methods. Even in that case, the implementation of the feature should be somewhat tirvial and unlikely to be error prone. Nonetheless, the two proposals serve somewhat different purpooses, though Dieter's new feature could easily be used to allow products to circumvent the above bug and simplify existing product code. 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 )