Re: [Zope-dev] zope.test.doctest made into monkey-patches
* Jim Fulton [2010-04-20 20:35]: > On Tue, Apr 20, 2010 at 4:46 AM, Lennart Regebro wrote: >> And here is another interesting experiment: >> svn+ssh://rege...@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching >> It replaces the custom doctest.py with monkey-patches. >> >> Benefits: We don't have to maintain a separate doctest.py, and we get >> the bugfixes from Python. > > Strong -1. > > Monkey patching should be used as a last resort. Monkey > patching the standard library is likely to make us look like > jack asses. That might be so. I don't share that position, but I have a different point that I want to make: Regardless of whether monkey-patching the stdlib is or isn't a Bad Thing(tm), I think Lennart's approach is an *improvement* over the previous situation where we copied a file from the stdlib wholesale[1] -- in my opinion that's definitely worse than a monkey-patch. Wolfgang [1] I know, I know, it was actually the other way around. But still. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testrunner (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 18:11, Christian Theune wrote: > The intention is to make a few successive runs have the same ordering. I > wouldn't complain if a switch to a different test runner version changed > ordering for a seed as long as the order then remains stable. Right, that's what I thought. And I think it actually will not change the ordering, I think it only did that for the testrunners own tests, as a result of the reorganization, but I'm not *sure*. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 20:35, Jim Fulton wrote: > Monkey patching should be used as a last resort. Monkey > patching the standard library is likely to make us look like > jack asses. Possibly. But having a doctest module with loads of bugs that doesn't even behave exactly the same maybe doesn't make us look like jackasses, but it sure as heck is a big pain, and makes zope.testing practically impossible to port to Python 3 in a sensible way. The monkey-patching makes it possible to remove the doctest module without all of zopes.* tests failing. The Deprecation warning of course should remain. It can be noted that my previous Python 3 porting efforts have simply deleted the doctest module. I believe these are the two options we have if we want ZTK to be ported to Python 3. So it's really a choice: Delete it and monkey patch, or delete it and break everything, or not supporting Python 3. > We should switch to manuel, which already has the footnote feature. Oh, I'm *not* monkey-patching in the footnote feature. :) People using that feature will have to stay with an earlier zope.testing or switch to Manuel. > Let zope.testing.doctest wither and die It hasn't been merged from python trunk since 2004, and the amount of bugfixes on that Python trunk since then is astounding. So I'd argue that is *is* withered. The monkey-patching kills it. :) Interestingly, there are two bugs fixed on zopes doctest that hasn't been fixed in the standard library. I've reported them: http://bugs.python.org/issue8471 http://bugs.python.org/issue8473 So that's two of the patches. The remaining two patches are: 1. zope doctests get the TestCases surrounding environment, while stdlib doctests you need to explicitly pass in extra environment. That patch is there for compatibility, some tests won't work otherwise. 2. stdlibs unittest will ignore all reporting flags given to the testrunner if any reporting flag is given to the test, most significantly also the -1 flag. I think that's daft, so I took it up on python-dev. Lastly doctest.DocTestCase.failureException is set to zope.testing.exceptions.DocTestFailureException, but that's not even a monkey-patch, that's how you are supposed to do it, so that's a part of the testrunner, really, and probably that "patching" should be done by the testrunner before it runs the tests instead, should be a simple fix. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
Hi Christian, On 21 April 2010 02:58, Christian Theune wrote: > On 04/20/2010 08:44 PM, Jim Fulton wrote: >> >> On Tue, Apr 20, 2010 at 12:09 PM, Christian Theune wrote: >>> >>> Minor note: zope.testing *promotes* layers the wrong way and >>> zope.app.testing definitely implements them the wrong way. >> >> That's prety vague. Could you say specifically in what ways >> zope.testing promotes layers the wrong way and > > zope.testing uses the attribute '__bases__' to store the information what > the base layers are. __*__ are supposedly Python internal attributes. > Specifically __bases__ is known to be used to store information which base > classes a class has. > > Looking at this I (and others too) get directed towards: aha, so layers are > classes and use inheritance to signal what base layers are. Which is exactly > not what is happening. In fact, it's a little worse than that. Consider this pair of layers: class Base: @classmethod def setUp(cls): print "Setting up base" @classmethod def tearDown(cls): print "Tearing down base" class Child(Base): @classmethod def setUp(cls): print "Setting up child" Note that there's no tearDown on the child (perhaps it doesn't need one). What actually happens in this case is that the test runner still finds a tearDown on Child, it's just that it's inherited from Base. So in effect, Base's tearDown is called twice. This also happens with things like testSetUp() and testTearDown(). If the base defines them and a child doesn't, they're called twice. The other problem is that it's hard to also use inheritance in the OOP sense to re-use layer logic. Also, if the layer manages any state, it has to be set as a class variable (on cls), which is effectively global. If you want to re-use a layer but isolate the resources its creates from those created by existing layers, you have to re-implement the layer. These insights by Ross Patterson led to collective.testcaselayer, which was lightly refactored into the layer module of the nascent plone.testing. See: http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.py http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.txt http://svn.plone.org/svn/plone/plone.testing/trunk/README.txt This module also contains an implementation of a resource manager that allows layers to define shared resources in a stack that lets child layers shadow those resources (i.e. provide a changed fixture). We use this for things like ZODB connections and Zope 2 app roots. It's explained best in the README, and tested in layer.txt. Having used this pattern for a while, I'm pretty sure it's an improvement on the layers-are-classes thing, which in addition to the problems above, has caused a fair amount of confusion. > > zope.app.testing uses them the wrong way? > > Actually it doesn't. I confused this with Zope 2's Testing: > > There's Testing/ZopeTestCase/layer.py which defines a class with > classmethods and in a similar fashion there is Products.PloneTestCase that > defines classes, derives them and thus kind of piggybacks on the class > inheritance mechanism to establish __bases__ paired with static methods but > without actually inheriting methods. FTR, the ZopeTestCase mess is basically what plone.testing.z2 tries to fix (insofar as it's possible). The PloneTestCase mess will hopefully be fixed by a plone.app.testing building on plone.testing. > We struggled through some hairy details that I fail to remember when we > worked on gocept.selenium last year which tries to establish a generic layer > that can be combined with others. You're not the only one. ;-) Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Validating invariants with zope.schema.getValidationErrors and zope.schema.Object
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey Popp wrote: > Ok, I've created bug report: > https://bugs.launchpad.net/zope.schema/+bug/567520 Thank you! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvOK8YACgkQ+gerLs4ltQ4oQQCfShBdLt4vCoHIisKyT+OmnXRH 7psAoLMu+yHBfULPdgiK3fDA3k4R7AR5 =BfKL -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On 04/20/2010 10:48 PM, Jim Fulton wrote: On Tue, Apr 20, 2010 at 4:05 PM, Fred Drake wrote: ... I think the issue is with that it's not standard protocol the way we use it - at least I can't find our use of __bases__ documented in Python's documentation[1] about __bases__ and thus have a hard time saying we're following standard protocols. Our uses of __bases__ and __parent__ don't match Python, We disagree wrt __bases__. and there's a general BDFL proclamation that underware are for Python implementations (IIRC). That proclamation changed over time. It was much weaker in the past. It was strengthened with "applications should not expect to define additional names using this convention. The set of names of this class defined by Python may be extended in future versions." in Python 2.3. In fact, Guido was aware of and didn't object to my use of __*__names. While we can argue that our use is reasonable, the fact that there's reasonable dissent suggests something different would have been a better choice. The fact that there is dissent from a choice doesn't mean that it is wrong. I'm not saying that my use of __*__s was "right" in any absolute sense. I get that there are differences of opinion. > To say that zope.testing "promotes" layers the wrong way, simply because it used the name __bases__, which doesn't even go against the BDFL's pronouncement on the use of __*__s is misleading at best. Something in this discussion thread is borked. I sense tension. I sense that the argument doesn't have direction and I don't feel invited to share my thoughts. I'd like to figure out why that is because I want this to happen less often. (Right now this caused me to spend 30 minutes not writing a technical answer which makes me sad because I think in real life this issue could have been debated much more quickly and constructively.) For now I'll go to bed, maybe looking at it tomorrow will help. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Tue, Apr 20, 2010 at 4:05 PM, Fred Drake wrote: ... >> I think the issue is with that it's not standard protocol the way we use it >> - at least I can't find our use of __bases__ documented in Python's >> documentation[1] about __bases__ and thus have a hard time saying we're >> following standard protocols. > > Our uses of __bases__ and __parent__ don't match Python, We disagree wrt __bases__. > and there's a > general BDFL proclamation that underware are for Python > implementations (IIRC). That proclamation changed over time. It was much weaker in the past. It was strengthened with "applications should not expect to define additional names using this convention. The set of names of this class defined by Python may be extended in future versions." in Python 2.3. In fact, Guido was aware of and didn't object to my use of __*__names. > While we can argue that our use is > reasonable, the fact that there's reasonable dissent suggests > something different would have been a better choice. The fact that there is dissent from a choice doesn't mean that it is wrong. I'm not saying that my use of __*__s was "right" in any absolute sense. I get that there are differences of opinion. To say that zope.testing "promotes" layers the wrong way, simply because it used the name __bases__, which doesn't even go against the BDFL's pronouncement on the use of __*__s is misleading at best. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Validating invariants with zope.schema.getValidationErrors and zope.schema.Object
Ok, I've created bug report: https://bugs.launchpad.net/zope.schema/+bug/567520 On Tue, Apr 20, 2010 at 10:15 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andrey Popp wrote: > >> does anyone know why zope.schema.Object does not check invariants >> during validation process? If object conforms to schema it implies >> that object should conform all schema invariants, insn't it? > > Likely you have found a bug. please report it to the zope.schema tracker: > > https://bugs.launchpad.net/zope.schema > > > Tres. > - -- > === > Tres Seaver +1 540-429-0999 tsea...@palladion.com > Palladion Software "Excellence by Design" http://palladion.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkvN71QACgkQ+gerLs4ltQ66CgCeNuk+9zlpEGTbEqTIsfalipD6 > fGkAoKIeOzTBFRAFEL8mxSr4Iu2e2/K2 > =0/QY > -END PGP SIGNATURE- > -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Tue, Apr 20, 2010 at 4:09 PM, Christian Theune wrote: > I think the two of us agreeing, right? You & I are. I think Jim's not (which is fine, of course). -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On 04/20/2010 10:05 PM, Fred Drake wrote: On Tue, Apr 20, 2010 at 3:47 PM, Christian Theune wrote: I don't know (or at least can't remember) all of the history of the discussion about that, but I wouldn't argue about following standard protocols. It *is* arguable that __name__ is a standard protocol. It's also not clear that our using it as we do is really the same thing. (And I don't think it's interesting to discuss whether we do the right thing or not.) I think the issue is with that it's not standard protocol the way we use it - at least I can't find our use of __bases__ documented in Python's documentation[1] about __bases__ and thus have a hard time saying we're following standard protocols. Our uses of __bases__ and __parent__ don't match Python, and there's a general BDFL proclamation that underware are for Python implementations (IIRC). While we can argue that our use is reasonable, the fact that there's reasonable dissent suggests something different would have been a better choice. I think the two of us agreeing, right? -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Tue, Apr 20, 2010 at 3:47 PM, Christian Theune wrote: > I don't know (or at least can't remember) all of the history of the > discussion about that, but I wouldn't argue about following standard > protocols. It *is* arguable that __name__ is a standard protocol. It's also not clear that our using it as we do is really the same thing. (And I don't think it's interesting to discuss whether we do the right thing or not.) > I think the issue is with that it's not standard protocol the way we use it > - at least I can't find our use of __bases__ documented in Python's > documentation[1] about __bases__ and thus have a hard time saying we're > following standard protocols. Our uses of __bases__ and __parent__ don't match Python, and there's a general BDFL proclamation that underware are for Python implementations (IIRC). While we can argue that our use is reasonable, the fact that there's reasonable dissent suggests something different would have been a better choice. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On 04/20/2010 09:24 PM, Jim Fulton wrote:
On Tue, Apr 20, 2010 at 3:04 PM, Fred Drake wrote:
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune wrote:
zope.testing uses the attribute '__bases__' to store the information what
the base layers are. __*__ are supposedly Python internal attributes.
Specifically __bases__ is known to be used to store information which base
classes a class has.
This sort of misdirection has, unfortunately, a long history in Zope 3
(and the various things that's become). Witness __name__. (There are
others, but most aren't *actually* used by Python implementations.)
Removing existing __*__ name ("underware") usage is probably
untenable, but I hope we can avoid extending our foolishness.
OK, let's stop new uses of __*__ names. We won't provide initializers
for classes, or implement operations either.
The use of protocols like __name__ and __bases__ is intended to
conform to common usage in Python.
Let's invent new names that are specific to our own frameworks.
I can live with saying we shouldn't invent new __*__ names,
even though I consider that a meta protocol. I get annoyed at
criticism for following standard protocols.
I don't know (or at least can't remember) all of the history of the
discussion about that, but I wouldn't argue about following standard
protocols.
I think the issue is with that it's not standard protocol the way we use
it - at least I can't find our use of __bases__ documented in Python's
documentation[1] about __bases__ and thus have a hard time saying we're
following standard protocols.
Christian
[1] ..
http://docs.python.org/library/stdtypes.html?highlight=__bases__#class.__bases__
--
Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
smime.p7s
Description: S/MIME Cryptographic Signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Wanted: representatives from Zope 2, grok, and BlueBream to engineer ZTK 1.0 release
Christian Theune wrote: > On 03/29/2010 04:08 PM, Christian Theune wrote: >> Hi everyone, >> >> on the way towards a ZTK 1.0 release we first looked for a single >> volunteer release manager who would drive the process. >> >> As no one stepped up and no (serious) nominations were presented the >> discussion went back to the drawing board and the plan was changed a >> bit: we'd like to go with a (small) team of representatives from the >> large ZTK consumers, namely: Zope 2, grok, and BlueBream. > > We're still missing someone from grok and I just send a reminder on > their list. So I'm going back to hibernation on this topic for now. You can enlist me as representative for Grok. Knowing of course that I can count on the grok-dev list's help. regards and thanks for coordinating this. regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Tue, Apr 20, 2010 at 3:04 PM, Fred Drake wrote:
> On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune wrote:
>> zope.testing uses the attribute '__bases__' to store the information what
>> the base layers are. __*__ are supposedly Python internal attributes.
>> Specifically __bases__ is known to be used to store information which base
>> classes a class has.
>
> This sort of misdirection has, unfortunately, a long history in Zope 3
> (and the various things that's become). Witness __name__. (There are
> others, but most aren't *actually* used by Python implementations.)
>
> Removing existing __*__ name ("underware") usage is probably
> untenable, but I hope we can avoid extending our foolishness.
OK, let's stop new uses of __*__ names. We won't provide initializers
for classes, or implement operations either.
The use of protocols like __name__ and __bases__ is intended to
conform to common usage in Python.
Let's invent new names that are specific to our own frameworks.
I can live with saying we shouldn't invent new __*__ names,
even though I consider that a meta protocol. I get annoyed at
criticism for following standard protocols.
Jim
--
Jim Fulton
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On 04/20/2010 09:04 PM, Fred Drake wrote:
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune wrote:
zope.testing uses the attribute '__bases__' to store the information what
the base layers are. __*__ are supposedly Python internal attributes.
Specifically __bases__ is known to be used to store information which base
classes a class has.
This sort of misdirection has, unfortunately, a long history in Zope 3
(and the various things that's become). Witness __name__. (There are
others, but most aren't *actually* used by Python implementations.)
Removing existing __*__ name ("underware") usage is probably
untenable, but I hope we can avoid extending our foolishness.
Yeah, I guess so: my impression of the OO structure after understanding
what's going on was quite satisfied. It's just very misleading. :)
--
Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
smime.p7s
Description: S/MIME Cryptographic Signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Tue, Apr 20, 2010 at 2:58 PM, Christian Theune wrote:
> zope.testing uses the attribute '__bases__' to store the information what
> the base layers are. __*__ are supposedly Python internal attributes.
> Specifically __bases__ is known to be used to store information which base
> classes a class has.
This sort of misdirection has, unfortunately, a long history in Zope 3
(and the various things that's become). Witness __name__. (There are
others, but most aren't *actually* used by Python implementations.)
Removing existing __*__ name ("underware") usage is probably
untenable, but I hope we can avoid extending our foolishness.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On 04/20/2010 08:44 PM, Jim Fulton wrote: On Tue, Apr 20, 2010 at 12:09 PM, Christian Theune wrote: Minor note: zope.testing *promotes* layers the wrong way and zope.app.testing definitely implements them the wrong way. That's prety vague. Could you say specifically in what ways zope.testing promotes layers the wrong way and zope.testing uses the attribute '__bases__' to store the information what the base layers are. __*__ are supposedly Python internal attributes. Specifically __bases__ is known to be used to store information which base classes a class has. Looking at this I (and others too) get directed towards: aha, so layers are classes and use inheritance to signal what base layers are. Which is exactly not what is happening. > zope.app.testing uses them the wrong way? Actually it doesn't. I confused this with Zope 2's Testing: There's Testing/ZopeTestCase/layer.py which defines a class with classmethods and in a similar fashion there is Products.PloneTestCase that defines classes, derives them and thus kind of piggybacks on the class inheritance mechanism to establish __bases__ paired with static methods but without actually inheriting methods. We struggled through some hairy details that I fail to remember when we worked on gocept.selenium last year which tries to establish a generic layer that can be combined with others. Looking at the layer code in gocept.selenium right now it feels relatively clean, although the exact choice of attribute names IMHO is confusing for anyone trying to understand whats going on and why. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Tue, Apr 20, 2010 at 12:09 PM, Christian Theune wrote: > Minor note: zope.testing *promotes* layers the wrong way and > zope.app.testing definitely implements them the wrong way. That's prety vague. Could you say specifically in what ways zope.testing promotes layers the wrong way and zope.app.testing uses them the wrong way? Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 4:46 AM, Lennart Regebro wrote: > And here is another interesting experiment: > > svn+ssh://rege...@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching > > It replaces the custom doctest.py with monkey-patches. > I will report these to the Python bugtracker as well, although I have > no hope of getting them into Python 2.7. But that doesn't matter much. > :) > > Benefits: We don't have to maintain a separate doctest.py, and we get > the bugfixes from Python. We haven't merged from Python trunk since > 2004, and there are LOADS AND LOADS of bugfixes done on the Python > doctest which we don't have. There are three bugfixes and two > "features" that we have that I now monkey patch in in this branch. > > Drawbacks: If you import zope.testing.doctest, *all* your doctests > will belong to us, so if you have doctests that expect the bugs, your > out of luck. :) > Also, I do not monkey-patch in the footer parsing support. It's too > big, use Manuel instead if you need that. > > > If noone protests, I'll merge this into my "no testrunner branch", > make it support Python 3, and then merge that to trunk, maybe sometime > next week. Strong -1. Monkey patching should be used as a last resort. Monkey patching the standard library is likely to make us look like jack asses. We should switch to manuel, which already has the footnote feature. Let zope.testing.doctest wither and die, or reimplement it as a facade on manuel. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Validating invariants with zope.schema.getValidationErrors and zope.schema.Object
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey Popp wrote: > does anyone know why zope.schema.Object does not check invariants > during validation process? If object conforms to schema it implies > that object should conform all schema invariants, insn't it? Likely you have found a bug. please report it to the zope.schema tracker: https://bugs.launchpad.net/zope.schema Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvN71QACgkQ+gerLs4ltQ66CgCeNuk+9zlpEGTbEqTIsfalipD6 fGkAoKIeOzTBFRAFEL8mxSr4Iu2e2/K2 =0/QY -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Validating invariants with zope.schema.getValidationErrors and zope.schema.Object
Hello, does anyone know why zope.schema.Object does not check invariants during validation process? If object conforms to schema it implies that object should conform all schema invariants, insn't it? Thanks. -- Andrey Popp phone: +7 911 740 24 91 e-mail: 8may...@gmail.com ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
On 04/17/2010 03:41 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This kind of goes with Lennart's frustration about trying to port the > ZTK packages, or a core subset, to Python 3. > > I would like to see the ZTK packages have really excellent > documentation, as well as 100% test coverage. I think we need to look > at refactoring how the testing story is done to get both needs > satisfied: trying to achieve both with a single set of doctests is > pretty near impossible: > > - - Testing setup and teardown code obscures the narrative flow / intent >of the documentation. > > - - Edge case testing *really* obscures the same. > > - - Test coverage suffers, because it is hard to write edge-case tests >in doctest. > > - - Porting the doctests where people have tried to juggle both goals >across Python versions is a mess. > > The refactoring I would like to see happen is to move the main narrative > documentation into a separate, Sphinx-driven 'docs' directory in each > ZTK package. As part of this move, we can start adding some of the > really nice Sphinx features (cross references, indexing, auto-generation > of API reference information, etc.). > > We can still leave the "main line" of the code illustrated using > doctest-style blocks: Sphinx has nice support for testing those blocks > *while building the docs*. At the end of this part of the change, each > package would have a much improved documentation set, with tested > examples. At the end of the process, we would be able to put the docs > for each package into an "intersphinx" tree underneath the main ZTK > docs, which could serve as the gateway into them. > > The trickier testing bits we would re-write as super thorough, no > shortcuts-taken unit tests: one testcase class per class (or API > function) under test, at least one method per class-under-test method, > with more preferred to get all code paths / preconditions covered. The > goal here would be to comment out the doctests from the test_suites and > get the code to 100% coverage using pure unit tests. Meanwhile, the > doctests would be refactored into the Sphinx documentation, losing all > the bits which obscure their intent as documentation. > > I would say that the risks here are slight, given that aiming for 100% > test coverage is likely to catch any oversights made during porting to > the new style. The amount of work for any given package is fairly-well > contained, I think: most of the effort will be in reverse-engineering > the intent of the "edge-case" tests. > > I made a sketch at what these changes would look for the zope.event > package like on a branch in Subversion: > >http://svn.zope.org/zope.event/branches/tseaver-new_style_docs > > I select zope.event largely because it is small enough that the scope of > the structural changes wouldn't be lost in the diffs for the actual > tests (and also because I didn't want to do the work for a bigger > package before getting feedback). > > The rendered docs from that branch are here: > >http://palladion.com/static/zope.event-docs/ > > I pushed the bzr branch to Launchpad, to let you see the kinds of > changes I made to get there (our viewcvs story is not nearly as easy to > review as the Launchpad changeset view): > >https://code.launchpad.net/~tseaver/zope.event/new_style_docs > > I am attaching an annotated diff for those who would prefer to see the > changes in that format. > > I would say that this cleanup effort should start at the "bottom" layers > of the ZTK, dependency-wise (zope.interface, zope.component, etc.) and > move "upwards" (in the depenency sense) over time. > > Thoughts? +the-rest-of-points-my-karma-allows-me Let me raise another issue which is that we also need to figure out how to follow up with this once we start. ;) -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
On 04/19/2010 04:06 PM, Lennart Regebro wrote: > On Mon, Apr 19, 2010 at 16:03, Lennart Regebro wrote: >> On Mon, Apr 19, 2010 at 15:48, Marius Gedminas wrote: >>> If you've the discipline to keep the doctests short, I don't see why you >>> shouldn't continue writing them instead of unit tests >> >> Because they are a bitch to debug, relies on details of output, which >> makes them brittle, hard to port to Python 3, and can be tricky to set >> up with loads of subtle things like inheriting the environment from >> where the DocTest was created, etc. > > And from __future__ imports doesn't work. And.. I'm sure I'm gonna > remember more reason why doctests are bad later, but I can't be > bothered really. Try defining a (persistent) class and sticking it into a ZODB. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
On 04/19/2010 03:56 PM, Wichert Akkerman wrote: > On 4/19/10 15:48 , Marius Gedminas wrote: >> def doctest_MyClass_bar(): >> """Test MyClass.bar >> >> >>> y = MyClass() >> >>The bar method peforms a bar calculation that typically returns >>twenty-three: >> >> >>> y.bar() >> 23 >> >> """ > > What is the advantage of that over: > > def test_something(self): ># Test MyClass.bar > >y=MyClass() > ># The bar method peforms a bar calculation that typically ># returns 23. > >self.assertEqual(y.bar(), 23) > > It reads the same, and as a bonus you can step through it with pdb and > syntax highlighting works normally in most editors. I had some good experiences in the last 6 months or so when switching from doctests that were tests (not documentation) to this style of testing. Also the review process mentioned (or pairing) helps to put comments in places where the code isn't easily understood by itself (after that, refactor the code so you don't need comments and put the real comments in). Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
On 04/17/2010 10:56 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lennart Regebro wrote: >> On Sat, Apr 17, 2010 at 19:17, Tres Seaver wrote: >>> I'm ambivalent about testing the Sphinx code snippets on each test run. >>> I want those snippets to be *much* less comprehensive than they are >>> currently, and am pretty sure that drift in the non-executable bits is >>> at least as important a problem as drift in the snippets. >> >> Well, unless they take of time, but they shouldn't, really. I think >> it's positive to get a quick feedback if you are breaking the >> documentation. > > Again, I don't mind that part, but I want to break the cycle of jamming > crap (for documentation purposes) into the docs for purposes of getting > test coverage. I think Lennart was arguing for a safety belt: if we're not supposed to break those tests *at all* within bug fixes then I want to know right away if I did so accidentally. I guess your coverage argument was that if the unit tests do the coverage anyway then we won't miss anything, but we won't be 100% anyway and as the tests in the docs do exist and should run quickly, the safety belt would be cheap. I'm +0.5 after some pondering. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testrunner (Was: Circular dependency hell.)
On 04/19/2010 01:03 PM, Lennart Regebro wrote: > OK, I made a branch of zope.testing that doesn't include the > testrunner. That was easy peasy. > > http://svn.zope.org/zope.testing/branches/regebro-notestrunner/ > > And I made a zope.testrunner: > > http://svn.zope.org/zope.testrunner/trunk > > That was pretty easy too. Except one thing: The shuffle feature > shuffles things differently in zope.testrunner compared to in > zope.testing.testrunner, which seems to be because it finds the layers > in a different order. > > Anybody using the shuffle feature with seeds in their tests, so we can > make sure it still actually works? The intention is to make a few successive runs have the same ordering. I wouldn't complain if a switch to a different test runner version changed ordering for a seed as long as the order then remains stable. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On 04/20/2010 03:59 PM, Martin Aspeli wrote: > On 20 April 2010 21:23, Lennart Regebro wrote: >> On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman wrote: >>> You may want to move it outside the zope.* namespace to encourage that :) > > -1 > > I think zope.testrunner is just fine, and acknowledges the heritage. > Namespaces should be about which community (or company) owns a > package, not marketing. I think we're a little over-sensitive to the > "it's Zope so we hate it" sentiment. The people (if any) who still > have such childish ideas are probably not all that interesting to us > as consumers of our software anyway. And I'd like to retain my badge of being a proud Zope developer anyway. ;) -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
Hi, On 04/17/2010 06:34 AM, Martin Aspeli wrote: > Hi Lennart& co, > > On 17 April 2010 02:38, Lennart Regebro wrote: >> On Fri, Apr 16, 2010 at 19:53, Jonathan Lange wrote: >>> As the author of one of those other testrunners, I can tell you that >>> if you do this you'll find that your number one biggest problem is >>> getting layers to work. >> >> Ah, right, layers are in zope.testing too. To actually get widespread >> movement from zope.testing we would have to make some other layer >> support. Hm... > > As you may know, I've been working on plone.testing. This is mainly to > make it easier for people working on Plone packages to write "good" > tests (and a lot of it is just about patterns, rather than code), but > in fact it doesn't depend on Plone (and only soft-depends on Zope 2). > I'm certainly hoping to use it for my "plain Zope 3/Toolkit" packages > in the future. > > plone.testing makes very heavy use of layers. I think layers are a > great feature, when done properly, and I haven't seen any better > approach. The setUpClass/setUpModule stuff in unittest2 is nice, but > doesn't really solve the same problem. For integration testing with > something as complex as Zope 2 (or, arguably, the ZODB, various bits > of the ZTK, and so on) layers allow "us" the framework authors to make > life much easier for those people who are not experts in the > framework. > > Anyway, a few high level observations: > > - In neither plone.testing (apart from its own tests), nor in code > that uses it, would I imagine actually depending on zope.testing via > an import. We use unittest(2) and doctest from the standard library. > > - We do depend on a zope.testing-compatible test runner, in that we > expect layers to work. In reality, we depend on zc.recipe.testrunner, > though I would *love* to be able to do 'python setup.py test' as well > (and have that execute tests with layers). I have no idea how that > works or whether it'd be possible. > > - The way zope.testing promotes writing layers is actually pretty > evil. It overloads the 'class' keyword, essentially, making you spell > "base layers" as base classes. This has a few problems: > > - If your "base layer" has a testTearDown method, say, and your > layer doesn't, the base class version will actually inherit into the > child layer. zope.testing will then run the same code twice, once for > the base layer and once for the child layer. > > - You can't use OOP inheritance to re-use layer conveniences. > > - People get quite confused. :) > > - You can't have two copies of a layer - all layers are > module-level global singletons. This becomes somewhat important when > layers manage and expose resources (like database connections). Minor note: zope.testing *promotes* layers the wrong way and zope.app.testing definitely implements them the wrong way. However, the testrunner itself deals with them in a way that allows you to use them correctly. I think the situation itself could be remedied if the actual layers that are around would be rewritten and a few annoyances (handling of missing methods) straightened out. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Wanted: representatives from Zope 2, grok, and BlueBream to engineer ZTK 1.0 release
On 03/29/2010 04:08 PM, Christian Theune wrote: > Hi everyone, > > on the way towards a ZTK 1.0 release we first looked for a single > volunteer release manager who would drive the process. > > As no one stepped up and no (serious) nominations were presented the > discussion went back to the drawing board and the plan was changed a > bit: we'd like to go with a (small) team of representatives from the > large ZTK consumers, namely: Zope 2, grok, and BlueBream. We're still missing someone from grok and I just send a reminder on their list. So I'm going back to hibernation on this topic for now. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unauthorized handling in Zope2
Hi! Wichert Akkerman wrote: > On 4/20/10 15:17 , yuppie wrote: >> Wichert Akkerman wrote: >>> I added an extra change (see diff below) to fix that, after which things >>> seemed to work. >> >> Great! > > Can you commit that change along with your other changes? Yes. I'll write some more tests and commit it in time for the 2.12.5 release. Thanks for catching this issue early enough! >> Re-raising the exceptions makes sure the post-processing in >> HTTPResponse.exception is called. That is also expected by >> CookieCrumbler and PAS. > > The authentication dance between the publisher, request, PAS and > CookieCrumbler really is a bit contrived :( An other advantage of the re-raising pattern is the fact that you can easily change the response type by raising a different exception inside the view. I plan to use that for replacing the nasty unauth redirect code in CookieCrumbler. The exception view will raise Redirect or Forbidden if you are already logged in. >> A better fix would be to store the rendered exception value in the >> response object instead of the exception object. That way we could >> re-raise *all* exceptions as it was done in older Zope versions. >> >> But this would have been a bigger refactoring with more risks to break >> something else. > > Perhaps something for 2.13 :) Yes. Perhaps ;) Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.i18nmessageid-3.5.1 py2.5 win binary
Hi Adam windows binaries available for python 2.4 and 2.5 Regards Roger Ineichen > -Ursprüngliche Nachricht- > Von: zope-dev-boun...@zope.org > [mailto:zope-dev-boun...@zope.org] Im Auftrag von Adam Groszer > Gesendet: Dienstag, 20. April 2010 08:27 > An: Zope-dev > Betreff: [Zope-dev] zope.i18nmessageid-3.5.1 py2.5 win binary > > Hello, > > Someone please make a release of the above. > > -- > Best regards, > Adam > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On 20 April 2010 21:23, Lennart Regebro wrote: > On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman wrote: >> You may want to move it outside the zope.* namespace to encourage that :) -1 I think zope.testrunner is just fine, and acknowledges the heritage. Namespaces should be about which community (or company) owns a package, not marketing. I think we're a little over-sensitive to the "it's Zope so we hate it" sentiment. The people (if any) who still have such childish ideas are probably not all that interesting to us as consumers of our software anyway. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tuesday 20 April 2010, Lennart Regebro wrote: > (zope.testrunner of course also being one perfectly good idea). I like zope.testrunner. If it gets its own Web site (eventually), we have a good place to guide people there. Regards. Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 15:23, Lennart Regebro wrote: > On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman wrote: >> You may want to move it outside the zope.* namespace to encourage that :) > > We could certainly do that. > > > Jarrett - After Arthur Jarrett, convicted of the crime of making of > gratuitous sexist jokes in a moving picture. > > Or maybe not. :) Other ideas? (zope.testrunner of course also being one perfectly good idea). ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 13:44, Wichert Akkerman wrote: > You may want to move it outside the zope.* namespace to encourage that :) We could certainly do that. Jarrett - After Arthur Jarrett, convicted of the crime of making of gratuitous sexist jokes in a moving picture. Or maybe not. :) Other ideas? ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unauthorized handling in Zope2
On 4/20/10 15:17 , yuppie wrote:
> Hi!
>
>
> Wichert Akkerman wrote:
>> Unauthorised is doing stupid things here:
>>
>> (Pdb) p v
>> Unauthorized()
>> (Pdb) p unicode(v)
>> u''
>> (Pdb) p str(v)
>> *** UnicodeEncodeError: UnicodeEncodeError('ascii',
>> u'>
>> I added an extra change (see diff below) to fix that, after which things
>> seemed to work.
>
> Great!
Can you commit that change along with your other changes?
>> Still, I can not see any good reason to reraise
>> Unauthorised exceptions if there is a valid exception view for them.
>> This approach feels like we are attacking the symptom instead of fixing
>> the problem.
>
> Zope 2.12.4 was definitely broken:
>
> 401 Unauthorized responses "MUST include a WWW-Authenticate header
> field", see
> http://tools.ietf.org/html/rfc2616#section-10.4.2
Hm, fair point.
> Re-raising the exceptions makes sure the post-processing in
> HTTPResponse.exception is called. That is also expected by
> CookieCrumbler and PAS.
The authentication dance between the publisher, request, PAS and
CookieCrumbler really is a bit contrived :(
> A better fix would be to store the rendered exception value in the
> response object instead of the exception object. That way we could
> re-raise *all* exceptions as it was done in older Zope versions.
>
> But this would have been a bigger refactoring with more risks to break
> something else.
Perhaps something for 2.13 :)
Wichert.
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unauthorized handling in Zope2
Hi!
Wichert Akkerman wrote:
> Unauthorised is doing stupid things here:
>
> (Pdb) p v
> Unauthorized()
> (Pdb) p unicode(v)
> u''
> (Pdb) p str(v)
> *** UnicodeEncodeError: UnicodeEncodeError('ascii',
>u'
> I added an extra change (see diff below) to fix that, after which things
> seemed to work.
Great!
> Still, I can not see any good reason to reraise
> Unauthorised exceptions if there is a valid exception view for them.
> This approach feels like we are attacking the symptom instead of fixing
> the problem.
Zope 2.12.4 was definitely broken:
401 Unauthorized responses "MUST include a WWW-Authenticate header
field", see
http://tools.ietf.org/html/rfc2616#section-10.4.2
Re-raising the exceptions makes sure the post-processing in
HTTPResponse.exception is called. That is also expected by
CookieCrumbler and PAS.
A better fix would be to store the rendered exception value in the
response object instead of the exception object. That way we could
re-raise *all* exceptions as it was done in older Zope versions.
But this would have been a bigger refactoring with more risks to break
something else.
Cheers,
Yuppie
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unauthorized handling in Zope2
On 4/20/10 09:51 , yuppie wrote:
> Hi!
>
>
> Wichert Akkerman wrote:
>> v is the html as generated by my view. Reraising the exception transfers
>> control to the bare except in
>> ZPublisher.Publish.publish_module_standard, which generates the standard
>> site error page and returns that.
>
> Could it be that your v is unicode?
>
> Please let me know if the attached patch fixes the issue.
Unauthorised is doing stupid things here:
(Pdb) p v
Unauthorized()
(Pdb) p unicode(v)
u''
(Pdb) p str(v)
*** UnicodeEncodeError: UnicodeEncodeError('ascii',
u'https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unauthorized handling in Zope2
On 4/20/10 09:51 , yuppie wrote: > Hi! > > > Wichert Akkerman wrote: >> v is the html as generated by my view. Reraising the exception transfers >> control to the bare except in >> ZPublisher.Publish.publish_module_standard, which generates the standard >> site error page and returns that. > > Could it be that your v is unicode? Indeed it is: Chameleon returns a unicode response it seems. > Please let me know if the attached patch fixes the issue. I'm afraid it doesn't. The result is this: Site Error An error was encountered while publishing this resource. Unauthorized Sorry, a site error occurred. Traceback (innermost last): Module ZPublisher.Publish, line 238, in publish_module_standard Module Products.PDBDebugMode.runcall, line 83, in pdb_publish Module ZPublisher.Publish, line 165, in publish Module plone.app.linkintegrity.monkey, line 21, in zpublisher_exception_hook_wrapper Module ZPublisher.Publish, line 116, in publish Module ZPublisher.BaseRequest, line 609, in traverse Module ZPublisher.HTTPResponse, line 720, in unauthorized Unauthorized: Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 10 OK, 4 Failed
Summary of messages to the zope-tests list. Period Mon Apr 19 12:00:00 2010 UTC to Tue Apr 20 12:00:00 2010 UTC. There were 14 messages: 6 from Zope Tests, 7 from ccomb at free.fr, 1 from ct at gocept.com. Test failures - Subject: FAILED: Repository policy check found errors in 669 projects From: ct at gocept.com Date: Mon Apr 19 21:16:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014027.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Mon Apr 19 23:53:58 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014038.html Subject: FAILED : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Mon Apr 19 23:55:15 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014039.html Subject: FAILED : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Mon Apr 19 23:55:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014040.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Apr 19 21:30:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014028.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Apr 19 21:32:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014029.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Apr 19 21:34:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014030.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Apr 19 21:36:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014031.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Apr 19 21:38:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014032.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Apr 19 21:40:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014033.html Subject: OK : BlueBream template / Python2.4.6 32bit linux From: ccomb at free.fr Date: Mon Apr 19 22:00:45 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014034.html Subject: OK : BlueBream template / Python2.7b1 32bit linux From: ccomb at free.fr Date: Mon Apr 19 22:00:49 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014035.html Subject: OK : BlueBream template / Python2.5.2 32bit linux From: ccomb at free.fr Date: Mon Apr 19 22:00:50 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014037.html Subject: OK : BlueBream template / Python2.6.4 32bit linux From: ccomb at free.fr Date: Mon Apr 19 22:00:50 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014036.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tue, Apr 20, 2010 at 7:44 AM, Wichert Akkerman wrote: > You may want to move it outside the zope.* namespace to encourage that :) People interested in interfaces or component architectures don't seem to mind using zope.interface or zope.component; those get selected on their own merits with some frequency. I see no need to drop/replace the "zope." in the package name. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On 4/20/10 13:37 , Stephan Richter wrote: > On Tuesday 20 April 2010, Lennart Regebro wrote: >> It replaces the custom doctest.py with monkey-patches. >> I will report these to the Python bugtracker as well, although I have >> no hope of getting them into Python 2.7. But that doesn't matter much. >> >> :) > > Fantastic. I really hate the improper counting of the Python version. :-) > > BTW, I also like your splitting of the test runner and the testing > infrastructure. The zope.testing testrunner is really good and deserves its > own life. I hope that more people will pick it up. You may want to move it outside the zope.* namespace to encourage that :) Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
On Tuesday 20 April 2010, Lennart Regebro wrote: > It replaces the custom doctest.py with monkey-patches. > I will report these to the Python bugtracker as well, although I have > no hope of getting them into Python 2.7. But that doesn't matter much. > > :) Fantastic. I really hate the improper counting of the Python version. :-) BTW, I also like your splitting of the test runner and the testing infrastructure. The zope.testing testrunner is really good and deserves its own life. I hope that more people will pick it up. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Agenda for today's meeting
Hi everyone, another weekly meeting is coming up today and I hope see you again around 3pm UTC at #zope at freenode. (That's about 4 hours from now on.) Last week's summary is here: https://mail.zope.org/pipermail/zope-dev/2010-April/040112.html Agenda -- - Version/release issues (KGS 3.4.1, requested by Adam Groszer) - LP bug management - Triage of old Zope 3 bugs -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.test.doctest made into monkey-patches (Was: Circular dependency hell.)
And here is another interesting experiment: svn+ssh://rege...@svn.zope.org/repos/main/zope.testing/branches/regebro-doctest-patching It replaces the custom doctest.py with monkey-patches. I will report these to the Python bugtracker as well, although I have no hope of getting them into Python 2.7. But that doesn't matter much. :) Benefits: We don't have to maintain a separate doctest.py, and we get the bugfixes from Python. We haven't merged from Python trunk since 2004, and there are LOADS AND LOADS of bugfixes done on the Python doctest which we don't have. There are three bugfixes and two "features" that we have that I now monkey patch in in this branch. Drawbacks: If you import zope.testing.doctest, *all* your doctests will belong to us, so if you have doctests that expect the bugs, your out of luck. :) Also, I do not monkey-patch in the footer parsing support. It's too big, use Manuel instead if you need that. If noone protests, I'll merge this into my "no testrunner branch", make it support Python 3, and then merge that to trunk, maybe sometime next week. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Created bug tracker for repository policy
Hi, as there were various issues about our repository policy floating around, I have created an according project on launchpad with a bug tracker: http://bugs.launchpad.net/zope.repositorypolicy/ I'm filing the issues I know of: - superfluous check for ZF being author - badly formatted ZPL 2.1 required Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: ZConfig/trunk/setup.py correct metadata: I really did write this.
Hi, On 04/09/2010 07:38 PM, Zvezdan Petkovic wrote: > On Apr 9, 2010, at 10:57 AM, Fred Drake wrote: > >> On Fri, Apr 9, 2010 at 10:43 AM, Tres Seaver wrote: >>> It seems reasonable to me that it *should* work, though I'm not sure how to >>> write the code which tests that. >> >> See my later follow-up as well. >> >> In particular, while it *may* be reasonable to set the ZF as >> maintainer, it's not clear that it's the right thing either. Why >> shouldn't some "Grok Team" be listed as the maintainer for the grok >> packages, with an appropriate email? That seems preferable to me. >> >> I think the *right* thing to do is update the copyrights to reflect >> the copyright ownership, but not to otherwise change package metadata. > > Why was the check for author even included in the checker/fixer scripts? > Can you point us to the Zope Foundation bylaws or a policy document that > requires this? > > I cannot find this in a contributor agreement. Pondering it this is an overzealous misunderstanding on my part. I'm removing the assertion. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] "Comply with repository policy" ?
On 04/09/2010 05:31 PM, yuppie wrote: > Hi! > > > Tres Seaver wrote: >> yuppie wrote: >>> Tres Seaver wrote: >>> So depending on a layout difference (line break or not) it produces >>> copyright headers with different content. >>> >>> Doesn't make any sense to me, but the people I already asked don't care. >> >> The "All Rights Reserved" is a little senseless, since the following >> language turns around and says that the files are covered by the ZPL. > > I'm not opposed to removing that phrase. What I don't like is the fact > that it is removed randomly based on a bug in a script that is made for > a different purpose. Right. I'd consider that behaviour not a bug, but actually point out that all the examples in documentations that I have found considered the copyright to be stand-alone on a single line with the next line following to carry the "All rights reserved" remark. Although the tool screws up, the output of the tool really is intended to be reviewed by the person who does the checkin. > I think a change like that should be based on an official policy change, > including new coding style guidelines: > http://docs.zope.org/zopetoolkit/codingstyle/python-style.html#license-statement-module-docstring I'd move this off from the topic of the tool being broken: if either of you would like to follow up on removing the "all rights reserved" from the header, then please acknowledge that and I'll pick it up (probably that needs to go to the foundation?!? I bet some lawyer wanted that phrase to be in there originally and I guess we have to ask the ZF board whether that part of the policy can be changed.) Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Unauthorized handling in Zope2
Hi! Wichert Akkerman wrote: > v is the html as generated by my view. Reraising the exception transfers > control to the bare except in > ZPublisher.Publish.publish_module_standard, which generates the standard > site error page and returns that. Could it be that your v is unicode? Please let me know if the attached patch fixes the issue. Cheers, Yuppie Index: public/src/zExceptions/unauthorized.py === --- public/src/zExceptions/unauthorized.py (revision 62) +++ public/src/zExceptions/unauthorized.py (working copy) @@ -43,7 +43,7 @@ provides are added to needed. """ if name is None and ( -not isinstance(message, StringType) or len(message.split()) <= 1): +not isinstance(message, basestring) or len(message.split()) <= 1): # First arg is a name, not a message name=message message=None Index: public/src/ZPublisher/HTTPResponse.py === --- public/src/ZPublisher/HTTPResponse.py (revision 62) +++ public/src/ZPublisher/HTTPResponse.py (working copy) @@ -800,7 +800,10 @@ b = v if isinstance(b, Exception): try: -b = str(b) +try: +b = str(b) +except UnicodeEncodeError: +b = self._encode_unicode(unicode(b)) except: b = '' % type(b).__name__ ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
