Re: [Zope-dev] [zopeproject] ZODB3 specified, but ZODB3 3.9.0-dev-r77011 egg still attempted?!
Brandon Craig Rhodes wrote: [buildout] ... versions = versions Should we write something like Grok for buildout, so that it just uses sections without having to have them doubly declared up at the top? :-) Heh, nah, this was a fair cop. I *did* actually know about this, was just a silly bug in my buildout... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional parameters --
what a simplification and homogenization :-)
Yeah, but since when has simplification or homogenisation been a goal of
Zope 3? ;-)
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Dieter Maurer wrote: Jim is heavily defending this difference. I am convinced that the difference should not be there fork anyone? ;-) but meanwhile have found a use case for it. Suppose, you have a class C that implements I. If queryAdapter would behave like I(...), you would have no way to override the implementation of I by C. With the current behavior, you can use queryAdapter(c, I) to check whether some special requirements apply and in this case use the special purpose adapter. Right, so every time you want these semantics you have to jump through these hoops. My understanding of the CA was that it was supposed to stop the need for this kind of copy'n'paste coding? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.recipe.testrunner/trunk/src/zc/recipe/testrunner/README.txt made doctest sections from the literal sections
Benji York wrote: On Mon, Aug 25, 2008 at 6:24 AM, Michael Howitz [EMAIL PROTECTED] wrote: Log message for revision 90184: made doctest sections from the literal sections Thanks for removing the unneccesary -- and inappropriate Why are they unneccesary and inappropriate? These are what causes the examples to appear in blue boxes on PyPI, which I think makes them much clearer... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weird release of transaction module
Martijn Faassen wrote: What's up? Clearly something went wrong during the releasing of this package, at least documentation-wise. Should be fixed. I'd hazard a guess at yet another brown bag release that now no-one wants to remove for the same stupid reasons that are always parrotted as soon as someone wants to remove something insane from PyPI or another source of eggs... *sulk* Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.size/trunk/bootstrap.py Added support to bootstrap on Jython.
Benji York wrote: It'll have to be an external to svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk/bootstrap since Subversion doesn't do externals to individual files. The zope.introspector project is one example taking this approach: svn+ssh://svn.zope.org/repos/main/zope.introspector/trunk Why svn+ssh rather than just svn? These are only consumers afterall. Chris . o O ( oh for a simple http svn.zope.org like every other project under the sun uses ;-) ) -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPT and strict namespace mapping
Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
--On 29. August 2008 12:31:21 +0200 Malthe Borch [EMAIL PROTECTED] wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). Can you elaborate this statement? Andreas pgpwl01UqfQrT.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form - extraction from sequence widget
Am Donnerstag 28 August 2008 23:55:24 schrieb Martin Aspeli: Hermann Himmelbauer wrote: Am Donnerstag 28 August 2008 02:35:28 schrieb Marius Gedminas: On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote: On Wednesday 27 August 2008, Martin Aspeli wrote: This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE). Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any required missing exceptions, even when I untick all the checkboxes and click OK. Am I missing something? I think you have a point. Have you tried changing the behavior to return default and see what tests fail? If no major failures come out of this, I would say change it. Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation. A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger required missing errors. I see this the same way - in my application I have a similar case (Accept some policy by a checkbox-click). I solved this simply by checking the value in the action handler and raising a WidgetExecutionError if it is unchecked. The notion of a required boolean field is a bit weird anyway. I think you *could* interpret it so that a boolean field that's required really means you have to tick this box (e.g. an I agree to these terms and conditions type scenario). My idea is to look at it bottom-up: Think about schemas without widgets at all, e.g. in a totally different non-zope/form scenario. To my mind, it's obvious, that required=True means, that some sort of value has to be given and not, that the value has to be of a specific type (e.g. True for Boolean). To put it the other way - how would you have a non-required boolean field represented by a checkbox? You really need three states then: True False and None, which you can't get with a checkbox. Well, and then there's the representation of fields by widgets. And, right, it's impossible to provide no value via a checkbox or a radio-box offering yes/no. And, yes, this somehow obsoletes the required constraint. But isn't this perfectly normal for widgets? For instance, a Choice, which is represented by a drop-down widget, will also never return None. Btw., it is possible to have a three-state widget for booleans, such as a drop-down widget, that includes True/False/None, although it may not make much sense. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.doctest bug
Benji York wrote: For the forked doctest in zope.testing, the Zope 3 project's bug tracker in Launchpad would be appropriate. https://bugs.edge.launchpad.net/zope.testing/+bug/262578 I suspect Python's doctest has the same bug; checking that and reporting the bug to them would be good too. They may have already fixed it, if so we can copy their fix. They haven't fixed it, so submitted here too: http://bugs.python.org/issue3722 cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form - extraction from sequence widget
Am Donnerstag 28 August 2008 17:45:58 schrieb Marius Gedminas: On Thu, Aug 28, 2008 at 05:26:20PM +0200, Hermann Himmelbauer wrote: Am Donnerstag 28 August 2008 10:14:11 schrieb Martin Aspeli: What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error. Yes, in your case this should give a validation error. However, the case where someone uses a checkbox for a True/False operation is at least as common. And if no ticking gives a validation error, this would prevent using checkboxes for this case. Moreover, a checkbox is typically used to represent a Bool schema (by default it's a choice widget, I think), so that fits well, I think. My suggestion would be to: - Create some schema field, e.g. MultipleChoice: colors = MutlipleChoice(title='Colors', values=['red', 'green', 'blue'], default=['green', 'blue'], required=True) colors = Set(type=uChoose your favourite colors, value_type=Choice(values=['red', 'green', 'blue']), min_length=1) Yes, so it already exists, then. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 4 OK, 1 Unknown
Summary of messages to the zope-tests list. Period Thu Aug 28 11:00:00 2008 UTC to Fri Aug 29 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Unknown --- Subject: UNKNOWN : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Aug 28 20:43:02 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010080.html Tests passed OK --- Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Aug 28 20:44:32 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010081.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Aug 28 20:46:03 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010082.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Aug 28 20:47:33 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010083.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Aug 28 20:49:03 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010084.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
2008/8/29 Andreas Jung [EMAIL PROTECTED]: --On 29. August 2008 12:31:21 +0200 Malthe Borch [EMAIL PROTECTED] wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). Can you elaborate this statement? Right, so this is basically a question of whether the following template is legal or not: div tal:replace=string:hello world! / In ZPT it would be, because it automatically assumes this namespace declaration: xmlns=http://www.w3.org/1999/xhtml; xmlns:tal=http://xml.zope. org/namespaces/tal xmlns:metal=http://xml.zope.org/namespaces/metal; . z3c.pt otoh, does not make such an assumption. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Failing Zope 2.8 / Python 2.3 tests on your box
The Python 2.3 on that box hasn't changed in a while, and the
encodings module works, at least interactively.
$ /usr/local/python2.3/bin/python
Python 2.3.6 (#1, Nov 11 2006, 11:08:56)
[GCC 4.0.2 (Debian 4.0.2-2)] on linux2
Type help, copyright, credits or license for more information.
import encodings
encodings.aliases.aliases
{'iso_ir_6': 'ascii', 'maccyrillic': 'mac_cyrillic', 'iso_celtic':
'iso8859_14', 'ebcdic_cp_wt': 'cp037', ...
On 20. Aug 2008, at 19:57, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan,
Tests are blowing up on that box becaues the 'encodings' module has no
attribute 'aliases': AFAICT, that doesn't happen on a standard
build
of Python: is there something weird about your setup?
Tres.
--
Anything that, in happening, causes something else to happen,
causes something else to happen. --Douglas Adams
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
--On 29. August 2008 13:20:38 +0200 Malthe Borch [EMAIL PROTECTED] wrote: 2008/8/29 Andreas Jung [EMAIL PROTECTED]: --On 29. August 2008 12:31:21 +0200 Malthe Borch [EMAIL PROTECTED] wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). Can you elaborate this statement? Right, so this is basically a question of whether the following template is legal or not: div tal:replace=string:hello world! / In ZPT it would be, because it automatically assumes this namespace declaration: xmlns=http://www.w3.org/1999/xhtml; xmlns:tal=http://xml.zope. org/namespaces/tal xmlns:metal=http://xml.zope.org/namespaces/metal; . z3c.pt otoh, does not make such an assumption. For convenience: z3c.pt should/could make such an assumption :-) Andreas pgpCwfAxhpKkh.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Failing Zope 2.8 / Python 2.3 tests on your box
What I have found out now is that in my Python 2.3.6 encodings/ __init__.py does not contain 'import aliases' at module level, whereas the Python 2.4 lib has this import. The patch does this: import encodings encodings._aliases = encoding.aliases.aliases which does therefore not work in 2.3. So, now I am curious how your Python 2.3 differs, and why you don't see the error locally :-) Cheers, Stefan -- It doesn't necessarily do it in chronological order, though. --Douglas Adams ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form - extraction from sequence widget
Hi Hermann Betreff: Re: [Zope-dev] z3c.form - extraction from sequence widget [...] I think you *could* interpret it so that a boolean field that's required really means you have to tick this box (e.g. an I agree to these terms and conditions type scenario). My idea is to look at it bottom-up: Think about schemas without widgets at all, e.g. in a totally different non-zope/form scenario. To my mind, it's obvious, that required=True means, that some sort of value has to be given and not, that the value has to be of a specific type (e.g. True for Boolean). To put it the other way - how would you have a non-required boolean field represented by a checkbox? You really need three states then: True False and None, which you can't get with a checkbox. Well, and then there's the representation of fields by widgets. And, right, it's impossible to provide no value via a checkbox or a radio-box offering yes/no. And, yes, this somehow obsoletes the required constraint. But isn't this perfectly normal for widgets? For instance, a Choice, which is represented by a drop-down widget, will also never return None. Btw., it is possible to have a three-state widget for booleans, such as a drop-down widget, that includes True/False/None, although it may not make much sense. No that's not possible! Because you can't save anything then False or True in a Bool field. That means the first time if no value is given the Bool field could return None as default=None. Which indicates that if missing_value=None is used the input is missing. But it is not valid to do that! Why? In some use case: zope.schema.Bool( required=True, default=None, missing_value=None) will raise exceptions. But why? If this field get used for a global configuration and will apply the defualt value if nothing get defined and the valdation get invoked, then this is will raise a validation error during zope start up and zope will not start. I think it's always bad idea to use default=None for Bool fields. Because of it's invalid defaults. Some background; Let me explain how the schema and the different field attribute combination work. If a field defines: required=True That means you must provide input if you store a value. But what means input for the field? This is defined in: missing_value='foo' That means everything except 'foo' is input. But doesn't mean that everything is valid input. the missing_value marker is a very important concept. It defines if input is given. This makes it possible to use None or False as input (doens't matter if valid or not) The widget and also the field has validation methods for find out if a value is valid or not which get in use if you store something. In general I think if an attribute should provide states like - selected - not selected - no yet set and at least a given state could set back to *not yet set* after the state was set. A boolean with a Bool field is defently the wrong type for such an attribute. If you like to do so, you need to define a choice which you can choose form and use another HTML input component then a single checkbox input or two radio (yes, no) elements. Hermann, can you you give me a short description of the problem what this thread describes and what is missing in z3c.form? If there is a real problem in the behavior or a missing widget I like to fix that. But right now I don't really understand the real problem. Sorry but I didn't follow the full mail thread. Regards Roger Ineichen Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.size/trunk/bootstrap.py Added support to bootstrap on Jython.
On Fri, Aug 29, 2008 at 5:53 AM, Chris Withers [EMAIL PROTECTED] wrote: Benji York wrote: It'll have to be an external to svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk/bootstrap since Subversion doesn't do externals to individual files. The zope.introspector project is one example taking this approach: svn+ssh://svn.zope.org/repos/main/zope.introspector/trunk Why svn+ssh rather than just svn? These are only consumers afterall. Typo. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.recipe.testrunner/trunk/src/zc/recipe/testrunner/README.txt made doctest sections from the literal sections
On Fri, Aug 29, 2008 at 5:36 AM, Chris Withers [EMAIL PROTECTED] wrote: Benji York wrote: On Mon, Aug 25, 2008 at 6:24 AM, Michael Howitz [EMAIL PROTECTED] wrote: Log message for revision 90184: made doctest sections from the literal sections Thanks for removing the unneccesary -- and inappropriate Why are they unneccesary and inappropriate? The double-colons are structural markup, they signify the introduction of a literal block (http://docutils.sourceforge.net/docs/user/rst/quickref.html#literal-blocks). doctest blocks have their own syntax (http://docutils.sourceforge.net/docs/user/rst/quickref.html#doctest-blocks). These are what causes the examples to appear in blue boxes on PyPI, which I think makes them much clearer... That's a matter of presentation, not structure. If you would like to see a change to the way doctest blocks are formatted on PyPI, you should make a proposal to the PyPI folks. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
On Fri, Aug 29, 2008 at 12:31:21PM +0200, Malthe Borch wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). Requiring explicit XML namespace declarations for TAL and TALES is a big cost for no obvious benefit, except maybe for making some obsessive-compulsive XML people slightly happier. It's not the Python way, I believe. We don't have 'public static void main', why should we have mandatory XML namespaces in our page templates? Marius Gedminas -- Some people around here wouldn't recognize subtlety if it hit them on the head. signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Make simple ISource usable
I'll try to make the ISource API smooth and usable for other components. Right now ISource provides no simple API for work with terms. Since a ISource only provides a __contains__ method and the IterableSource the __iter__ method, there is some more needed which makes it easy to work with terms next to the ISourceQueriables API. The zope.app.form.browser.interfaces.ITerms defines one possible way to make it work like a vocabulary because it defines the methods getTerm(value) and getValue(token). The z3c.form.interfaces.ITerms defines also such a query API but right now only or vocabularies. I propose to define such a ITerms interface in zope.schema.interfaces which makes it possible to implement simple ISource terms and work with the ITerm values like we do in vocabularies. This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms). The current state of ISource/ITerms concept whould not work if someone will switch form zope.app.form based sources to z3c.form based sources because of it's different ITerms implementations. Or if someone defines a zope.schema.ISource in a 3rd party package, the zope.app.form.browser.interfaces.ITerms is often used for query ITerms even if it's only used in python code without any form framework. That's a real bad dependency. Fazit, The only query API defined for ISource in zope.schema is the ISourceQueriables API. That's defently to less and makes it required to implement custom query APIs in UI frameworks if we need to work with terms. I no one objects, I'll start a zope.schema branch and let you know about the progress and a hopfully a simple solution. Additional to them I started allready a z3c.form branch for adjust the ITerms implementation. As far as I can see right now this refactoring will only provides additional features. What do you think? Any objections or hints about that? Regards Roger Ineichen _ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile+41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email [EMAIL PROTECTED] _ END OF MESSAGE ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] weird release of transaction module
Martijn Faassen wrote: I just looked at the PyPI page of 'transaction': http://pypi.python.org/pypi/transaction And I see some weirdnesses: * it's called 'transaction 1.0a1' * the 'changes' claim however: 1.0 (unreleased) What's up? Clearly something went wrong during the releasing of this package, at least documentation-wise. Should be fixed. The documentation is wrong indeed. Note that zope.sqlalchemy pulls in this package as a dependency, even though I don't think ZODB 3.8 comes with that version of transaction... The transaction module has been moved out of the ZODB egg for ZODB trunk aka 3.9 as far as I know. That means the stand-alone transaction package can probably not be used with any ZODB 3.8 versions. But except the wrong documentation, I don't see a problem with the release as such. IIRC someone wanted to use it outside the ZODB and it was moved out and got an early alpha release. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Failing Zope 2.8 / Python 2.3 tests on your box
On Fri, Aug 29, 2008 at 14:05, Stefan H. Holek [EMAIL PROTECTED] wrote: What I have found out now is that in my Python 2.3.6 encodings/ __init__.py does not contain 'import aliases' at module level, whereas the Python 2.4 lib has this import. The patch does this: import encodings encodings._aliases = encoding.aliases.aliases which does therefore not work in 2.3. So, now I am curious how your Python 2.3 differs, and why you don't see the error locally :-) The 1.1 version of the hotfix corrected this. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Failing Zope 2.8 / Python 2.3 tests on your box
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan H. Holek wrote:
What I have found out now is that in my Python 2.3.6 encodings/
__init__.py does not contain 'import aliases' at module level,
whereas the Python 2.4 lib has this import. The patch does this:
import encodings
encodings._aliases = encoding.aliases.aliases
which does therefore not work in 2.3. So, now I am curious how your
Python 2.3 differs, and why you don't see the error locally :-)
On my system, the aliases get imported during a codec lookup for
'iso-8869-1': not at Python startup, but early in the test run, while
finding tests.
- --- % --
- --- encodings/__init__.py 2008-08-29 12:18:18.0 -0400
+++ encodings/__init__.py.debug 2008-08-29 12:18:13.0 -0400
@@ -83,6 +83,7 @@
mod = __import__('encodings.' + modname,
globals(), locals(), _import_tail)
except ImportError:
+import pdb; pdb.set_trace()
import aliases
modname = (aliases.aliases.get(modname) or
aliases.aliases.get(modname.replace('.', '_')) or
@@ -125,6 +126,7 @@
except AttributeError:
pass
else:
+import pdb; pdb.set_trace()
import aliases
for alias in codecaliases:
if not aliases.aliases.has_key(alias):
- --- % --
At that point, 'aliases' is added to the module's globals. Maybe this
doesn't happen for you because you have a different 'site.py' which
pre-establishes that codec?
At any rate, we should make the patch harder against this case.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIuCHf+gerLs4ltQ4RAtMCAKC0fBvDBNoR0NC4qwGKM3Fvqo7SDgCfZXfQ
mKLNaD78vXiUTDCZVRb/+NQ=
=YxJH
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Failing Zope 2.8 / Python 2.3 tests on your box
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Pieters wrote: On Fri, Aug 29, 2008 at 14:05, Stefan H. Holek [EMAIL PROTECTED] wrote: What I have found out now is that in my Python 2.3.6 encodings/ __init__.py does not contain 'import aliases' at module level, whereas the Python 2.4 lib has this import. The patch does this: import encodings encodings._aliases = encoding.aliases.aliases which does therefore not work in 2.3. So, now I am curious how your Python 2.3 differs, and why you don't see the error locally :-) The 1.1 version of the hotfix corrected this. Maybe, but the integration of it into the Zope-2.8 branch didn't solve the problem. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuCIj+gerLs4ltQ4RAkMVAJsGeKUZtakPRHxZ0lM78mNBf+1acACgqhSt MJgLf+FVjSuwXaHDdfTZnC0= =AaEv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
On Fri, Aug 29, 2008 at 5:13 PM, Malthe Borch [EMAIL PROTECTED] wrote: Log message for revision 90599: Move test-dependencies to 'extras'. This is a controversial change; can we avoid making changes like this until a policy is agreed upon? The controversy surrounding this has been discussed on zope-dev several times; I don't want to rehash it *right now*, since we all have things we need to get done. -Fred -- Fred L. Drake, Jr. fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
Fred Drake wrote: This is a controversial change; can we avoid making changes like this until a policy is agreed upon? The controversy surrounding this has been discussed on zope-dev several times; I don't want to rehash it *right now*, since we all have things we need to get done. I didn't know there was a controversy, but I do remember that there was consensus that ``extras_require`` is not the most elegant solution. If you can advise a different way to avoid pulling in ``zope.app.testing`` I'm happy to revert the change; otherwise I think we should live and let live with it since it at the very least does the job. Or just revert the change and let Zope have its many dependencies. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
On Fri, Aug 29, 2008 at 5:26 PM, Malthe Borch [EMAIL PROTECTED] wrote: I didn't know there was a controversy, but I do remember that there was consensus that ``extras_require`` is not the most elegant solution. Oh, there is! If you can advise a different way to avoid pulling in ``zope.app.testing`` I'm happy to revert the change; otherwise I think we should live and let live with it since it at the very least does the job. There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I'd suggest reverting the change for now. -Fred -- Fred L. Drake, Jr. fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
Fred Drake wrote: There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I understand, but this particular dependency pulls in the world, all 76 packages. I'll revert the change; it seems we're about to have a fork the size of the emacs/xemacs conflict, because for projects like repoze.bfg, dependency hell is no longer acceptable. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Move test-dependenciesto 'extras'.
Hi Fred Betreff: Re: [Checkins] SVN: zope.dublincore/trunk/ Move test-dependenciesto 'extras'. On Fri, Aug 29, 2008 at 5:13 PM, Malthe Borch [EMAIL PROTECTED] wrote: Log message for revision 90599: Move test-dependencies to 'extras'. This is a controversial change; can we avoid making changes like this until a policy is agreed upon? The consensus was to move the testing dependencies to extras_require. We really need to get rid of loading zope.app.testing as a core package for our production applications. install_requires only needs to install what is needed for production. I really like to do the next couple weeks and month some cleanup work and this is a fundamental part. The controversy surrounding this has been discussed on zope-dev several times; I don't want to rehash it *right now*, since we all have things we need to get done. come on, that's a real bad answer and will only stop others from doing the right thing for you. We can't take care on everybody if we do cleanup work. And you have always the option to relay on the KGS or other egg versions. Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
On Fri, Aug 29, 2008 at 11:59:24PM +0200, Malthe Borch wrote: Fred Drake wrote: There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I understand, but this particular dependency pulls in the world, all 76 packages. I'll revert the change; it seems we're about to have a fork the size of the emacs/xemacs conflict, because for projects like repoze.bfg, dependency hell is no longer acceptable. So either let's make zope.app.testing not depend on the whole world, or let's extract the core of zope.app.testing and put it somewhere else (zope.testing?). Marius Gedminas -- Some performers on television appear to be horrible people, but when you finally get to know them in person, they turn out to be even worse. -- Avery signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependenciesto 'extras'.
Hi Betreff: Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependenciesto 'extras'. Fred Drake wrote: There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I understand, but this particular dependency pulls in the world, all 76 packages. I'll revert the change; it seems we're about to have a fork the size of the emacs/xemacs conflict, because for projects like repoze.bfg, dependency hell is no longer acceptable. Yes, I agree, The same is true for our z3c.* based projects. Regards Roger Ineichen \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Movetest-dependencies to 'extras'.
Hi Marius Betreff: Re: [Zope-dev] SVN: zope.dublincore/trunk/ Movetest-dependencies to 'extras'. [...] I understand, but this particular dependency pulls in the world, all 76 packages. I'll revert the change; it seems we're about to have a fork the size of the emacs/xemacs conflict, because for projects like repoze.bfg, dependency hell is no longer acceptable. So either let's make zope.app.testing not depend on the whole world, or let's extract the core of zope.app.testing and put it somewhere else (zope.testing?). +1 Yes, we need both, We need to move some parts from zope.app.testing to the right packages and we need to remove zope.app.testing as a general dependency from some packages. Regards Roger Ineichen Marius Gedminas -- Some performers on television appear to be horrible people, but when you finally get to know them in person, they turn out to be even worse. -- Avery ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: On Fri, Aug 29, 2008 at 5:26 PM, Malthe Borch [EMAIL PROTECTED] wrote: I didn't know there was a controversy, but I do remember that there was consensus that ``extras_require`` is not the most elegant solution. Oh, there is! If you can advise a different way to avoid pulling in ``zope.app.testing`` I'm happy to revert the change; otherwise I think we should live and let live with it since it at the very least does the job. There's no good way to avoid dependencies like zope.app.testing; because that's part of the test environment, the tests won't show whether there are problems when it's removed. If you want to fly what you test, test dependencies can't be eliminated. I don't want to have to run the tests for 'zope.dublincore' in *every* system which uses it: I want to test 'zope.dublincore' in isolation, and then use a well-tested, known good version of it in other applications, which may not need or want the 'zope.app.testing' dependency. If zc.buildout would grow support for either 'tests_require' or a special 'extras_require' key, you could still have what you want without forcing it on the rest of the world. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIuIjO+gerLs4ltQ4RAq7MAJ0QU/OZGj+paO1dqp/iIsQ832UyfwCfd4ch UmvWo2czCKJsVW5VlMz9pt8= =W9vk -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and strict namespace mapping
Previously Malthe Borch wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). +1 for requiring proper XML namespace. Tools like xmllint which are incredibly practical to validate your templates require this as well. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Chris Withers wrote at 2008-8-29 10:25 +0100:
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional parameters --
what a simplification and homogenization :-)
Yeah, but since when has simplification or homogenisation been a goal of
Zope 3? ;-)
It was with the Service geddon: make Service and Utility homgogenous.
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
