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.

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to