Re: [Zope3-dev] Re: Release process closure
On Wed, Oct 03, 2007 at 09:44:21PM +0200, Philipp von Weitershausen wrote: Jim Fulton wrote: I'd really like to get to closure on the current approved release process. Philipp, would you mind separating the release process into a separate file? Or do you mind if I do it? Done: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt Isn't step 4 redundant? I assume the changelog refers to CHANGES.txt in step 2: 2. Update the changelog to note the release date. Make sure the changelog is complete. ... 4. Fill in the release date in ``CHANGES.txt``. Step 6.3: python setup.py register sdist upload, should we assume that everyone will have a fixed version of setuptools installed, or should we recommend that people making the sdist on Windows system force the package format to tar.gz to avoid the unpleasantness with \r\n line endings in SOURCES.txt causing some files to not get extracted on POSIX systems? Purely formatting matter: the indentation of step 6 is inconsistent: 6. Get a separate checkout of the release tag for creating the distribution tarball and eggs. It is important that you don't do this on the trunk or release branch to avoid snip indented list here In the checkout of the tag perform the following steps: ... Also, there are two steps numbered 6: 6. Back on the trunk or the release branch, increase the version number in ``setup.py`` to the *next* release while preserving the ... Marius Gedminas -- Never attribute to malloc that which can be adequately explained by stupidity. -- From the .sig of [EMAIL PROTECTED] (Joerg Pommnitz) signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Known working sets II [was: Eggification redux]
On Thu, Sep 27, 2007 at 10:09:23AM -0400, Jim Fulton wrote: On Sep 26, 2007, at 8:22 PM, Tres Seaver wrote: ... I think that replacing 'index_url' with a gated community of packages is the only path to sanity here: the contract of the Cheeseshop (share new releases of all packages with everyone ASAP) is incompatible with our goals (ensure that users can install a given package and its dependencies, and have them work). Regretfully, I agree. People here at ZC are already moving in this direction internally. It works for Linux distros: they periodically take packages from upstream (which would be Cheeseshop in our case) into their unstable distribution, fix incompatibilities there, then freeze and release a stable package set downloadable from a fixed URL. End users can use a stable version if they want things to Just Work, or they can install one or two packages from unstable if they really need a newer version of something, and are prepared to fix any incompatibilities themselves. Marius Gedminas -- To express oneself In seventeen syllables Is very diffic -- John Cooper Clark. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Why do we restrict our egg testing?
On Thu, Sep 27, 2007 at 10:33:09AM -0400, Tres Seaver wrote: Why would we want to pull in all of Zope3 as a dependency (worse, a hidden one) before testing an egg? If the egg's dependencies are broken, I *want* the tests to fail. I don't think testing against a fat meta-egg satisfies that goal. Fix the egg so that its 'install_requires' or 'tests_requires' are sufficient to make the tests pass instead. There are two conflicting goals here: (1) testing that an egg's tests fail when its dependency list is incomplete (2) testing whether any of the other eggs that depend on this one break due to recent changes I thought Roger was one of the folks looking to *reduce* the set of dependencies his application had on zope3 coee -- testing against the meta-egg actually makes that problem worse. I think Roger wants (2). Marius Gedminas -- ...the only place for 63,000 bugs is a rain forest signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Automated egg releases
People make mistakes. Can we reduce the number/severity of those mistakes by creating a Python script to automate the release process as much as possible? Things like: - check that the version number in setup.py doesn't match an existing release in cheeseshop - check whether you have modified but not committed (or unversioned) files in the source tree - check that you've created a tag in subversion for this release (or, alternatively, offer to create the tag for you) - build an egg, install it locally in a temporary directory, then run the test suite to check for any missing files or whatever (a somewhat related idea would be to set up a buildbot to check for new zope-related egg releases and run their test suite in a sandbox, to notice breakages and email the guilty parties) - run the correct setup.py command to build/register/upload the egg to cheeseshop and/or www.zope.org I'd be happy to work on such a script during the sprint, if someone could help me figure out what exactly it should to do. Marius Gedminas -- If something has not yet gone wrong then it would ultimately have been beneficial for it to go wrong. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Automated egg releases
On Wed, Sep 26, 2007 at 04:19:35PM +0200, Philipp von Weitershausen wrote: Any other suggestions are highly welcome. That problem with building eggs on Windows: if you need to pass some argument to setup.py sdist to get a tar.gz egg, please update http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt because it currently says just | * Upload the package to PyPI with the following command:: | | python setup.py register sdist upload Marius Gedminas -- Added mysterious, undocumented --scanflags and --fuzzy options. -- nmap 3.0 announcement signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] faulty releases and pypi access [update]
On Wed, Sep 26, 2007 at 09:54:59AM -0400, Jim Fulton wrote: Sorry, I decided not to reply and hit the wrong button in my mailer. :) You were just applying explicit is better than implicit to email replies. :-) Marius Gedminas -- Just to be extra clear about this: yes, it is morally wrong for us to have written RetchMail, and it is morally wrong for you to use it. But try it, it's really fast! -- http://open.nit.ca/wiki/index.php?page=RetchMail signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
On Wed, Sep 26, 2007 at 11:16:46AM -0400, Tres Seaver wrote: Jim Fulton wrote: On Sep 26, 2007, at 10:42 AM, Stephan Richter wrote: On Wednesday 26 September 2007 10:40, Jim Fulton wrote: What about using CHANGES.txt, which we should be maintaining anyway? I agree with a change log. CHANGES.txt is difficult to get included in distributions. Having one requires a more complex setup.py. I'd rather recommend including a change log in README.txt. -1. I don't like that. We include CHANGES.txt via the long description; that's good enough for me. Do you think that the change log should be included in the distribution? +10. The cheeseshop metadata is not where I would expect to look for a changelog; having it readable there is only helpful *before* I've downloaded. FWIW, I think that both README.txt and CHANGES.txt should be package data, so that they are discoverable after installing an egg. The top-level README.txt should be boilerplate, and point to those files (the setup.py process can then stitch them all todgether). Example from Debian: all packages have a /usr/share/doc/$packagename with the changelog and readme in there, and this is a Very Good Thing. +1 for CHANGES.txt (or NEWS.txt) in a separate file from README.txt +1 for the latest changelog entries visible on the cheeseshop page (see an announcement, go to cheeseshop, see whether you want to upgrade or not) +1 for README.txt and CHANGES.txt available to you after you install an egg. Marius Gedminas -- Despite all appearances, your boss is a thinking, feeling, human being. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Automated egg releases
On Wed, Sep 26, 2007 at 05:19:45PM +0200, Martijn Faassen wrote: Stephan Richter wrote: [snip] Doing another checkout of the tag will create a significant overhead to the release process of a package. I'd like to highlight this. We need to be careful we don't increase release overhead too much, otherwise it won't happen/people will make mistakes. Reducing overhead is why I proposed an automated tool. To put it in perspective, I believe the proper sequence of things is 1. keep doing stuff so you learn (from mistakes and whatnot) what needs to be done 2. document the process because (1) you'll forget what you learned, and (2) other people won't know what you learned 3. automate, because following a long process by hand is boring, and bored people make mistakes. Marius Gedminas -- I would suggest re-naming rmbdd(). I _assume_ that dd stands for data dependent, but quite frankly, rmbdd looks like the standard IBM we lost every vowel ever invented kind of assembly lanaguage to me. -- Linus Torvalds signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Re-normalizers instead of ellipses in doctests [was: some checkin]
On Wed, Sep 26, 2007 at 11:52:42PM +0200, Philipp von Weitershausen wrote: Marius Gedminas wrote: Log message for revision 80145: Make the test pass on both Python 2.4 and 2.5. ... -=- Modified: z3c.form/trunk/src/z3c/form/action.txt === --- z3c.form/trunk/src/z3c/form/action.txt 2007-09-26 21:26:25 UTC (rev 80144) +++ z3c.form/trunk/src/z3c/form/action.txt 2007-09-26 21:49:09 UTC (rev 80145) @@ -236,4 +236,5 @@ ActionErrorOccurred for Action 'cancel' u'Cancel' eventlog[-1].error - ActionExecutionError wrapping zope.interface.exceptions.Invalid ... + ActionExecutionError wrapping ...Invalid... + It's too bad that Exception's __repr__ changed in Python 2.5. Actually I like the new __repr__ better. The reason is that it's a new-style class now, which is actually a benefit at the same time. Anyway, these ellipses are very ugly and confusing. I disagree. I think they're okay-ish when you know exactly what they're supposed to stand for. In this case we can definitely do better. When Nikhil N made all of zope.*'s tests pass on Python 2.5, he did a good job of using re-normalizers. I very much suggest doing the same thing here. I see you use a re-normalizer already for some messages, so I won't have to show you how to use it :). I actually tried using renormalizers for this, and hit a brick wall very soon. Renormalizers are ugly, confusing and essentially undebuggable. Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. — Jamie Zawinski Marius Gedminas -- We're sysadmins. To us, data is a protocol-overhead. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation
On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote: Why does the caller care? She just wants an object which will provide the 'IFoo' contract on behalf of the passed context. If 'x' is capable of providing 'IFoo' without help, then failing (or worse, returning a less-specific factory result) when calling 'getAdapter' is the Wrong Thing (a least surprise violation, if nothing else). FWIW it was a big surprise to me when I discovered that IFoo(x) has different semantics from getAdapter(x, IFoo). Marius Gedminas -- C is for Cookies. Perl is even better for Cookies. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.sendmail having dependency on zope.app.comonent
On Fri, Aug 31, 2007 at 01:21:08PM +0200, Christian Theune wrote: Am Freitag, den 31.08.2007, 13:06 +0200 schrieb Wichert Akkerman: Is there documentation on sources anywhere? The last time I checked there was nothing that I could understand either in zope.* or on the wiki. It took me a while to understand them myself. Especially as there is some code in there that is basically not useful. I'll try to give a very short overview: How do you feel about adding it to the top of zope/schema/sources.txt? Marius Gedminas -- We don't care. We don't have to. We're the Phone Company. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] doctest prb again
On Fri, Jul 20, 2007 at 10:09:18AM +0200, Adam Groszer wrote:
Hello,
How to solve the \r\n and \n mismatch between win32 and *nix in the
doctests?
doctest is:
ctrl.value
'Text inside\narea!\n '
fails with (on win32):
Failed example:
ctrl.value
Expected:
'Text inside\narea!\n '
Got:
' Text inside\r\n area!\r\n'
ctrl.value comes from a html file in zope.testbrowser.ftests
You could do
ctrl.value.replace('\r', '')
or strip the \r's in the place where you're reading that html file.
Marius Gedminas
--
This host is a black hole at HTTP wavelengths. GETs go in, and nothing
comes out, not even Hawking radiation.
-- Graaagh the Mighty on rec.games.roguelike.angband
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] help with doctests
On Fri, Jul 20, 2007 at 09:48:52AM +0200, Adam Groszer wrote:
Hello,
In z.a.apidoc.browser.README.txt I can write
browser.open('http://localhost/++apidoc++/non-existent/')
Traceback (most recent call last):
...
httperror_seek_wrapper: HTTP Error 404: Not Found
(test passes)
but I can't write
browser.open('http://localhost/++apidoc++/non-existent/')
Traceback (most recent call last):
...
...HTTP Error 404: Not Found
it throws:
Failed example:
browser.open('http://localhost/++apidoc++/non-existent/')
Exception raised:
Traceback (most recent call last):
File U:\zope\svn_zope34\src\zope\testing\doctest.py, line 1348, in
__run
compileflags, 1) in test.globs
File doctest README.txt[3], line 1, in ?
browser.open('http://localhost/++apidoc++/non-existent/')
File U:\zope\svn_zope34\src\zope\testbrowser\browser.py, line 224, in
open
self.mech_browser.open(url, data)
File U:\zope\svn_zope34\src\mechanize\_mechanize.py, line 203, in open
return self._mech_open(url, data)
File U:\zope\svn_zope34\src\mechanize\_mechanize.py, line 254, in
_mech_open
raise response
httperror_seek_wrapper: HTTP Error 404: Not Found
what do I miss?
doctests have special rules for exceptions that are different from the
rules of normal output matching.
If a statement raises an exception, the output part must be of the form
Traceback (most recent call last):
...
exception type: exception value
You can use ellipsis in the exception value part, IIRC.
Marius Gedminas
--
HOST SYSTEM NOT RESPONDING, PROBABLY DOWN. DO YOU WANT TO WAIT? (Y/N)
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: help with doctests
On Fri, Jul 20, 2007 at 07:57:12AM -0400, Jim Fulton wrote: On Jul 20, 2007, at 5:27 AM, Philipp von Weitershausen wrote: I suggesting using the regex-normalizer [1]. There are many packages out there that use it if you're looking for examples. http://svn.zope.org/zope.testing/trunk/src/zope/testing/renormalizing.py?rev=66267view=auto BTW, a small useful easy project that I don't have time for would be to generalize the renormalizer to allow other objects besides regexes. It already does, in a way. It doesn't call re.compile by itself, so you can pass it anything that implements a ``sub`` method, not necessarily regexes. class LowercaseTransformer(object): def sub(replacement, text): return text.lower() checker = RENormalizing([(LowercaseTransformer(), None)]) You now give this a sequences of regex/replacement pairs. It would be nice to allow callables in addition to regexs. Basically, allow items in the sequence to be either: - a regex+replacement tuple, or - a callable transformer that reads the text and returns new text. So essentially you want nicer syntax for the above. Should be easy to do: Index: renormalizing.py === --- renormalizing.py(revision 78151) +++ renormalizing.py(working copy) @@ -181,15 +181,21 @@ class RENormalizing(doctest.OutputChecke def __init__(self, patterns): -self.patterns = patterns +self.transformers = map(self._cook, patterns) + +def _cook(self, pattern): +if callable(pattern): +return pattern +regexp, replacement = pattern +return lambda text: regexp.sub(replacement, text) def check_output(self, want, got, optionflags): if got == want: return True -for pattern, repl in self.patterns: -want = pattern.sub(repl, want) -got = pattern.sub(repl, got) +for transformer in self.transformers: +want = transformer(want) +got = transformer(got) return doctest.OutputChecker.check_output(self, want, got, optionflags) @@ -208,9 +214,9 @@ class RENormalizing(doctest.OutputChecke # Dang, this isn't as easy to override as we might wish original = want -for pattern, repl in self.patterns: -want = pattern.sub(repl, want) -got = pattern.sub(repl, got) +for transformer in self.transformers: +want = transformer(want) +got = transformer(got) # temporarily hack example with normalized want: example.want = want Do you want me to write unit tests for this and commit? Marius Gedminas -- C is quirky, flawed, and an enormous success. -- Dennis M. Ritchie signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: doctest prb again
On Fri, Jul 20, 2007 at 11:30:08AM +0200, Philipp von Weitershausen wrote: Adam Groszer wrote: Great, that works ;-) Thought that there is some more genreic-sane way. There is. NORMALIZE_WHITESPACE actually only helps when whatever you're outputting actually prints whitespace. Doing this:: ' ' ' ' won't invoke the whitespace normalizer. I'm pretty certain you're mistaken here: import doctest def test1(): ... ... ' ' # doctest: +NORMALIZE_WHITESPACE ... ' ' ... ... doctest.testmod() (0, 1) The test passes. What wouldn't work, though, is if you tried to match whitespace that is not expressed as whitespace in your test, e.g. tabs: def test2(): ... r ... '\t\t ' # doctest: +NORMALIZE_WHITESPACE ... '\t' ... ... doctest.testmod() ** File /home/mg/.python, line 25, in __main__.test2 Failed example: '\t\t' # doctest: +NORMALIZE_WHITESPACE Expected: '\t' Got: '\t\t' ** 1 items had failures: 1 of 1 in __main__.test2 ***Test Failed*** 1 failures. *** DocTestRunner.merge: '__main__.test1' in both testers; summing outcomes. *** DocTestRunner.merge: '__main__' in both testers; summing outcomes. (1, 2) Marius Gedminas -- America and England are two countries separated by a common language. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Sun, Jul 15, 2007 at 08:34:43AM -0400, Stephan Richter wrote:
On Saturday 14 July 2007 04:24, Marius Gedminas wrote:
- API documentation: human readability is the primary concern, doctests
are in there just to make sure the documentation stays up to date.
These are .txt files.
I disagree.
Perhaps not. ;)
API reference should be automatically created.
Yes, absolutely, with something like pydoc/epydoc/pydoctor.
I was talking about regular programmer-facing documentation and couldn't
find a good word for it (tutorial? programmer's guide). The thing you
read to learn about the package, not the thing you use to look up some
details of some function.
Text files are
there to explain the API to someone who wants to use it. I write text files
like I would write a lab report or a book on the subject.
- Short usage examples: sometimes it's simpler to show an example than
to describe the function in words:
def parse_date(date_string):
Parses an ISO-8601 date.
parse_date('2007-07-14')
datetime.date(2007, 7, 14)
I have not done this, because most interesting functions/methods are not that
simple.
Yes, these are very rarely applicable in my experience. Low-level
universal utility functions, mainly, not application business logic.
Also, I really enjoy not having long documentation strings in the
code anymore.
That's great, I completely agree.
That's a huge win coming from interfaces, in my opinion.
I wish pydoc knew about zope interfaces...
- Unit tests: there are many of those, they're independent (thus a
single .txt for a collection of tests is a Bad Idea), they're short
(so understanding and debugging is easy) and expressive. I put
those into .py files full with functions that look like
def doctest_FooClass_does_this():
Test that FooClass is able to ...
foo = FooClass()
results = foo.do_this()
for fruit, score, comments in results:
... print fruit.ljust(10), '|', score.ljust(5), '|',
comments Orange | 9 | Tastes good, a bit sour
Apple | 8 | Varies
I never do this anymore. If I have a collection of utility functions, I Still
put them in a text file, because text files allow me to concentrate on
documentation.
Perhaps I did not get my point clearly accross. Python modules with
doctests are useful for testing the various corner cases that you did
not test in the corresponding .txt file.
If you put the tests for all your corner cases into the documentation,
it quickly becomes unreadable.
In you example above, for example, I miss a lot of explanatory
text.
I was trying to keep the email short. I usually have a sentence
explaining each set short sequence of doctest assertions that do
something and then inspect the result.
When I have utility functions that I want to explain independently,
then I simply create one section/chapter per function.
Right, but test_foo.py is never about documentation, it's about isolated
unit tests.
Marius Gedminas
--
I noticed that Open Source proponents using MacOS X have developed highly tuned
excuses, similar to those that smokers have about why cigarettes are good for
you.
-- Miguel de Icaza,
http://primates.ximian.com/~miguel/archive/2004/Aug-03.html
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Sun, Jul 15, 2007 at 10:44:35AM -0400, Benji York wrote: I'm doing some work with doctest right now, and am considering how to make assertions about HTML/XML better. Fixing https://bugs.launchpad.net/zope3/+bug/126169 would make my life easier. Marius Gedminas -- Microsoft -- because God hates us. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Fri, Jul 13, 2007 at 02:03:04PM -0400, Jim Fulton wrote: Of course, I'm a big fan of doctest. Not all tests are documentation though, even if they are written as doctest. I'm happy with what we've done. We're making good incremental progress. I think though that many of our doctests that aspire to be documentation are actually not good documentation. IMO, we need to separate tests into 2 classes: executable documentation and tests. +infinity Absolutely! Trying to reach two unrelated goals (comprehensive tests + human-friendly documentation) with one file is just too hard, if not impossible. The executable documentation needs to be **much more readable than it is now**. FWIW, here's a very good example of executable documentation: https://storm.canonical.com/Tutorial Marius Gedminas -- We have enough youth, how about a fountain of SMART? signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Fri, Jul 13, 2007 at 11:09:30PM +0200, Wichert Akkerman wrote:
Previously Tres Seaver wrote:
Stephan Richter wrote:
I think in the long term it will be most beneficial, if we convert all
tests
to doctests; then a reasonable on-line documentation is not that hard to
provide.
- -1. Good tests don't always make good documentation; I prefer the
isolation of traditional unittests for anything other than main line
use cases, for which doctests are best suited.
Amen. I find failing doctests to be much harder to debug as well. I use
doctests as a method to make sure examples in my documentation are
correct, which is very useful.
Doctests are hard to get right. I've finally settled on classifying my
tests into four categories and using different styles for them:
- API documentation: human readability is the primary concern, doctests
are in there just to make sure the documentation stays up to date.
These are .txt files.
- Short usage examples: sometimes it's simpler to show an example than
to describe the function in words:
def parse_date(date_string):
Parses an ISO-8601 date.
parse_date('2007-07-14')
datetime.date(2007, 7, 14)
This is the only case when I allow doctests in code modules.
Putting long test suites in class/function docstrings clutters the
code and makes it harder to read.
- Unit tests: there are many of those, they're independent (thus a
single .txt for a collection of tests is a Bad Idea), they're short
(so understanding and debugging is easy) and expressive. I put
those into .py files full with functions that look like
def doctest_FooClass_does_this():
Test that FooClass is able to ...
foo = FooClass()
results = foo.do_this()
for fruit, score, comments in results:
... print fruit.ljust(10), '|', score.ljust(5), '|',
comments
Orange | 9 | Tastes good, a bit sour
Apple | 8 | Varies
and have a traditional test_suite() function at the end that returns
a DocTestSuite with the appropriate setUp/tearDown/optionflags.
In effect this is a more or less direct translation of the
traditional unittest tests. I find that rewriting the assertions
into doctest format helps me make the tests more readable. Compare
the above with
class TestFooClass(unittest.TestCase):
def test_does_this(self):
foo = FooClass()
results = foo.do_this()
self.assertEquals(results,
[('Orange', 9, 'Tastes good, a bit sour'),
('Apple', 8, 'Varies')])
and especially compare the output you get when the test fails.
- Functional tests: these are .txt files that use zope.testbrowser and
are the hardest to debug. There ought to be a better way to make
assertions about HTML output than using ELLIPSIS and then pulling
your hair out looking at huge and incomprehensible diffs.
Digression: syntax highlighting the diffs helps immensely.
Check out http://svn.zope.org/zope.testing/branches/colorized-output/
Another digression: this is why I want Zope 3 to run on Python 2.5.
I want to make XPath queries on the HTML, and I hope I'll be
able to do that with cElementTree.
Marius Gedminas
--
Added mysterious, undocumented --scanflags and --fuzzy options.
-- nmap 3.0 announcement
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Sat, Jul 14, 2007 at 11:24:36AM +0300, Marius Gedminas wrote: Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ A picture is better than five hundred lines of code: http://mg.pov.lt/blog/europython-2007-sprints-2.html Marius Gedminas -- An algorithm must be seen to be believed. -- D.E. Knuth signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
On Sat, Jul 14, 2007 at 03:30:22PM -0400, Benji York wrote: Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ I'm very much looking forward to that branch being merged to the trunk. Merged. I have a feature suggestion: it would be nice to have a switch to say colorize output, unless stdout isn't a terminal, so piping the output to a pager (or file) doesn't result in polluted output. There's a little complication: when you have test layers that don't support tearDown, some of the tests are run in a subprocess, where stdout isn't a terminal (it's a pipe), but all the output will be copied verbatim to the stdout of the parent process (which may or may not be a terminal). It's not that hard to remove the -c flag when you're adding |less to the command line. Or you could use |less -R and have colourful and scrollable output. Marius Gedminas -- Nothing ever goes missing that they don't look at me, ever since that time I lost my horse. As if that could be helped. He was white and it was snowing, what did they expect? -- Dolorous Edd in A Storm of Swords by George R. R. Martin signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.session/zope.minmax
On Wed, Jul 11, 2007 at 02:13:46PM -0400, Tres Seaver wrote: Fred Drake wrote: On 7/11/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Right, I made the same assumption: the eggs have been set free, Right. No need to hold all the developers hostage to a release model we've been working to get away from. Please don't discount the risks such an escape entails: in particular, the balkanization of the source tree creates both technical risks (developers in one of the satellites may not pay enough heed to the needs of their dependents), and branding risks (the known good / quality management issue). This sounds like the job that Linux distributions are doing: taking multiple packages that depend on each other in arbitrary ways, integrating them and releasing the whole after it's been tested and seen to work together. Marius Gedminas -- Anyone can do any amount of work provided it isn't the work he is supposed to be doing at the moment. -- Robert Benchley signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] namechooser : object deleted instead of being renamed
On Mon, Jun 18, 2007 at 07:22:20PM +0300, Marius Gedminas wrote: On Mon, Jun 18, 2007 at 12:20:57PM +0200, Christophe Combelles wrote: Hi, I've experienced a dangerous behaviour with namechoosers : If the namechooser computes a name which is the same as the current name, the object is deleted! This is simple to reproduce : - register a name chooser that only returns foobar - create your object → ok it's name is foobar - from the Contents view of it's container, try to rename it (with a different name) - → deleted Someone should try to reproduce that, to be sure that's not a side effect of my app, but I don't think so. I can reproduce it with a unit test: I've added this to the bug tracker so it doesn't get lost: https://bugs.launchpad.net/zope3/+bug/123532 Marius Gedminas -- Ambition is a poor excuse for not having enough sense to be lazy. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] namechooser : object deleted instead of being renamed
On Mon, Jun 18, 2007 at 12:20:57PM +0200, Christophe Combelles wrote:
Hi,
I've experienced a dangerous behaviour with namechoosers :
If the namechooser computes a name which is the same as the current name,
the object is deleted!
This is simple to reproduce :
- register a name chooser that only returns foobar
- create your object → ok it's name is foobar
- from the Contents view of it's container, try to rename it (with a
different name)
- → deleted
Someone should try to reproduce that, to be sure that's not a side effect
of my app, but I don't think so.
I can reproduce it with a unit test:
[EMAIL PROTECTED]:~/src/Zope3 $ ./test.py -pv -s zope.copypastemove
Running tests at level 1
Running unit tests:
Running:
46/46 (100.0%) doctest_renaming_with_obstinate_name_chooser
(zope.copypastemove.tests.test_rename)
Failure in test doctest_renaming_with_obstinate_name_chooser
(zope.copypastemove.tests.test_rename)
Failed doctest test for
zope.copypastemove.tests.test_rename.doctest_renaming_with_obstinate_name_chooser
File /home/mg/src/Zope3/src/zope/copypastemove/tests/test_rename.py, line
32, in doctest_renaming_with_obstinate_name_chooser
--
File /home/mg/src/Zope3/src/zope/copypastemove/tests/test_rename.py, line 67,
in
zope.copypastemove.tests.test_rename.doctest_renaming_with_obstinate_name_chooser
Failed example:
list(container)
Expected:
[u'foobar']
Got:
[]
Ran 46 tests with 1 failures and 0 errors in 0.081 seconds.
Here's the test I added:
Index: src/zope/copypastemove/tests/test_rename.py
===
--- src/zope/copypastemove/tests/test_rename.py (revision 76767)
+++ src/zope/copypastemove/tests/test_rename.py (working copy)
@@ -28,10 +28,55 @@
eventtesting.setUp()
container_setup.setUp()
+
+def doctest_renaming_with_obstinate_name_chooser():
+Test ObjectMover when the name chooser returns the same name
+
+This is a regression test for a bug reported by Christophe Combelles
+
+Setup: register the IObjectMover adapter
+
+ from zope.copypastemove import ContainerItemRenamer, ObjectMover
+ from zope.component import adapts, provideAdapter
+ provideAdapter(ObjectMover)
+
+Suppose you have a NameChooser that always chooses the same name
+
+ from zope.app.container.sample import SampleContainer
+ class MyContainer(SampleContainer):
+... pass
+ from zope.app.container.contained import NameChooser
+ class ObstinateNameChooser(NameChooser):
+... adapts(MyContainer)
+... def chooseName(self, name, object):
+... return u'foobar'
+ provideAdapter(ObstinateNameChooser)
+
+Let's add an object to a container
+
+ from zope.app.container.contained import Contained
+ container = MyContainer()
+ container[u'foobar'] = Contained()
+
+Try to rename it
+
+ ContainerItemRenamer(container).renameItem(u'foobar', u'newname')
+
+The rename did not succeed, because the name chooser did not allow it:
+
+ list(container)
+[u'foobar']
+
+There was a bug once: in this particular case the object mover adapter
+would remove the item altogether.
+
+
+
def test_suite():
return unittest.TestSuite((
DocTestSuite('zope.copypastemove',
setUp=setUp, tearDown=testing.tearDown),
+DocTestSuite(setUp=setUp, tearDown=testing.tearDown),
))
if __name__=='__main__':
Marius Gedminas
--
If nothing else helps, read the documentation.
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] DoS problem in zope.sendmail.maildir
On Thu, Jun 07, 2007 at 12:52:43PM +0200, Sascha Ottolski wrote: Am Mittwoch 06 Juni 2007 schrieb Marius Gedminas: I'm attaching the patch here. I'd be happy to commit it to trunk if somebody else could test it on various platforms. (I haven't even tested if it works fine on Linux, other than by running the unit tests.) Marius, again, thanks a lot for the patch. I can confirm that it works fine here. I also checked that e.errno == errno.EEXIST is True on Windows XP. Thanks. Fix committed in rev 76463. Marius Gedminas -- Of course everyone knows that vim is the best text editor in the world. Anyone who tells you differently is either wrong, lying, or criminally insane. (Or an emacs user, in which case they are wrong, lying and criminally insane). signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] DoS problem in zope.sendmail.maildir
Hi,
On Wed, Jun 06, 2007 at 06:04:50PM +0200, Sascha Ottolski wrote:
I discovered a problem with the maildir implementation, that is
triggered when trying to use the QueuedDelivery with many (read: more
than current filedescriptor limit of the zope process) mails at once:
...
OSError: [Errno 24] Too many open files:
'/home/so/sandbox/var/zope/lib/python/lalisio/app/site/../../../../var/zope/var/mqueue/new'
Oh, wow. I'd forgotted that this causes the data manager to keep an
open file descriptor for every email. Ouch.
Suggestion: introduce IMaildirMessageWriter.close() and call it in
QueuedMailDelivery.createDataManager.
I need to kill -9 the server after that, SIGTERM seems to be ignored.
Ouch.
The reason for that to happen is clear to me, however, I'm not sure how
a fix could look like.
Did you create an bug in launchpad? I could attach a patch that I think
would fix the problem, but I don't currently have the time and energy to
test myself.
One source of the problem is
try:
fd = os.open(filename, os.O_CREAT|os.O_EXCL|os.O_WRONLY, 0600)
except OSError:
# File exists
OSError is obviously to broad to catch as a test if the unique filename
could be created. May be use os.path.exists(filename) instead? But I'm
not sure if this is equivalent in a platform independant way.
That solution would have a race condition. Better
try:
fd = os.open(filename, os.O_CREAT|os.O_EXCL|os.O_WRONLY, 0600)
except OSError, e:
import errno # actually put this at the very top
if e.errno != errno.EEXIST:
raise
# File exists
but would it work on Windows? Could anyone test that by running this
little program on Windows:
import os, errno
file('tempfile', 'w').close()
try:
fd = os.open('tempfile', os.O_CREAT|os.O_EXCL|os.O_WRONLY, 0600)
except OSError, e:
print e.errno == errno.EEXIST # prints True on Linux
The real source of the problem lies in the MaildirMessageWriter: The
passed-in filedescriptor remains open until commit() is called. No
problem for sending some mails only, but when sending lots of
messages in one transaction, the filedescriptor limit kicks in.
It's scary to see the problems in zope.sendmail, given that I'm
at least partially responsible for all of them.
A dirty solution might be to change the write() and writeline() to open
and close the file on every call. But there's probably a saner way.
Yes.
BTW, I'm wondering if it is really safe to assume that
os.rename(self._filename, self._new_filename) in the commit() message
never fails?
Nothing is really safe. Renaming a file is much safer than creating a
file.
Although I believe that it's almost impossible that it
really could :-)
Sudden filesystem corruption, the kernel remounts it as read-only, and
you cannot rename anything. But then you have bigger problems than an
exception in the second phase of a commit.
Marius Gedminas
--
For Sale: Parachute. Only used once, never opened, small stain.
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] DoS problem in zope.sendmail.maildir
On Thu, Jun 07, 2007 at 12:36:25AM +0300, Marius Gedminas wrote:
On Wed, Jun 06, 2007 at 06:04:50PM +0200, Sascha Ottolski wrote:
I discovered a problem with the maildir implementation, that is
triggered when trying to use the QueuedDelivery with many (read: more
than current filedescriptor limit of the zope process) mails at once:
...
OSError: [Errno 24] Too many open files:
'/home/so/sandbox/var/zope/lib/python/lalisio/app/site/../../../../var/zope/var/mqueue/new'
...
The reason for that to happen is clear to me, however, I'm not sure how
a fix could look like.
Did you create an bug in launchpad? I could attach a patch that I think
would fix the problem, but I don't currently have the time and energy to
test myself.
I'm attaching the patch here. I'd be happy to commit it to trunk if
somebody else could test it on various platforms. (I haven't even
tested if it works fine on Linux, other than by running the unit tests.)
Marius Gedminas
--
(mental note: stop installing red hat. everytime i do so, it takes ages to fix
my system again.)
-- from the sig of Martin H�gman
Make QueuedMailDelivery not keep open files around for every message sent
during a transaction.
Patch by Marius Gedminas [EMAIL PROTECTED]
Index: tests/test_maildir.py
===
--- tests/test_maildir.py (revision 75881)
+++ tests/test_maildir.py (working copy)
@@ -19,6 +19,7 @@
import unittest
import stat
import os
+import errno
from zope.interface.verify import verifyObject
@@ -123,7 +124,7 @@
def open(self, filename, flags, mode=0777):
if (flags os.O_EXCL and flags os.O_CREAT
and self.access(filename, 0)):
-raise OSError('file already exists')
+raise OSError(errno.EEXIST, 'file already exists')
if not flags os.O_CREAT and not self.access(filename, 0):
raise OSError('file not found')
fd = max(self._descriptors.keys() + [2]) + 1
Index: tests/test_delivery.py
===
--- tests/test_delivery.py (revision 75881)
+++ tests/test_delivery.py (working copy)
@@ -147,18 +147,32 @@
data = ''
commited_messages = [] # this list is shared among all instances
aborted_messages = [] # this one too
+_closed = False
def write(self, str):
+if self._closed:
+raise AssertionError('already closed')
self.data += str
def writelines(self, seq):
+if self._closed:
+raise AssertionError('already closed')
self.data += ''.join(seq)
+def close(self):
+self._closed = True
+
def commit(self):
+if not self._closed:
+raise AssertionError('for this test we want the message explicitly'
+ ' closed before it is committed')
self._commited = True
self.commited_messages.append(self.data)
def abort(self):
+if not self._closed:
+raise AssertionError('for this test we want the message explicitly'
+ ' closed before it is committed')
self._aborted = True
self.aborted_messages.append(self.data)
Index: maildir.py
===
--- maildir.py (revision 75881)
+++ maildir.py (working copy)
@@ -18,6 +18,7 @@
__docformat__ = 'restructuredtext'
import os
+import errno
import socket
import time
import random
@@ -91,7 +92,9 @@
filename = join(subdir_tmp, unique)
try:
fd = os.open(filename, os.O_CREAT|os.O_EXCL|os.O_WRONLY, 0600)
-except OSError:
+except OSError, e:
+if e.errno != errno.EEXIST:
+raise
# File exists
counter += 1
if counter = 1000:
@@ -115,7 +118,7 @@
self._filename = filename
self._new_filename = new_filename
self._fd = fd
-self._closed = False
+self._finished = False
self._aborted = False
def write(self, data):
@@ -124,22 +127,28 @@
def writelines(self, lines):
self._fd.writelines(lines)
+def close(self):
+self._fd.close()
+
def commit(self):
-if self._closed and self._aborted:
+if self._aborted:
raise RuntimeError('Cannot commit, message already aborted')
-elif not self._closed:
-self._closed = True
-self._aborted = False
+elif not self._finished:
+self._finished = True
self._fd.close()
os.rename(self._filename, self._new_filename)
# NOTE: the same maildir.html says it should be a link, followed by
# unlink. But Win32 does not necessarily have hardlinks!
def abort(self):
-if not self._closed:
-self
Re: [Zope3-dev] Re: [Checkins] SVN: z3c.form/trunk/src/z3c/form/ HTML element ids containing dots are not very good, because then the
On Sun, Jun 03, 2007 at 02:18:47PM -0400, Gary Poster wrote: On Jun 3, 2007, at 12:58 PM, Stephan Richter wrote: Log message for revision 76258: HTML element ids containing dots are not very good, because then the element#id CSS selector does not work FYI it works just fine (at least in Firefox) if you escape the dots: element#id\.with\.dots I'm pretty sure it works in MSIE6 as well, but don't quote me on that. Marius Gedminas -- When I'm not in my right mind, my left mind gets a little crowded. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Launchpad Bug Emails
On Tue, May 15, 2007 at 11:15:24AM -0400, Benji York wrote: Philipp von Weitershausen wrote: A quick check revealed that you don't appear to be a team member. I would've changed that except that Launchpad seems to know two Benji Yorks :/. Yeah, I signed up with my personal email before we started using Launchpad for Zope 3 and then later signed up with my work email not remembering the other account. Launchpad lets you merge user accounts: https://launchpad.net/people/+requestmerge Marius Gedminas -- 1 + 1 = 3 -- from a Microsoft advertisement signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Cleaning up dependencies for Zope 3.4 eggs
On Thu, Apr 05, 2007 at 10:23:44AM -0400, Stephan Richter wrote: On Thursday 05 April 2007 09:08, Christian Theune wrote: we're starting work on an application that we're going to use Zope 3.4 for and that I'd like to base on the eggs. That should give me the chance to clean up some of the egg dependencies. Yeah, I wanted to look into some dependencies too, since I noticed that zope.pagetemplate will pull in pretty much all of Zope. I think what we need is a tool that draws us a dependency graph. Is there something out there already, at least for creating the dependency graph text version? Since all dependencies are specified as an argument to the setup function, I would not immediately know how to extract that information, except than monkey patching into it. I have a half-baked tool that analyzes Python module dependencies by parsing import statements. It was not as useful as I hoped, as the graphs produced from SchoolTool sources were big and unwieldy. Marius Gedminas -- This company has performed an illegal operation and will be shut down. If the problem persists, contact your vendor or appeal to a higher court. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] bit puzzled with directDelivery+smtpMailer
Hi, On Thu, Mar 29, 2007 at 01:31:12PM +0200, Adam Groszer wrote: I'm trying to catch somehow the exception that's coming when the SMTP server IP address is misconfigured or the SMTP server is not responding. My problem is that the sending works using the transaction manager. That means the exception comes after File U:\zope\svn_zope33\src\zope\publisher\publish.py, line 138, in publish publication.afterCall(request, obj) File U:\zope\svn_zope33\src\zope\app\publication\browser.py, line 78, in afterCall super(BrowserPublication, self).afterCall(request, ob) File U:\zope\svn_zope33\src\zope\app\publication\zopepublication.py, line 167, in afterCall txn.commit() That means I don't have a big chance to catch it in my app. That's a feature. You don't want to send emails about changes made in transactions that were later aborted. In particular, when you encounter ZODB ConflictErrors a couple of times, you don't want three copies of the same email to be sent. Unfortunately, that means the actual sending must be done in the second phase of the two-phase commit, and it is not supposed to ever fail at that point. That makes directDelivery unsuitable for production use. Using queuedDelivery might be a solution, but I still don't have too many chances to give feedback of the error. There is a IMailErrorEvent, and IMailSentEvent but they don't seem to be used. Ouch. I do not remember why the events were never fully implemented. Obviously they would be fired in the middle of tpc_finish. Sending events is the same as running arbitrary code. That's a bad thing to do during transaction commit. There was some discussion (years ago) that the transaction mechanism should acquire a way to register some callback for code that should be run in a new transaction, after the current one is committed. I do not remember how that discussion ended. Any ideas, pointers? zope.sendmail could use some loving care and attention. For example, the queued delivery thread will loop forever trying to deliver a message with an ill-formed recipient address once every three seconds. In the meantime, this seems to work adequately: use queuedDelivery, and send a test message after depoying the application. If it doesn't come through, check the error logs. Note also that if the nearest SMTP server accepts an email, that does not guarantee delivery. We've hooked up incoming mail to a bounce message processor in one of our Zope 3 apps that matches message IDs in bounce messages with IDs of sent emails and can take appropriate action. Marius Gedminas -- I would suggest re-naming rmbdd(). I _assume_ that dd stands for data dependent, but quite frankly, rmbdd looks like the standard IBM we lost every vowel ever invented kind of assembly lanaguage to me. -- Linus Torvalds signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why is the testrunner running with the --profile option ?
On Wed, Feb 28, 2007 at 10:33:34AM +0100, Michael Haubenwallner wrote: Why is the testrunner running with the --profile option ? It is not, but it tries to import the profiler anyway. I did not set it. I understand that profiling should be disabled if hotshot cannot be imported. That seems to be a good idea. Running (from a svn checkout) python test.py -s zope.anypackage gets me that error: ImportError: No module named profile please install the python2.4-profiler package Any ideas ? Alternatives: 1) install the python2.4-profiler package. 2) write a patch for zope/testing/testrunner.py to be able to run the tests when the profiler is not available 3) file a bug in the collector and wait for somebody else to implement step (2) Marius Gedminas -- Key emulation: [ ] Intuitive [*] Emacs(Seen in an MCEdit dialog) signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.cachedescriptors outdated
On Sat, Feb 24, 2007 at 09:59:16PM +0100, Philipp von Weitershausen wrote: Jeff Shell wrote: With `readproperty`, you can still have the simple getter-method-wrapper property, with the ability to replace the value on instances. So no, the builtin 'property' descriptor is not fine. `property` came into being when Python got descriptors, but before it got decorators. By grand design or divine accident, Clearly Guido's time machine is to blame here :) the fact that the first argument for `property` is the getter function makes it a useful decorator. But it wasn't written with decorators in mind. It was written for ``x = property(getX, setX, delX)``, or some combination thereof. I once mused about this and came up with rwproperty (a decorator spelling for getters *and* setters, del'ers) rwproperty is incredibly cool. I'd love to see it in the Python standard library. Marius Gedminas -- This is an object-oriented system. If we change anything, the users object. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] development checkout
On Thu, Feb 01, 2007 at 08:59:00AM +, Chris Withers wrote: It's been way too long since I did that, but how do I go about getting an svn checkout of Zope 3 that I can develop with? Is there a how-to somehwere? If there isn't, you could write one on the Zope 3 wiki. ;-) I'd imagine it goes something like: 1 - checkout svn url you wish to develop with Yep. svn co svn+ssh://svn.zope.org/repos/main/Zope3/trunk Zope3 or svn co svn+ssh://svn.zope.org/repos/main/Zope3/branches/3.3 Zope3 or replace the svn+ssh with svn 2 - do some kind of inplace build By typing 'make'. 3 - point your mkzopeinstance-created instance at the checkout I usually don't bother with mkzopeinstance, just symlink my packages into src/ and drop a one-liner file into zopeskel/etc/package-includes/. I'm not sure mkzopeinstance even works in a svn checkout. IIRC I saw a couple of reports of it failing when run from the checkut. The response usually was you're not supposed to use it from a checkout; run make install first, then use mkzopeinstance from the installation directory. 4 - develop This step looks deceptively simple. :-) 5 - run tests python test.py [options] (in the root directory of the checkout). How do I do 2 and 5? For 2, how do I do a suitable in-place build on Linux? Make sure you have gcc, make, python-dev installed, then type 'make'. Are there still up-to-date pre-built binary bits for Windows that I can unpack? If so, where do I get them from? No idea. I ran away to more developer-friendly OSes a long time ago. For 5, how do I run tests for a module in the checkout with the testrunner, as opposed to tests for a module in the instance? python test.py -s module I am not sure if there's a way to make Zope 3 and its test runner notice my packages without symlinking them into src/. zc.buildout may be the answer. I haven't used it on my projects yet, because what I already use works well enough for me. Cheers, Marius Gedminas -- If your company is not involved in something called ISO 9000 you probably have no idea what it is. If your company _is_ involved in ISO 9000 then you definitely have no idea what it is. (Scott Adams - The Dilbert principle) signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View permissions
On Tue, Jan 30, 2007 at 02:37:18PM +0100, Martijn Faassen wrote:
Marius Gedminas wrote:
[snip]
Also, I'd like a way to specify the adapter name in the adapter class.
Something like
from zope.interface import implements
from zope.component import adapts, named
class MyNamedAdapter(object):
adapts(IFoo)
implements(IBar)
named('myname')
def __init__(self, context):
self.context
Also I'd like to have a zope.component.Adapter class that defines
def __init__(self, context):
self.context
and does nothing else. It seems to me that 95% of all adapters have an
__init__ like this. It is tiring to keep repeating it.
Also, I want a pony. Ok, not really.
You can have your pony. In grok, there's a grok.Adapter class, which
does the thing in init, where you can specify the name using grok.name,
Cool!
and which causes registration as an adapter without the need for ZCML.
I am not sure I like that. When does the registration take effect? On
module import?
Marius Gedminas
--
Which is worse: ignorance or apathy? Who knows? Who cares?
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
On Wed, Jan 24, 2007 at 08:44:31PM -0500, Tres Seaver wrote: Note that for regularity, I assert that the calling the IFoo interface should allow the follwing use cases, based on the asserition that utilities are zero-order adapters, just as views are binary order adapters. There is a very important difference. When you do adaptation, an adapter factory gets called and you get a new object. (There are exceptions -- the adapter factory may do caching, or the object you're adapting may already implement the interface.) When you do utility lookups, you always get the same object. No factory ever gets invoked. Marius Gedminas -- Special bonus feature: absolutely nowhere in RetchMail's code is there an arbitrary 3-second sleep(). Wow! What other mail retriever can say that? (Hint: not fetchmail.) -- http://open.nit.ca/wiki/index.php?page=RetchMail signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] View permissions
On Mon, Jan 22, 2007 at 05:46:48PM -0500, Jim Fulton wrote:
I might even hack the TextWidget so I could just do:
adapter
factory=.TextWidget
permission=zope.Public
/
+1
I'd be happy to deprecate the view directive.
+1
Caveats: won't it seem strange to newcomers? Maybe there is a place for
some sort of a view directive that is basically an alias for
adapter, and maybe allows you to register a menu item as well?
Also, I'd like a way to specify the adapter name in the adapter class.
Something like
from zope.interface import implements
from zope.component import adapts, named
class MyNamedAdapter(object):
adapts(IFoo)
implements(IBar)
named('myname')
def __init__(self, context):
self.context
Also I'd like to have a zope.component.Adapter class that defines
def __init__(self, context):
self.context
and does nothing else. It seems to me that 95% of all adapters have an
__init__ like this. It is tiring to keep repeating it.
Also, I want a pony. Ok, not really.
Marius Gedminas
--
I may not understand what I'm installing, but that's not my job. I
just need to click Next, Next, Finish here so I can walk to the next
system and repeat the process
-- Anonymous NT Admin
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py --list-modules
On Sun, Jan 14, 2007 at 10:31:16PM +0200, Marius Gedminas wrote: I have now implemented --list-tests in a different branch. That option pays attention to all of -t, -m, -s, -u, -f, --layer, --level options. http://svn.zope.org/zope.testing/branches/list-tests/?rev=72034view=rev I intend to merge this one, unless somebody suggests a cleaner way of implementing it. Merged. Marius Gedminas -- Nobody will ever need more than 640k RAM! -- Bill Gates, 1981 Windows 95 needs at least 8 MB RAM. -- Bill Gates, 1996 Nobody will ever need Windows 95. -- logical conclusion signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wildcard adapter
On Thu, Jan 18, 2007 at 08:55:17AM +, Chris Withers wrote: Marius Gedminas wrote: BTW passing interfaces to provideAdapter/adapts is out of fashion. This stuff is getting almost perl-ish in it's there's many ways to do it, pick the style you like nature.. There's a slight difference, I think. In the Zope 3 world, there's usually one style that is considered to be the best way of doing stuff. Only it varies with time and with individual Zope 3 developers. ;-) I prefer using zope.component.adapts and zope.interface.implements (or zope.component.adapter and zope.interface.implementer, when my adapter is a function rather than a class). I often register the same adapter factory for several different types or objects / interfaces. How would I do that with your favoured spelling? If you pass the adapts/provides arguments to provideAdapter (or the ZCML directive), the values you specify override the defaults declared by the adapter itself. Marius Gedminas -- Some people have told me they don't think a fat penguin really embodies the grace of Linux, which just tells me they have never seen a angry penguin charging at them in excess of 100mph. They'd be a lot more careful about what they say if they had. -- Linus Torvalds, announcing Linux v2.0 signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wildcard adapter
On Thu, Jan 18, 2007 at 08:53:36AM +, Chris Withers wrote:
Philipp von Weitershausen wrote:
If it is, then which of the following should I use to register a
generic adapter for any single object to an interface:
provideAdapter(...,adapts=(None,),...)
This one.
Given that you can register adapters for any class, whether or not it
implements any interface, this doesn't work as it should:
from zope.component import provideAdapter
def adapter(*args): pass
...
from zope.interface import Interface
class ITest(Interface): pass
...
provideAdapter(adapter,adapts=(None,),provides=ITest)
It's a bit subtle. The function you pass to provideAdapter is not the
adapter, it is an adapter factory. Consider the difference between
classes and objects. One is a factory for the other. Adapters are
usually objects, and but you register classes with provideAdapter.
Now when you try to adapt anything to ITest, zope.component will call
your ``adapter`` function and then check the return value. A return
value of None means the adapter is not available, and results in a
TypeError you see here:
ITest(1)
Traceback (most recent call last):
...
TypeError: ('Could not adapt', 1, InterfaceClass __main__.ITest)
This is useful when you want to have an adapter that is available
conditionally.
Insert a print statement in your adapter function, and you will see that
it does get called:
from zope.component import provideAdapter
def myAdapter(*args):
... print Hi
...
from zope.interface import Interface
class ITest(Interface): pass
...
provideAdapter(myAdapter,adapts=(None,),provides=ITest)
ITest(1)
Hi
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: ('Could not adapt', 1, InterfaceClass __main__.ITest)
I have no idea what a generic adapter is, but the zope.component API
docs (== interfaces) are certainly complete in this sense. There are
also doctests.
Where can I find the docs and interfaces you mention above? I looked
through both zope.interface and zope.component and obviously missed them :-(
src/zope/component/README.txt would be my guess. I do not remember
what's inside, I learnt adapters by osmosis and occasional studying of
the source code.
Marius Gedminas
--
Change is inevitable, except from a vending machine.
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] wildcard adapter
On Wed, Jan 17, 2007 at 06:37:52AM -0800, Martin Aspeli wrote: Chris Withers wrote: I was wondering if someone could give me a definitive explanation of what the following means: adapter for=* ISomething * ... ...means? Is the following equivalent: provideAdapter(...,adapts=(None,ISomething,None),...) No, but this is: provideAdapter(...,adapts=(Interface, ISomething, Interface),...) As far as I know provideAdapter treats None the same way as Interface. I've used this pattern a few times: from zope.adapter import adapts, provideAdapter from zope.interface import implements ... class SomeAdapter(object): adapts(None) implements(IFoo) ... provideAdapter(SomeAdapter) BTW passing interfaces to provideAdapter/adapts is out of fashion. I prefer using zope.component.adapts and zope.interface.implements (or zope.component.adapter and zope.interface.implementer, when my adapter is a function rather than a class). Marius Gedminas -- America and England are two countries separated by a common language. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py -u -f
On Sat, Jan 13, 2007 at 01:37:17AM +0200, Marius Gedminas wrote: Due to an accident of implementation, if you pass both -u (run unit tests) and -f (run non-unit tests) to the test runner, it will not run any tests at all. That is not useful. I have a branch where test.py -fu is equivalent to specifying neither -f nor -u and runs all the tests: http://svn.zope.org/zope.testing/branches/test-fu/?rev=71988view=rev If there are no objections, I would like to merge that branch. Merged. Marius Gedminas -- It is a mess, pure and simple. Sucks to be away from Unix, huh? -- man perlfaq3 signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py -s src/zope/something
On Sat, Jan 13, 2007 at 01:44:17AM +0200, Marius Gedminas wrote: A long time ago test.py -s accepted directory names. Later it was changed to take package names instead. There is some backwards-compatibility code that replaces slashes with dots, but it is incomplete: test.py -s src/zope would try to run the tests for a nonexistent package src.zope. I have expanded the backwards-compatibility/convenience code in a branch: http://svn.zope.org/zope.testing/branches/filter-by-dirs/?rev=71986view=rev Merged. Marius Gedminas -- phrakture i learned vim by reading the source code. am I hardcore yet? Axioplase phrakture: not enought yet... read it rot13'd, and you'll be hardcore ^^ phrakture I read it as analog output on an oscilliscope mgedmin rot13, bah, try reading the gzipped source tarball Zathrus encrypted. lack standing on your head. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py --list-modules
On Fri, Jan 12, 2007 at 11:30:15PM +0200, Marius Gedminas wrote: The Zope 3 test runner can filter tests by package, module, test name and layer. Sometimes your expectations do not match reality and either the test you want is not being run, or more tests than you wanted are being run. When you want to debug filter patterns it helps if you can see what tests would be run without wasting time actually running them. I have implemented a --list-modules option in a branch. It causes the test runner to apply package and module name filters, and then print the list of Python module names that would be imported. It is very fast because it doesn't actually import the modules. I have now implemented --list-tests in a different branch. That option pays attention to all of -t, -m, -s, -u, -f, --layer, --level options. http://svn.zope.org/zope.testing/branches/list-tests/?rev=72034view=rev I intend to merge this one, unless somebody suggests a cleaner way of implementing it. I do not think I care enough about --list-modules or --list-files to push those to completion. Marius Gedminas -- If all else fails, read the documentation. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: zope.testing/branches/mgedmin-fixes/src/zope/testing/testrunner Implement a --list-modules option that lists all modules matching your pattern,
On Fri, Jan 12, 2007 at 08:07:22AM +0530, Baiju M wrote: Marius Gedminas wrote: Log message for revision 71953: Implement a --list-modules option that lists all modules matching your pattern, but does not actually run any tests. I hope this will help me figure out why test.py -s zope.testing in a Zope 3 checkout runs 0 tests. If I comment 'zope[.]testing' line in test.py, I can run 'test.py -s zope.testing'. Yes, I discovered the -m !^(...|zope.testing|...) in Zope 3's top-level test.py as well. At first I thought it was a sinister bug in zope.testing. And all tests are passed with message Ran 123 tests with 0 failures and 0 errors in 18.783 seconds. Which Python version do you have? I get 4 failures with Python 2.4.4c1 (Ubuntu Edgy) with the zope.testing trunk. These are now fixed on the mgedmin-fixes branch. Marius Gedminas -- Where do you think you're going today? signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: test.py --list-modules
The Zope 3 test runner can filter tests by package, module, test name and layer. Sometimes your expectations do not match reality and either the test you want is not being run, or more tests than you wanted are being run. When you want to debug filter patterns it helps if you can see what tests would be run without wasting time actually running them. I have implemented a --list-modules option in a branch. It causes the test runner to apply package and module name filters, and then print the list of Python module names that would be imported. It is very fast because it doesn't actually import the modules. It is not very accurate because it does not pay attention to test name patterns or layer filtering. Would this option be useful to anybody? You can find the code here: http://svn.zope.org/zope.testing/branches/list-modules/?rev=71982view=rev I am also thinking about two other options: * --list-files -- essentially the same as --list-modules, but outputs file names instead of module names. * --list-tests -- apply package and module filters, import the modules, apply test name and layer filters, then list just the names of tests. Would these be useful to anybody? SchoolTool's custom test runner used to have --list-tests and --list-files. Now that SchoolTool has finally switched to the Zope 3 test runner, I wonder if anyone working on SchoolTool would miss those (hi, Ignas ;-). Marius Gedminas -- TCP_SeqNum - The 32-bit Sequence Number, encoded as an ASCII string representing the hex value of the Sequence number. This field MUST be sent as lower case because it is not urgent. -- RFC 3093 signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py --list-modules
On Fri, Jan 12, 2007 at 05:17:18PM -0500, Benji York wrote: Marius Gedminas wrote: I have implemented a --list-modules option in a branch. It causes the test runner to apply package and module name filters, and then print the list of Python module names that would be imported. It is very fast because it doesn't actually import the modules. It is not very accurate because it does not pay attention to test name patterns or layer filtering. Would this option be useful to anybody? If its output were identical to the tests that were actually going to be selected, then I think it'd be worth including. That would be the proposed --list-tests option, wouldn't it? Or do you want a list of modules that have at least one test remaining after all the filtering (including --layer, --level and --test) is done? OTOH, being not very accurate would make the feature as implemented a bit of an attractive nuisance. I phrased it badly. s/It is not very accurate/It may not match user expectations/. As implemented in that branch, --list-modules is the list of test modules that will be imported. That is accurate. My doubts lie in whether this is what the user wants. A long time ago, the Zope 3 test runner would only import unit or functional test modules if it saw the corresponding option on the command line. I was used to that. I think that is why I thought seeing unit tests in 'test.py -f --list-modules' might be confusing. Marius Gedminas -- What goes up, must come down. Ask any system administrator. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: test.py -u -f
Due to an accident of implementation, if you pass both -u (run unit tests) and -f (run non-unit tests) to the test runner, it will not run any tests at all. That is not useful. I have a branch where test.py -fu is equivalent to specifying neither -f nor -u and runs all the tests: http://svn.zope.org/zope.testing/branches/test-fu/?rev=71988view=rev If there are no objections, I would like to merge that branch. Marius Gedminas -- Of course I use Microsoft. Setting up a stable unix network is no challenge ;p signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: test.py -s src/zope/something
A long time ago test.py -s accepted directory names. Later it was changed to take package names instead. There is some backwards-compatibility code that replaces slashes with dots, but it is incomplete: test.py -s src/zope would try to run the tests for a nonexistent package src.zope. I have expanded the backwards-compatibility/convenience code in a branch: http://svn.zope.org/zope.testing/branches/filter-by-dirs/?rev=71986view=rev The test runner has a mapping of directory names to package names, and I use it in reverse to get the package name from the directory name. As a result you can use your shell's directory name completion for the test runner command line, and, for example, test.py -s src/zope now works. I would appreciate it if someone could check out this branch and run its tests on Windows. Marius Gedminas -- The advertisement is the most truthful part of a newspaper. -- Thomas Jefferson signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope repositories
On Thu, Jul 13, 2006 at 11:02:33PM +0200, luis wrote: while browsing the zope svn repository at http://svn.zope.org , I noticed there are some packages that seem to be duplicated... for example [Zope] / zope.formlib / trunk / src / zope / formlib vs [Zope] / Zope3 / trunk / src / zope / formlib This bit me recently. Google gives me the first link as the first hit when I search for zope.formlib, but the second one appears to be more recent. (I thought Zope 3 included zope.formlib with svn:externals, but didn't check that assumption.) Marius Gedminas -- AdamV SamB: PHP's basic control structure is the database timeout error. -- from Twisted.Quotes signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The bug fixing problem
On Fri, Jul 07, 2006 at 08:48:39PM +0200, [EMAIL PROTECTED] wrote: In many cases, I can convince myself that a fix does actually work without performing a test -- at least in the sense that it removes one bug. In many cases I have made completely trivial bug fixes that I was absolutely confident about. I wrote unit tests for those bug fixes only out of habit. Quite often I was surprised when my superfluous tests caught bugs in my trivial bugfixes. Marius Gedminas -- Look! Before our very eyes, the future is becoming the past. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On Wed, Jul 05, 2006 at 11:46:52AM +0200, Christian Theune wrote: I'm sitting at EuroPython right now, and a small discussion came up, trying to find out why nobody seems motivated to fix bugs came up. ... I feel like fixing a bug every now and then when I have like 30 minutes spare time and want to do something useful. This happens to me about once a month. I get the wanna fix a bug in 30 minutes feeling, head over to the Zope 3 collection, and start browsing. Almost always I find no bug that I'd want to fix at the time. There are several reasons: 1. Some of the bug reports I do not understand. 2. Some of the bugs need changes in code that I'm not familiar with. 3. For some of the bugs it is unclear what ought to be done. (2) and (3) are pretty close, but (3) refers to behaviour visible from the outside, while (2) refers to implementation details. I do not think that the requirements to 4. Write unit tests 5. Merge bugfixes from trunk to the release branch 6. Wait for the incredibly slow updates on the collector discourage me all that much. I think that if more bug reports had a solution outlined in English, I'd be more likely to go fix them every now and them. Marius Gedminas -- We'll show a small example here with one user calling another. (Under international treaties describing technical papers these users must be called Alice and Bob.) -- Anthony Baxter signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issues 648 and 593: uploading files with non-ASCII filenames now works.
On Mon, 2006-19-06 at 11:01 +0200, Adam Groszer wrote: Hi Marius, Your fix of browser.py causes problems for me using hurry.file when running functional test with zope.testbrowser. The problem is that aFieldStorage.filename is already unicode and it cannot be decoded again. Do you mind if I add an if isinstance(aFieldStorage.filename, unicode): construct? I don't mind, but I think it would be better if testbrowser was changed to match what real browsers do instead. On Mon, Jun 19, 2006 at 08:37:03AM -0230, Rocky Burt wrote: Hmm, this seems strange to me. How can it be guaranteed that the remote filename is a utf-8 encoded byte string? Not sure this should be done this way anyhow. There's an RFC (1867) that says each part in a multipart/form-data request has headers (filename is one of them) that are always 7-bit ASCII and use MIME quoting (RFC 1522, =?charset?encoding?encoded-text?=) if they need to represent non-ASCII characters. Experiments with two real-life browsers (Firefox on Linux, with a UTF-8 system locale, and MSIE 6 on Windows XP with Lithuanian regional settings, which, I presume, mean cp1257) showed that if I upload a filename with non-ASCII characters, I get a UTF-8 encoded str at this point in the code. I assumed that the cgi module from the standard library (that's where the aFieldStorage object comes from) takes care of charset conversions (but didn't actually check that assumption). Modified: Zope3/trunk/src/zope/publisher/browser.py === --- Zope3/trunk/src/zope/publisher/browser.py2006-06-13 22:00:47 UTC (rev 68625) +++ Zope3/trunk/src/zope/publisher/browser.py2006-06-14 12:25:49 UTC (rev 68626) @@ -596,7 +596,7 @@ d[m] = getattr(file,m) self.headers = aFieldStorage.headers -self.filename = aFieldStorage.filename +self.filename = unicode(aFieldStorage.filename, 'UTF-8') class RedirectingBrowserRequest(BrowserRequest): Browser requests that redirect when the actual and effective URLs differ Marius Gedminas -- We have enough youth, how about a fountain of SMART? signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Somebody review my fix for issue 592?
Hi, On Sun, Jun 18, 2006 at 01:33:48AM -0400, Christian Theune wrote: I'm pretty confident that this change does what it is intended to do (fix 592 and some inconsistencies along the way). But as I had to figure out some pretty old code and some of the architecture and dependencies in zope.app.form.browser, I might have made a mistake, although I supplied tests and changed the existing tests according to my view of the world. Here's the changeset for the trunk: http://svn.zope.org/Zope3/trunk/src/zope/app/form/browser/itemswidgets.py?rev=68729view=rev It broke a functional test in one of the packages here. The (no value) option disappeared from the dropdown. It should not have disappeared, because the schema field explicitly says it is not required. (The same thing happens with a real browser.) Reverting the change made in rev 68729 to src/zope/app/form/browser/itemswidgets.py makes the (no value) choice reappear and therefore fixes the problem. I'm still trying to understand why it happens in that view, but not in some other views that also have not-required Choice fields. Marius Gedminas -- If you are smart enough to know that you're not smart enough to be an Engineer, then you're in Business. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Somebody review my fix for issue 592?
On Mon, Jun 19, 2006 at 07:59:07PM +0300, Marius Gedminas wrote: On Sun, Jun 18, 2006 at 01:33:48AM -0400, Christian Theune wrote: I'm pretty confident that this change does what it is intended to do (fix 592 and some inconsistencies along the way). But as I had to figure out some pretty old code and some of the architecture and dependencies in zope.app.form.browser, I might have made a mistake, although I supplied tests and changed the existing tests according to my view of the world. Here's the changeset for the trunk: http://svn.zope.org/Zope3/trunk/src/zope/app/form/browser/itemswidgets.py?rev=68729view=rev It broke a functional test in one of the packages here. The (no value) option disappeared from the dropdown. It should not have disappeared, because the schema field explicitly says it is not required. (The same thing happens with a real browser.) The problem was that zope.mimetype had its own widget, that subclassed (after a couple of levels of indirection) ItemsEditWidgetBase and overrode renderItemsWithValues. Your changeset shifted the responsibility for rendering the (no value) choice from various renderItems methods into renderItemsWithValues, and zope.mimetype.widget.TranslatableSourceSelectWidget did not expect that. I wonder how many widgets outside the Zope 3 source tree subclass ItemsEditWidgetBase and override renderItemsWithValues... Marius Gedminas -- Stupidity management for the superuser is a user space issue in Unix systems. -- Alan Cox signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: ZOPE3 Maildir implementation
Hi, folks! On Fri, Apr 07, 2006 at 05:23:06PM +0200, Philipp von Weitershausen wrote: The Maildir step could have been skipped, I suppose, just the connection to a mail server directly over the network interface would suffice. Is there a specific reason for the Maildir implementation? The reason for queued delivery (as opposed to direct delivery) is that you might send an email that is later aborted. For example, consider a change notification email whereas the change itself is aborted. The email would be lying about the state of the application. With queued delivery, the email isn't sent when the transaction is aborted. As Gary pointed out, the reason for using Maildir is a practical one. We don't want to block. Actually, the DirectMailDelivery utility also aborts emails if the transaction is aborted. The reason for using Maildirs was to speed up the transaction commit -- if you send 100 emails in a transaction, you do not want to wait for 100 SMTP connections while the user is sitting in front of his browser waiting. Creating a 100 files in the outgoing mail queue was supposed to be faster. It didn't work due to the extreme brain-deadness of the Maildir code. IIRC I wrote it (a number of years ago, when I was young and foolish) and I cannot fathom why I didn't realize that 1 email per second would be an extremely inconvenient. Maybe I was too enamored with Extreme Programming ideas at the time (let's do the simplest thing that could possibly work, and when it turns out to be not enough, we can just fix it). Well, the time to fix it has finally come. There were also some bugs in the transaction commit/abort logic that could lead to multiple copies of the emails being sent on ZODB ConflictErrors. Thankfully all this is now fixed in Zope 3 trunk, and in the 3.2 branch. The issue was http://www.zope.org/Collectors/Zope3-dev/590 2. The current implementation can only handle between 30-60 E-mail's a minute. This is mostly due to the naming convention used for maildir files (one a second - actually the Maildir naming allows in between numbers, but you don't use that). Actually, the Maildir spec (http://cr.yp.to/proto/maildir.html) now suggests new fashion Maildir names that are a lot more unique than old fashion ones. Every major Maildir implementation I've come across in the last two years uses new fashion Maildir names. I didn't know about this. Yesterday I just changed the unique name generator to include a large random number in the filename. In the wrong place, so it no longer matches the Maildir spec. *sigh* Any volunteers for making it match the spec? Marius Gedminas -- #define QUESTION ((bb) || !(bb)) /* Shakespeare */ signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] a new zcml directive?
On Fri, Mar 10, 2006 at 04:19:44PM +0100, Martijn Faassen wrote: Hi there, I notice a pattern in code that uses annotations that looks like this: class Foo(Persistent, Contained): implements(interfaces.IFoo) def getFoo(context): annotations = IAnnotations(context) try: return annotations[FOO_KEY] except KeyError: foo = Foo() annotations[FOO_KEY] = foo # to please security... zope.app.container.contained.contained( foo, context, 'foo') return foo # Convention to make adapter introspectable getFoo.factory = Foo If I'm doing this quite a bit, this looks like something that would be better expressed in a... new ZCML directive (..waiting for the crowd to start flinging stones). For instance, one that looks like this: zope:annotation for=IBar factory=Foo / where the factory actually points to whatever creates the real annotation (such as the Foo class in this case), not to the boilerplate to attach it to the proper object. The boilerplate would go away from my code, you could use the facility too without thought, and we'd all be happy. :) -1 I'd prefer from zope.annotation.adapter import AnnotationAdapter getFoo = AnnotationAdapter(for_=IBar, interface=IFoo, factory=Foo, key=FOO_KEY) # I suppose the key could be optional; you could use a dotted # interface name by default and then the ordinary zope:adapter factory=.foo.getFoo / I think this is exactly the same as Jeff Shell's suggestion, but its 3am, and I'm too tired to read his entire message. Marius Gedminas -- We have an advanced scalable groupware communication environment (email) -- Alan Cox signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal: Enhance tracebacks in persistent logs
On Wed, Jan 18, 2006 at 04:37:41PM -0700, Shane Hathaway wrote: Any objections to this proposal? http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/EnhanceTracebacksInPersistentLogs +1 (I would like the test runner to use extended tracebacks as well.) Marius Gedminas -- This is an object-oriented system. If we change anything, the users object. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] attr name space (was: RFC: abolishing python: expressions)
On Fri, Dec 30, 2005 at 11:22:56AM +0100, Alexander Limi wrote: This reminds me of a thing Steve Alexander and myself talked about when working together on a project using Zope 3 a while back: One of the ugliest and most error-prone parts of TAL is its handling of multiple attributes: a tal:attributes=href some/url; title some/title; / etc. We looked at having a separate namespace for these kinds of statements. The above code would then be: a attr:href=some/url attr:title=some/title / How would you express my_xml_element tal:attributes=xlink:href some/url; xlink:title some/title; / ? AFAIR if you use the XML Namespaces spec, you can only have one ':' in an attribute name, so this would be invalid: my_xml_element attr:xlink:href=some/url attr:xlink:href=some/title / The same would probably be relevant for tal:defines, something like: div define:mammals=here/getMammals define:fish=here/getFish / You can do things like div tal:define=foo view/foo; bar foo/bar; baz python:bar and 'something' or 'somethingelse'; qux string:my_class $baz / because the ordering of definitions is explicit. How would you specify the order of definitions if you used separate attributes in the define: namespace? Attributes have no order in XML. Marius Gedminas -- C++ is a loaded machine gun helpfully pointed at your feet with the safety off. -- ChaosDiscord on Slashdot signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope-dev] Announcement: the Zope Subversion repository will be down for maintenance on December 25th, 2005
On Mon, Dec 19, 2005 at 05:17:04PM -0500, Jim Fulton wrote:
Jim Fulton wrote:
Jens Vagelpihl has graciously offered to convert the subversion
repository to use a file-system back end.
Jim groans, That's Jens Vagelpohl.
Thanks again Jens!
Yes! Yes! Yes!
I can offer a short shell script that I used to convert about 50 small
repositories to fsfs. Perhaps it will come in handy.
Marius Gedminas
--
In short, at least give the penguin a fair viewing. If you still don't
like it, that's ok: that's why I'm boss. I simply know better than you
do.
-- Linus what, me arrogant? Torvalds, on c.o.l.advocacy
#!/bin/sh
# convert a subversion repository to fsfs
# usage: convert-svn-to-fsfs /path/to/repository
repos=${1%/}
test -z $repos {
echo usage: $0 /path/to/repository 12
exit
}
test -f $repos/format || {
echo $0: $repos is not a subversion repository 12
exit 1
}
test -e $repos.old {
echo $0: $repos.old already exists 12
exit 1
}
test `cat \$repos/db/fs-type\ 2/dev/null` = fsfs {
echo $0: $repos already uses fsfs 12
exit 1
}
set -e
mv $repos $repos.old
svnadmin create --fs-type fsfs $repos
svnadmin dump -q $repos.old | svnadmin load -q $repos
echo * $repos converted to fsfs
ls $repos.old/hooks | grep -v [.]tmpl$ | while read fn; do
echo copying $fn hook
cp $repos.old/hooks/$fn $repos/hooks/
done
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFC: Handling HTTP DELETE errors
Hi folks, When you do HTTP DELETE on objects that do not explicitly support deletion, the default view (zope.app.http.delete.DELETE) tries to adapt self.context.__parent__ to IWriteDirectory, which raises a TypeError which is never caught. I suggest changing the view to raise MethodNotAllowed instead when there is no adapter: dir = IWriteDirectory(container, None) if dir is None: raise MethodNotAllowed(self.context, self.request) If there are no objections, I will write a test and make this change to Zope 3 trunk. (This is also http://www.zope.org/Collectors/Zope3-dev/497, but I thought more people would see my request for comments if I posted it here.) Marius Gedminas -- 9. Okay, then, what do you think about syntactic noise in config files? [EMAIL PROTECTED]@!#([EMAIL PROTECTED]';,[EMAIL PROTECTED] -- http://open.nit.ca/wiki/index.php?page=RetchMail signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
