Mailing List Archive

Florent Guillaume wrote:
> In article <20041006140019.GC4591@cotia.awkly.org> you write:
>
>>I've made some changes on the way ZPublisher deals with
>>__bobo_traverse__.
>>
>>Here's the branch:
>>svn+ssh://svn.zope.org/repos/main/Zope/branches/dc-bobo_traverse-branch
>>
>
> [...]
>
>>This change would simplify the implementations of __bobo_traverse__,
>>which would not have to worry about looking at __getattr__ and
>>__getitem__ themselves, but I would like to know what people think
>>first.
>>
>>The changes would be applied to 2_7-branch and trunk.
>
>
> I'm all for these cleanups, or a variation on them, but I'm strongly -1
> on them being included in the 2.7 branch. 2.7 is getting very stable
> now, and I don't want any kind of incompatibility problems added.

Agreed. -1 for mucking with 2.7, even though I realize that it means 500
response codes will continue to propagate from Five running on 2.7.3+

Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com

_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

--On Donnerstag, 7. Oktober 2004 10:26 Uhr -0400 Tres Seaver
<tseaver@zope.com> wrote:

>>
>> I'm all for these cleanups, or a variation on them, but I'm strongly -1
>> on them being included in the 2.7 branch. 2.7 is getting very stable
>> now, and I don't want any kind of incompatibility problems added.
>
> Agreed. -1 for mucking with 2.7, even though I realize that it means 500
> response codes will continue to propagate from Five running on 2.7.3+
>

The changes are fine for 2.8, but not for 2.7 since there is a risk that
applications
might break and we really don't want introduce new behaviour in the current
state.

Andreas
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Thu, Oct 07, 2004 at 05:51:05PM +0200, Andreas Jung wrote:
| >>I'm all for these cleanups, or a variation on them, but I'm strongly -1
| >>on them being included in the 2.7 branch. 2.7 is getting very stable
| >>now, and I don't want any kind of incompatibility problems added.
| >
| >Agreed. -1 for mucking with 2.7, even though I realize that it means 500
| >response codes will continue to propagate from Five running on 2.7.3+
| >
|
| The changes are fine for 2.8, but not for 2.7 since there is a risk that
| applications
| might break and we really don't want introduce new behaviour in the current
| state.

It's not like something will break. I highly doubt that something is
depending on ZPublisher returning a 500 status code for not found
pages.

--
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

1: No code table for op: ++post
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

| The publisher's job has always been to mediate between what the protocl
| (HTTP) expects, and what the application delivers. In this case, the
| difference is between having the HTTP response code be 404, or having it
| be 500. Making either choice is DWIM ("do what I mean"); it happens to
| be consistent with the other publisher code (immediately following the
| test for __bobo_traverse__) to treat it as a 404 instead of a 500.
|
| In debug mode, we should prefer a 500, because it preserves the original
| exception information; this is the current behavior for errors raised
| from getattr / getitem, and would be the behavior under Sidnei's
| proposed change.

That's correct.

The thread seems to have died here, and I don't think we came to a
consensus if it should be merged to 2.7 and trunk or just trunk.

IMHO, the change has minimal impact, as no-one sane would be depending
on an AttributeError/KeywordError raised inside __bobo_traverse__ when
called from ZPublisher to result in a 500 error code instead of 404
(which is what it boils down to after all). As Tres mentioned, in
debug mode it will have the same behavior as getattr/getitem so that
should be enough for pleasing developers.

--
Sidnei da Silva <sidnei@awkly.org>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

<sjj> dash: you certainly are an enigma wrapped in a riddle wrapped in a hat.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

--On Mittwoch, 13. Oktober 2004 10:33 Uhr -0300 Sidnei da Silva
<sidnei@awkly.org> wrote:

>| The publisher's job has always been to mediate between what the protocl
>| (HTTP) expects, and what the application delivers. In this case, the
>| difference is between having the HTTP response code be 404, or having it
>| be 500. Making either choice is DWIM ("do what I mean"); it happens to
>| be consistent with the other publisher code (immediately following the
>| test for __bobo_traverse__) to treat it as a 404 instead of a 500.
>|
>| In debug mode, we should prefer a 500, because it preserves the original
>| exception information; this is the current behavior for errors raised
>| from getattr / getitem, and would be the behavior under Sidnei's
>| proposed change.
>
> That's correct.
>
> The thread seems to have died here, and I don't think we came to a
> consensus if it should be merged to 2.7 and trunk or just trunk.

Please include your patch on the SVN trunk but not on the 2.7 branch.
I don't see the benefits for having the changes on the 2.7 branch
especially
not for the upcoming 2.7.3 final release.

Andreas
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Andreas Jung wrote:
>
>
> --On Mittwoch, 13. Oktober 2004 10:33 Uhr -0300 Sidnei da Silva
> <sidnei@awkly.org> wrote:
>
>> | The publisher's job has always been to mediate between what the protocl
>> | (HTTP) expects, and what the application delivers. In this case, the
>> | difference is between having the HTTP response code be 404, or
>> having it
>> | be 500. Making either choice is DWIM ("do what I mean"); it
>> happens to
>> | be consistent with the other publisher code (immediately following the
>> | test for __bobo_traverse__) to treat it as a 404 instead of a 500.
>> |
>> | In debug mode, we should prefer a 500, because it preserves the
>> original
>> | exception information; this is the current behavior for errors raised
>> | from getattr / getitem, and would be the behavior under Sidnei's
>> | proposed change.
>>
>> That's correct.
>>
>> The thread seems to have died here, and I don't think we came to a
>> consensus if it should be merged to 2.7 and trunk or just trunk.
>
>
> Please include your patch on the SVN trunk but not on the 2.7 branch.
> I don't see the benefits for having the changes on the 2.7 branch
> especially
> not for the upcoming 2.7.3 final release.

Sidnei came up with the patch while trying to implement correct
traversal for Five, which is intended to work with the currently
released 2.7.x.

I *don't* think this is a feature; I think it is a bugfix. However,
Andreas is the release manager, and if he thinks it is too risky for
2.7.3, then we need to respect that. In that case, I *do* think it
should land the moment 2.7.3 is tagged.

Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

--On Mittwoch, 13. Oktober 2004 9:56 Uhr -0400 Tres Seaver
<tseaver@zope.com> wrote:
>
> Sidnei came up with the patch while trying to implement correct traversal
> for Five, which is intended to work with the currently released 2.7.x.
>
> I *don't* think this is a feature; I think it is a bugfix. However,
> Andreas is the release manager, and if he thinks it is too risky for
> 2.7.3, then we need to respect that. In that case, I *do* think it
> should land the moment 2.7.3 is tagged.
>

Pre-2.7.3 would be fine with me. I don't like to make another beta release.
The current
2.7 branch looks fine for a RC or even a final version.

Andreas
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders