Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
On Tue, Dec 29, 2009 at 23:47, Marius Gedminas mar...@gedmin.as wrote: I don't know enough about the differences between stdlib's doctest.py (in its various Python 2.4/2.5/2.6 incarnations) and zope.testing.doctest, other than that I've seen diffs, they were non-trivial, with bugfixes and new features; I've heard about monkey-patching the stdlib's doctest.py (which fills me with dread; when exactly is the monkey-patching performed?), and I'd rather not touch the issue without either complete understanding or a very large test suite (all of the packages that were in the Zope 3 KGS at the very least) run on various platforms. zope.testing runs a lot of doctests. Lot's and lot's. In the Python 3 branch I've moved them over to using stdlibs doctest. There was two bugs that are fixed in Zopes doctest that is not fixed in Pythons doctest. I've added monkey-patches on import for them. Obviously they should also be reported upstream, but new releases won't remove the bugs in old releases, so the monkey patches need to stay anyway. The alternative to this is that somebody port zopes doctest.py to Python 3, so we don't deprecate it but keep it separate, for ever adding to the frustration and complication in doing testing and in particular doctesting that persists. * custom doctest exception formatting What does that formatting actually do? * support for the INTERPRET_FOOTNOTES feature Then they should use Manuel. I find it highly unlikely that this feature will make it into stdlib. and since zope.testing.doctest still reimplements large bits of doctest, I don't know what other bugfixes might be lost too (like the universal newline thing that punishes people for daring to release packages from Windows machines). There's no test for that one, so I didn't know about it. I think the problem with having a sperate doctest.py is evident in the fact that there has been bugs fixed for *years* but not moved upstream. The custom doctest was there to support Python 3, and nothing else. Now it's become it's own creature, and that's very bad. Overall, I'm still -1 for deprecating zope.testing.doctest at this point. A PendingDeprecationWarning would be more appropriate, IMHO. That will just leave less time between people getting warned and before it gets removed. I must say I find PendingDeprecationWarnings completely and utterly pointless. -- 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] removing zope.app from the ZTK
I agree with everything except: On Tue, Dec 29, 2009 at 23:30, Martijn Faassen faas...@startifact.com wrote: Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS. I don't agree with this statement. What we want is that the Zope 3 KGS becomes based on the ZTK KGS. After that happens, people might realize they can move from Zope 3 KGS to ZTK KGS, but that's up to them. We don't want anything there. :) It depends on what they do with Zope 3. Fact 6: We were maintaining such a KGS within the ZTK. I dont' think you are. The ZTK KGS as it is today is not a replacement for the Zope 3 KGS, and never was, and never was intended as such. -- 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] [ZODB-Dev] Splitting a large ZODB file storage - any light-weight approach?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: Hi there, we have some huge ZODB file storage (60-80 GB each) and we want to split the storage into a number of smaller storage (easier to handle for backup and packing). The storages themselves only contain a few (Zope 2) folders - let's say folders A, B, C - within the root and we want to create seperate storages for A, B, C. Is there some easier approach than using the Zope 2 CopyManager API for moving data around. The ZODB storage iterator API comes to my mind... is this a suitable approach or is there some other light-weight approach (compared to using CopyManager API)? Why move any data between ZODBs at all? In this situation I would try the following: - create a new empty ZODB. This one holds the root. - copy the old Data.fs into three new storage server buildouts. Attach to each with a ZEO client and delete the folders you do not need in that particular storage in the ZMI or via zopectl debug. - pack each storage so the deleted data gets trashed and the files shrink. - mount the folder storages into the new empty root using mount points on the clients that will use the storages. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7CpEACgkQRAx5nvEhZLKjYgCdGI71f/yNJS3EIpZxkyFVBmSe qhMAoJ8RBK2eq27P67Iki4h4MYMZ1kZB =FC8f -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] Zope 3.4 and the way forward
On Wed, Dec 30, 2009 at 00:07, Marius Gedminas mar...@gedmin.as wrote: So, what's the way forward for existing Zope 3.4 (KGS) users? I'm not one, so I really should shut up, but I won't. :) Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK? Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0? I think: Both of these. :) A 3.5 KGS that includes all the 3.4 packages and has deprecation warnings for the refactorings out of zope.app seems to me to be a great help in this. Then the 3.4 users can switch to 3.5, fix all the zope.app imports that are gone, and still have everything working. You can then look at your code and see how much you use of zope.app packages after such a refactoring. If that is not much then team up with Martijn who wanted to make a smaller ZTK publisher, or look into if you can use BFG's publisher. That's going to be more work, but I suspect most 3.4 users would be able to use it and end up with a smaller leaner app. Butwhat do I know. I'm just guessing. -- 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] [ZODB-Dev] Splitting a large ZODB file storage - any light-weight approach?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: - copy the old Data.fs into three new storage server buildouts. Attach to each with a ZEO client and delete the folders you do not need in that particular storage in the ZMI or via zopectl debug. Delete operations will trigger events modifying other global metadata related to the those objects. So this approach requires modification to the application in order to avoid such side effects. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks7DFEACgkQCJIWIbr9KYxIcACgonZfwXWmTqguW2tlcoEsLfNv 9KMAn0+h5EZ59ConlsKUNa1BWn2+bTt2 =bP9X -END PGP SIGNATURE- attachment: lists.vcf___ 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: 6 OK
Summary of messages to the zope-tests list. Period Tue Dec 29 12:00:00 2009 UTC to Wed Dec 30 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 29 20:38:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013287.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Dec 29 20:40:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013288.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:42:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013289.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:44:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013290.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:46:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013291.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Dec 29 20:48:10 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013292.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.testing 3.8.6 emits deprecation warnings from itself?
On Wed, Dec 30, 2009 at 08:58:52AM +0100, Lennart Regebro wrote:
On Tue, Dec 29, 2009 at 23:47, Marius Gedminas mar...@gedmin.as wrote:
I don't know enough about the differences between stdlib's doctest.py
(in its various Python 2.4/2.5/2.6 incarnations) and
zope.testing.doctest, other than that I've seen diffs, they were
non-trivial, with bugfixes and new features; I've heard about
monkey-patching the stdlib's doctest.py (which fills me with dread; when
exactly is the monkey-patching performed?), and I'd rather not touch the
issue without either complete understanding or a very large test suite
(all of the packages that were in the Zope 3 KGS at the very least) run
on various platforms.
zope.testing runs a lot of doctests. Lot's and lot's.
Do you mean the test suite of zope.testing itself? Yes, it's not tiny,
but that doesn't mean it is representative of all the other packages out
there that currently use zope.testing.doctest.
In the Python 3
branch I've moved them over to using stdlibs doctest. There was two
bugs that are fixed in Zopes doctest that is not fixed in Pythons
doctest. I've added monkey-patches on import for them.
On import of what? zope.testing's __init__.py?
I think I found it: in regebro-python3-reloaded branch I see
zope.testing's __init__ doing 'import monkeys', which is
http://zope3.pov.lt/trac/browser/zope.testing/branches/regebro-python3-reloaded/src/zope/testing/monkeys.py
Would you mind terribly adding a couple of comments explaining why
DocTestCase __init__ and tearDown need to be patched? Is that to
prevent the globs from keeping state between different tests? Just
guessing, by looking at the most interesting thing that happens in the
overridden methods.
Obviously they
should also be reported upstream,
The word should meaning they haven't been?
What are the bugs? The globs thing, and allowing mixed unicode + UTF-8
output inside doctests?
but new releases won't remove the
bugs in old releases, so the monkey patches need to stay anyway.
*nod*
The alternative to this is that somebody port zopes doctest.py to
Python 3, so we don't deprecate it but keep it separate, for ever
adding to the frustration and complication in doing testing and in
particular doctesting that persists.
I'm +1 for dropping the forked doctest.py, and I'm very grateful for
your Python-3-ification efforts of zope.stuff.
I'm -1 for leaving existing users of zope.testing.doctest hanging
without a known and documented migration path.
* custom doctest exception formatting
What does that formatting actually do?
I don't remember, exactly, I was just grepping the diffs for
DocTestFailureException. It's probably the bit that lets bin/test -c
colorize things like diffs, and tracebacks in doctest failures.
If that's the case, I'd truly hate to lose this feature, it helps me
immensely.
* support for the INTERPRET_FOOTNOTES feature
Then they should use Manuel.
Good, so we have a migration path for this bit!
How mechanical can such a transformation be? Is it sufficient to
replace
zope.testing.doctest.DocFileSuite('foo.txt', **kw)
with
manuel.testing.TestSuite(manuel.doctest.Manuel(), 'foo.txt', **kw)
or do we need other changes, like removing INTERPRET_FOOTNOTES from
optionflags and include the manuel.footnote.Manuel() in some way?
I've never used Manuel, I'm guessing what the syntax ought to be by
looking at http://packages.python.org/manuel/
I find it highly unlikely that this
feature will make it into stdlib.
I agree.
and since zope.testing.doctest still reimplements large bits of doctest,
I don't know what other bugfixes might be lost too (like the universal
newline thing that punishes people for daring to release packages from
Windows machines).
There's no test for that one, so I didn't know about it.
I still don't know anything definite about it, other than remembering
that at some point people on Windows would release .zip sdists with .txt
files inside that had DOS line-endings, and that would cause doctest
failures in some circumstances, again, I'm not sure which. It was
brought up in another thread recently, and I got the impression that
zope.testing.doctest had a fix of some kind (using universal newlines?).
I suppose we could ignore the issue and wait for some hapless Windows
user to bring it to our attention, at which point we'll fix it and make
sure our fix has a unit test. Maybe.
*shrug*
I think the problem with having a sperate doctest.py is evident in the
fact that there has been bugs fixed for *years* but not moved
upstream. The custom doctest was there to support Python 3, and
nothing else. Now it's become it's own creature, and that's very bad.
Yes, I absolutely agree!
Overall, I'm still -1 for deprecating zope.testing.doctest at this point.
A PendingDeprecationWarning would be more appropriate, IMHO.
That will just leave less time between people getting warned and
before it gets removed. I
Re: [Zope-dev] [ZODB-Dev] Splitting a large ZODB file storage - any light-weight approach?
On Wed, Dec 30, 2009 at 9:16 AM, Andreas Jung li...@zopyx.com wrote: Delete operations will trigger events modifying other global metadata related to the those objects. So this approach requires modification to the application in order to avoid such side effects. But if you do it from a debug prompt, you can easily prevent those events from being fired. For a normal ObjectManager you do: delattr(root, 'A') # this is what _delOb does root._objects = tuple([i for i in root._objects if i['id'] != 'A']) That's the actually important part of _delObject method, without firing any events or calling any manage_ methods. Hanno ___ 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.testing 3.8.6 emits deprecation warnings from itself?
On Wed, Dec 30, 2009 at 13:45, Marius Gedminas mar...@gedmin.as wrote:
Obviously they
should also be reported upstream,
The word should meaning they haven't been?
As far as I can tell, yes.
What are the bugs? The globs thing, and allowing mixed unicode + UTF-8
output inside doctests?
Yes. And apparently also the Windows lineendings.
I don't remember, exactly, I was just grepping the diffs for
DocTestFailureException. It's probably the bit that lets bin/test -c
colorize things like diffs, and tracebacks in doctest failures.
If that's the case, I'd truly hate to lose this feature, it helps me
immensely.
OK, so that colorizing support could probably also be moved into stdlib.
If someone (ie you, you seem to be on top of the problems) get diffs
into the Python tracker then maybe we could get it into Python 2.7 and
3.2, which would be cool.
How mechanical can such a transformation be? Is it sufficient to
replace
zope.testing.doctest.DocFileSuite('foo.txt', **kw)
with
manuel.testing.TestSuite(manuel.doctest.Manuel(), 'foo.txt', **kw)
No idea, the Manuel experts need to answer that. :)
--
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] removing zope.app from the ZTK
Lennart Regebro wrote: I agree with everything except: On Tue, Dec 29, 2009 at 23:30, Martijn Faassen faas...@startifact.com wrote: Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS. I don't agree with this statement. What we want is that the Zope 3 KGS becomes based on the ZTK KGS. After that happens, people might realize they can move from Zope 3 KGS to ZTK KGS, but that's up to them. We don't want anything there. :) It depends on what they do with Zope 3. Yes, a Zope 3 KGS will have to be a superset of the ZTK KGS. If we want to retain that name at all. But there will also have to be a transitional KGS for Zope 3, that contains things that we have deprecated and can be replaced (unless the ZMI is in use) with ZTK counterparts, such as zope.app.container. This one is needed so that people can update their imports. Fact 6: We were maintaining such a KGS within the ZTK. I dont' think you are. The ZTK KGS as it is today is not a replacement for the Zope 3 KGS, and never was, and never was intended as such. Effectively we were maintaining a large part of such a KGS within the ZTK. Perhaps not everything, but much that was the old Zope 3 was in there. This was the only version list which we as a community were maintaining of those packages. I agree that the ZTK never was intended to fully replace Zope 3 so things had to change. Regards, Martijn ___ 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.testing 3.8.6 emits deprecation warnings from itself?
On Wed, Dec 30, 2009 at 03:08:26PM +0100, Lennart Regebro wrote:
On Wed, Dec 30, 2009 at 13:45, Marius Gedminas mar...@gedmin.as wrote:
I don't remember, exactly, I was just grepping the diffs for
DocTestFailureException. It's probably the bit that lets bin/test -c
colorize things like diffs, and tracebacks in doctest failures.
If that's the case, I'd truly hate to lose this feature, it helps me
immensely.
OK, so that colorizing support could probably also be moved into stdlib.
If someone (ie you, you seem to be on top of the problems) get diffs
into the Python tracker then maybe we could get it into Python 2.7 and
3.2, which would be cool.
The only thing needed from doctest.py, AFAIU, is a custom exception
class inheriting from AssertionError, so the test runner (which does the
colorization) can distinguish doctest errors from regular assertion
failures.
It should be simple to monkey-patch this too, by setting
DocTestCase.failureException, so we can support Python 2.5 through 3.1
How mechanical can such a transformation be? Is it sufficient to
replace
zope.testing.doctest.DocFileSuite('foo.txt', **kw)
with
manuel.testing.TestSuite(manuel.doctest.Manuel(), 'foo.txt', **kw)
No idea, the Manuel experts need to answer that. :)
I was afraid you'd say that...
Marius Gedminas
--
http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital 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] zope.testing.doctestunit pprint and deprecation warnings
Hi there, zope.testing.doctestunit emits a deprecation warning. It also defines a function pprint. How does one use pprint without getting a deprecation warning? It seems impossible now, and an equivalent pprint doesn't appear to be in the standard library doctest.. Regards, Martijn ___ 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.testing.doctestunit pprint and deprecation warnings
On Wed, Dec 30, 2009 at 6:38 PM, Martijn Faassen faas...@startifact.com wrote: zope.testing.doctestunit emits a deprecation warning. It also defines a function pprint. How does one use pprint without getting a deprecation warning? It seems impossible now, and an equivalent pprint doesn't appear to be in the standard library doctest.. When I recently converted some tests, I replaced that pprint function with the one from the standard library: from pprint import pprint There weren't any differences in the output, as far as I could tell. Hanno ___ 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.app.form and zope.formlib
Hi there, I've been trying to clean up the zope.formlib/zope.app.form situation. This is a report about my lack of progress so far, just so I have something to show for it. :) zope.app.form is in practice in use as a widget library for zope.formlib. It however also contains code that supports the original Zope 3 form system (using ZCML directives). My first response was to try to move zope.app.form's widgets into zope.formlib. zope.app.form can then depend on zope.formlib for its widgets (for backwards compatibility), and zope.formlib would stop depending on zope.app.form. We can leave the old Zope 3 form system behind. I started to try this but was daunted by having to port a huge amount of code from zope.app.form to zope.formlib, including test code. Instead, I tried to create a zope.formlibwidget which which would contain only the widgets of zope.app.form. zope.app.form would then depend on it for backwards compatibility, and zope.formlib would only need to depend on zope.formlibwidget. Unfortunately this bounced off the fact that zope.app.form's functional widget tests (there are many, we want to retain them) depend on the old Zope 3 form support in order to do their tests. The old Zope 3 form support I was trying to get rid of in the first place. To do sane functional tests I need a form library. I can't use zope.formlib in zope.formlibwidget as that would create a circular dependency (at least for tests, but that's ugly enough). So my conclusion is to move zope.app.form's widget stuff into zope.formlib, so that the functional tests can be ported to use zope.formlib instead of the old Zope 3 form system. So I'm back to my original approach again... Regards, Martijn ___ 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.app.form and zope.formlib
Hey, Martijn Faassen wrote: So I'm back to my original approach again... This approach is working; I've moved the widget implementations and most tests from zope.app.form into zope.formlib now. zope.formlib has no more dependency on zope.app.form anymore either, instead zope.app.form depends on zope.formlib. There are still some functional tests to port and this is a bit more tricky. Hopefully I (or someone else) will get around to it soon. I'm talking about the test_functional_* tests in zope.app.form.browser.tests. Not of all of them are sensibly portable to zope.formlib, but the widget-related ones are. I have a few examples of ported versions already in zope.formlib.tests. Regards, Martijn ___ 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.testing.doctestunit pprint and deprecation warnings
Hanno Schlichting wrote:
On Wed, Dec 30, 2009 at 6:38 PM, Martijn Faassenfaas...@startifact.com
wrote:
zope.testing.doctestunit emits a deprecation warning. It also defines a
function pprint. How does one use pprint without getting a deprecation
warning? It seems impossible now, and an equivalent pprint doesn't
appear to be in the standard library doctest..
When I recently converted some tests, I replaced that pprint function
with the one from the standard library:
from pprint import pprint
There weren't any differences in the output, as far as I could tell.
Not sure if this is related, but one thing I found which bit me recently
is that prior to Python 2.5, pprint did not sort dict keys in the
output. That means that a test like this:
pprint(foo)
{'omega': 1, 'alpha': 2}
will pass on 2.4 and fail on 2.5/2.6; to fix it for 2.5/2.6 you do:
pprint(foo)
{'alpha': 2, 'omega': 1}
but now it fails on 2.4. The only way I could find it make it work
reliably was to not rely on dicts at all, but do:
pprint(sorted(foo.items())
[('alpha', 2), ('omega', 1)]
Which works the same on both. I don't know if the zope.doctest pprint
function was meant to fix this, but maybe it did?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
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: Zope/branches/2.11/ - Fixed improper handling of IF_MODIFIED_SINCE header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: Log message for revision 107356: - Fixed improper handling of IF_MODIFIED_SINCE header inside Five/browser/resource.py Changed: U Zope/branches/2.11/doc/CHANGES.txt U Zope/branches/2.11/lib/python/Products/Five/browser/resource.py What, no test? How do you know you got the speling right? And why use 'request.environ.get()' instead of the original OFS.Image spelling, 'request.get_header()'? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks8FS8ACgkQ+gerLs4ltQ5UewCgnwP21URcTj/AfX1tRl6vsKj2 cQIAn3oPGaIX4VOK8UIErPu8Hk9kHpLu =bAkx -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] SVN: Zope/branches/2.10/doc/CHANGES.txt - fixed improper usage of the IF_MODIFIED_SINCE header inside
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: Log message for revision 107357: - fixed improper usage of the IF_MODIFIED_SINCE header inside Five/browser/resource.py Changed: U Zope/branches/2.10/doc/CHANGES.txt -=- Modified: Zope/branches/2.10/doc/CHANGES.txt === --- Zope/branches/2.10/doc/CHANGES.txt2009-12-30 13:16:54 UTC (rev 107356) +++ Zope/branches/2.10/doc/CHANGES.txt2009-12-30 13:19:39 UTC (rev 107357) @@ -4,6 +4,14 @@ Change information for previous versions of Zope can be found in the file HISTORY.txt. + Zope 2.10.11 (unreleased) + +Bugs fixed + + - fixed improper usage of the IF_MODIFIED_SINCE header inside +Five/browser/resource.py + + Zope 2.10.10 (2009/12/22) No fix for this issue has landed yet on the 2.10 branch. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks8FtEACgkQ+gerLs4ltQ5LyQCeL/KfsJFy8yK8q3SNdGeqW8/9 6wgAoKnSPP4v455jXr5h/Xka8biA5C4I =HuBu -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] Where best to intercept a request to send a 304 response in Zope 2
Hi, A few of us are playing with some caching tools, trying to get to a more sane and less monkey patch-laden approach than CacheFu (Products.CacheSetup), for use with Zope 2.12. It is relatively easy to set response headers, e.g. in an IPubBeforeCommit event handler. However, we also need to be able to intercept a request to send a 304 response if the underlying object has not been modified. CacheFu monkey patches ZPT rendering to avoid the actual rendering if a 304 response is being sent, returning an empty string instead. I'd rather not have such patches, though, and anyway this only work with things rendered as ZPTs. It also doesn't avoid any pre-work that a view may do before rendering its template, if indeed it has one. Another thought was to use IPubAfterTraversal, at which point we have the object to publish and security checks have been completed. However, ZPublisher.Publish goes straight from that into mapply(). Can anyone think of a good way to do this? Maybe we need to add some kind of condition around mapply(), e.g. to do not nothing if there's a 304 response header, or some other marker? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] Top-level namespace package for Zope 2 ?
On Tue, Dec 29, 2009 at 6:51 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Dec 29, 2009 at 2:10 PM, Baiju M mba...@zeomega.com wrote: I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: zope.app.*, grokcore.*, repoze.bfg.* ? What would be the advantage of that? It'd break every single existing import. Most of those packages aren't reusable in the wild and shouldn't be released outside of the Zope2 distribution. The packages that we might want to break out (like we did with Acquistion, ExtensionClass, DateTime) should retain their name, so nobody has to change any code to work with them. I think we could have added those packages in a namespace. What if we want to extract similar things out of Zope 2 core. For example DTML related things could be extracted out of Zope 2 core. I guess we are planning to improve the WSGI story of Zope 2, in addition to creating new packages, we will be required to re-factor existing code for this. I hope these kind of refactoring would be much easier with namespace packages. One of the major contributing factor why we were able to create a nice ZTK out of Zope 3 is the use of namespace. There are few more important factors: - We should not clutter top-level names with Zope 2 specific packages This is very important in the context of new distribution mechanism we adopted (egg, PyPI). Courtesy to other PyPI users ? - Branding Zope technologies is also very important. Yes, Zope is still a good brand :) - Some of the things mentioned in this blog by Martin Aspelli: http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces PEP 20: Namespaces are one honking great idea -- let's do more of those! Regards, Baiju M ___ 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] Top-level namespace package for Zope 2 ?
Baiju M wrote: The packages that we might want to break out (like we did with Acquistion, ExtensionClass, DateTime) should retain their name, so nobody has to change any code to work with them. I think we could have added those packages in a namespace. Why? A million things depend on these with the names they have now. Inventing a new namespace for the sake of a new namespace and asking all those applications to change their code is to be obsessive-compulsive. What if we want to extract similar things out of Zope 2 core. For example DTML related things could be extracted out of Zope 2 core. I doubt there is much stuff there that anyone other than Zope 2 cares about. Even Acquisition and ExtensionClass are dubious. There's already a DTML implementation in zope.app somewhere. I guess we are planning to improve the WSGI story of Zope 2, in addition to creating new packages, we will be required to re-factor existing code for this. I hope these kind of refactoring would be much easier with namespace packages. One of the major contributing factor why we were able to create a nice ZTK out of Zope 3 is the use of namespace. Mmm... I doubt that. Any module path change is painful. The WSGI story exists in repoze.zope2 and just needs to be officially blessed if we want that. I don't see that this has anything to do with re-organising legacy code that's been there for nearly a decade. There are few more important factors: - We should not clutter top-level names with Zope 2 specific packages This is very important in the context of new distribution mechanism we adopted (egg, PyPI). Courtesy to other PyPI users ? I agree in general, but we are unlikely to have many new packages. Note that we can name eggs whatever we want, without using namespace packages. Yes, if someone wanted to use Zope 2's Acquisition in Django and Django had a module called Acquisition that would clash. If you find someone who wants to do that, or anything like it, slap them. They'll thank you later. - Branding Zope technologies is also very important. Yes, Zope is still a good brand :) We are doing that with dozens of zope.* packages. If we really are refactoring things out of Zope 2, they should go into existing/new zope.* packages. We don't need a new namespace. - Some of the things mentioned in this blog by Martin Aspelli: *cough* *Aspeli* *cough* :) http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces PEP 20: Namespaces are one honking great idea -- let's do more of those! They're not such a good idea that we should arbitrarily cause people pain just to have them. Zope 2 is very old. We have to accept that some things (like namespace packages or setuptools) just didn't exist when its architectural decisions were taken. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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.contenttype on PyPI is messed up
Can somebody please fix zope.contettype on PyPI? We had a 3.5.0 release, and somebody uploaded a 3.4.3 release which should have been 3.5.1. I don't have the rights for it. Best regards, Fabio ___ 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.contenttype on PyPI is messed up
On Thu, Dec 31, 2009 at 12:26 PM, Fabio Tranchitella kob...@kobold.it wrote: Can somebody please fix zope.contettype on PyPI? We had a 3.5.0 release, and somebody uploaded a 3.4.3 release which should have been 3.5.1. I don't have the rights for it. I just added kobold as owner. Regards, Baiju M ___ 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 )
