[Zope-dev] zope-tests - FAILED: 22, OK: 44
This is the summary for test reports received on the zope-tests list between 2012-01-25 00:00:00 UTC and 2012-01-26 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received [1]ZTK 1.0 / Python2.4.6 Linux 64bit [2]ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit [3]ZTK 1.0dev / Python2.4.6 Linux 64bit [4]ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit [5]ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit [6]ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 [7]Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 [8]Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 [9]Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 [10] Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 [11] Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 [12] Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 [13] Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 [14] Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 [15] Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 [16] Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 [17] Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 [18] Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 [19] Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 [20] Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [21] winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 [22] winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED ZTK 1.0 / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/056803.html [2]FAILED ZTK 1.0 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/056805.html [3]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/056812.html [4]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/056814.html [5]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/056801.html [6]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/056811.html [7]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/056831.html [8]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/056822.html [9]FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/056834.html [10] FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/056824.html [11] FAILED Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/056836.html [12]
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
On Thu, Jan 26, 2012 at 04:02:54PM +0200, Jan-Carel Brand wrote: > On Wed, 2012-01-25 at 18:56 +0100, Souheil CHELFOUH wrote: > > A quick note : > > > > This quite an advanced vocabulary, why not make another package with a > > dependency on zope.schema ? > > I don't quite see the point to have that in the "core". > > Ok, Charlie also expressed his reservations. I'll put it in a different > package then. > > I'm not too sure what to name it though. For example, under what > namespace? zope or z3c? My gut feeling says "z3c". OTOH I don't think a single class warrants a whole separate PyPI package. Especially if it's going to be used with z3c.form (hint, hint ;) or that collective.forgotthenamealready you mentioned upthread. > I'm guessing zope.vocabulary, or rather zope.treevocabulary? (Or z3c.treevocabulary) But I'd rather see this in zope.schema. Incidentally, since this would be a new feature, it would need a minor version bump in setup.py (4.0.2dev -> 4.1dev). > > Furthermore, for the dict class in use in the vocabulary, you could > > add a "factory" class that can be overriden easily. > > That would allow people with OrderDict capabilities to use them > > without having to re-sort later on. > > Could you please elaborate on what you mean? I think he meant something like class TreeVocabulary(object): # you can subclass and use OrderedDictionary instead dict_factory = dict This would mean that you can't subclass dict and would instead have to delegate __getitem__, __iter__, __len__, keys, values, items and all the rest by hand. I'm actually feeling a bit guilty about raising this question. As I said, I don't have a use-case for ordered TreeVocabularies myself. (Or unordered ones either, for that matter ;) The only reason for hashing this out now is to avoid painful API changes if we ever decide that we need those. Feel free to cry YAGNI at any time. It's already hard enough to contribute to zope3-or-is-it-bluebream-or-is-it-ztk-aaaugh as it is, without us adding extra barriers in place. > If I create a factory class to create TreeVocabulary instances, how will > overriding that factory (without creating a separate > SortableTreeVocabulary) allow people to use OrderedDict? > > Incidentally, I came upon this: http://pypi.python.org/pypi/ordereddict > which provides the OrderedDict to Python 2.4 to 2.7 Oh, neat. I've used http://pypi.python.org/pypi/odict in the past, but it doesn't have the blessing of stdlib'ness. > I think it might make sense to just subclass OrderedDict and implement > an ordered tree from the start. > > By the way, good work on that, it's something that is often needed in > > advanced forms. I'll make sure to try it. > > Thank you for the effort. > > Thanks! Much appreciated. Thanks! Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hiya, Am 26.01.2012, 15:02 Uhr, schrieb Jan-Carel Brand : Ok, Charlie also expressed his reservations. I'll put it in a different package then. Hang on a minute! While I'm not 100 % convinced of the need in the core I think a separate package just for TreeVocabulary would be splitting hairs. If z3c.form can use it then I think that is justification enough. I'm not too sure what to name it though. For example, under what namespace? zope or z3c? I'm guessing zope.vocabulary, or rather zope.treevocabulary? Furthermore, for the dict class in use in the vocabulary, you could add a "factory" class that can be overriden easily. That would allow people with OrderDict capabilities to use them without having to re-sort later on. Could you please elaborate on what you mean? If I create a factory class to create TreeVocabulary instances, how will overriding that factory (without creating a separate SortableTreeVocabulary) allow people to use OrderedDict? Incidentally, I came upon this: http://pypi.python.org/pypi/ordereddict which provides the OrderedDict to Python 2.4 to 2.7 I think it might make sense to just subclass OrderedDict and implement an ordered tree from the start. I agree. Despite my previous remark about class methods, I don't think we need to worry much about Python 2.4 and 2.5 and ordered dictionaries are just so damn useful that they've been added to the standard library. Back to bike-shedding. As I was intrigued by the whole thing I've spent some time looking at the code. I'm not too happy on the use of nested functions as I find they obscure code, particularly when used recursively. I think that "createTree" and "recurse" should be written as separately testable generators. I also don't see a need for createTerm in this particular class and the subsequent awkward call from createTree. As it stands it is copy & paste both in method and test. If you must have it with the same implementation createTree = SimpleVocabulary.createTree does the job just fine but I don't see the advantage of cls.createTerm(*args) over SimpleTerm(*args) As I said this is bike-shedding but I think our source code should be written with a view to being read and probably copied verbatim. With that in mind I prefer readability and testability over integration. In the end it tends to make things easier to use. The exceptions where refactoring to produce slightly uglier code but with significant performance hopefully prove the rule. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TreeVocabulary in zope.schema.vocabulary
Hi Souheil On Wed, 2012-01-25 at 18:56 +0100, Souheil CHELFOUH wrote: > A quick note : > > This quite an advanced vocabulary, why not make another package with a > dependency on zope.schema ? > I don't quite see the point to have that in the "core". Ok, Charlie also expressed his reservations. I'll put it in a different package then. I'm not too sure what to name it though. For example, under what namespace? zope or z3c? I'm guessing zope.vocabulary, or rather zope.treevocabulary? > Furthermore, for the dict class in use in the vocabulary, you could > add a "factory" class that can be overriden easily. > That would allow people with OrderDict capabilities to use them > without having to re-sort later on. Could you please elaborate on what you mean? If I create a factory class to create TreeVocabulary instances, how will overriding that factory (without creating a separate SortableTreeVocabulary) allow people to use OrderedDict? Incidentally, I came upon this: http://pypi.python.org/pypi/ordereddict which provides the OrderedDict to Python 2.4 to 2.7 I think it might make sense to just subclass OrderedDict and implement an ordered tree from the start. > By the way, good work on that, it's something that is often needed in > advanced forms. I'll make sure to try it. > Thank you for the effort. Thanks! Much appreciated. J-C > > - Souheil > > 2012/1/25 Marius Gedminas : > > On Wed, Jan 25, 2012 at 01:55:28AM +0200, Jan-Carel Brand wrote: > >> On Wed, 2012-01-25 at 00:52 +0200, Marius Gedminas wrote: > >> > On Tue, Jan 24, 2012 at 07:34:03PM +0200, Jan-Carel Brand wrote: > >> > > I now subclass PersistentMapping instead of SimpleVocabulary, so this > >> > > is > >> > > not an issue anymore. > >> > > >> > Ok. But why Persistent? None of the other vocabularies are > >> > persistent... > >> > >> Yeah, using PersistentMapping was a mistake, firstly because persistence > >> is not necessary and secondly because it introduces a dependency on > >> Persistence. > > <...> > >> > > I've changed the TreeVocabulary to subclass from PersistentDict. So the > >> > > vocabulary itself now acts as a dict. > >> > > >> > So is it PersistentMapping or PersistentDict then? ;) > >> > >> It was first the one, and then the other :) > > > > For extra fun: one is an alias for the other in newer ZODB versions. > > > >> > > > > Perhaps I should rephrase :) > >> > > > > > >> > > > > I would like my changes to be merged with the zope.schema trunk. > >> > > > > The > >> > > > > tests I've added provide 100% coverage of the TreeVocabulary code. > >> > > > > > >> > > > > I would just like someone to sign it off. > >> > > > > >> > > > -1 because of the concerns above. > >> > > > >> > > Fair enough. Have your concerns been addressed properly? > >> > > >> > Thank you, yes. > >> > > >> > I'm still wondering about the possibility of ordered trees. > >> > >> Python 2.7 has an OrderedDict class in the collections module: > >> http://docs.python.org/dev/whatsnew/2.7.html#pep-0372 > > > > Yes. And if I pass an OrderedDict to your .fromDict(), it will be > > discarded and all the items inserted into a regular dict, forgetting > > their original order. > > > > But anyway, I'm fine with you saying "explicit ordering is not > > supported; it's up to the widget to sort each tree level appropriately". > > In the class docstring, say. ;-) > > > >> > And I'm -1 for subclassing PersistentMapping. It may tempt people into > >> > storing tree vocabularies in the ZODB, and then maybe even modifying > >> > them. And you have plenty of non-persistent dicts in the internal > >> > structure. > >> > > >> > I think it would be better to subclass a regular dict, and document that > >> > you ITreeVocabulary is a dict-like object by making it inherit > >> > IEnumerableMapping. > >> > >> Thanks for the suggestion, I did that. > > > > I've no objections remaining (other than that little thing about > > explicit ordering). > > > > Marius Gedminas > > -- > > http://pov.lt/ -- Zope 3/BlueBream consulting and development > > > > ___ > > Zope-Dev maillist - Zope-Dev@zope.org > > https://mail.zope.org/mailman/listinfo/zope-dev > > ** No cross posts or HTML encoding! ** > > (Related lists - > > https://mail.zope.org/mailman/listinfo/zope-announce > > https://mail.zope.org/mailman/listinfo/zope ) > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
