[Zope-dev] Object schema field validation
I stumbled upon a problem with Object schema field validation. The problem occurs, e.g., if the the Object field's schema itself contains a Choice field with a dynamically computed vocabulary. For the latter to validate correctly the field must be bound to the instance. But the Object field validation code in zope.schema._fields._validate_fields validates the attributes of the Object field instance without binding them first: def _validate_fields(schema, value, errors=None): ... try: attribute = schema[name] if IField.providedBy(attribute): # validate attributes that are fields attribute.validate(getattr(value, name)) except ValidationError, error: ... Replacing the line attribute.validate(getattr(value, name)) with field = attribute.bind(value) field.validate(getattr(value, name)) fixes the problem. Looks like a bug to me. Regards, Markus Kemmerling ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Sat Nov 28 12:00:00 2009 UTC to Sun Nov 29 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Nov 28 20:39:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013101.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Nov 28 20:41:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013102.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:43:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013103.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:45:31 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013104.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:47:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013105.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Nov 28 20:49:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-November/013106.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
Tim Hoffman wrote: Just re-inforcing this I almost never do IFoo. adaption as I am almost always using multiadapters and utilities so I completely forget about the IFoo adaption capability. Which means I always just write getAdapter as well as it seems more consistent to from an api consumption point of view. I use the IFoo(x) to invoke an adapter (and IFoo(x, None) lookup for a fallback) a *lot*. As in, virtually in every piece of (Zope) software I write. I've also encouraged people to do that in at least three major pieces of documentation (including my book). Similarly, answering a different part of this thread: I use custom adapter factories from time to time, and have documented them as useful practice. Normally, that's because I want to look up the adapter implementation from someplace else than the global registry (e.g. plone.portlets fishes a persistent object out of an annotation at one point), or because I want the ability to abort the annotation by returning None (plone.behavior does that - actually, plone.behavior is a good example of the former also). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
Martijn Faassen wrote: Multi-adaptation: IFoo(one, two) Please note that this will break an incredible amount of code in the wild. A good number of my packages do something like this: foo = IFoo(context, None) if foo is None: ... There is a lot of documentation out there (including at least three books in print) encouraging this pattern, too. How is someone reading an old document supposed to know what's going on when the semantics of this call suddenly changes radically? I love all the other suggestions. In my book, this one would be an incompatibility too far, though. I think the version of passing a tuple would be a better compromise, not at least because there's only a very small number of people who will've attempted to single-adapt a tuple (or a tuple sub-class). Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really something fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. +1 Features off the table for now --- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. Agreed, but we should tackle those in a separate proposal. Backwards compatibility --- Now let's get back to my favorite topic in this discussion: backwards compatibility. The ideal semantics unfortunately break backwards compatibility for the single adapter lookup case, as this supports a second argument, the default. The challenge is therefore to come up with a way to support the new semantics without breaking the old. We could introduce the following upgrade pattern: zope.component 3.8.0: old semantics zope.component 3.9: old semantics is the default. new semantics supported too somehow but explicitly triggered. zope.component 4.0: new semantics is the default. Old semantics is not supported anymore. We could, if needed, maintain zope.component 3.x in parallel with the new-semantics 4.0 line for a while. -1 Because we now have so many packages and things are being released as eggs and mixed up in various platforms and projects, this type of gross backwards incompatibility is virtually impossible to manage. To take an example, I'm sure Stefan co will release z3c.form 3 depending on zope.component 4 before long, and we'll want to use that in Plone. Except we can't, because even if z3c.form never uses the IFoo(one, two) syntax, everything in Plone that uses IFoo(context, None) would suddenly break. I'm sorry, but I think the ship on perfect API has sailed. We have to own up to our past decisions and compromise, at least on the patterns that are widely used, and where there is almost certain confusion and failure. I think Jim said once, we can't ever have backwards incompatibility. Other serious platforms like Java or .NET have a similar stance. They deprecate liberally, but never actually break anything. (Remember java.util.Data and java.util.Calendar?) We may never be able to do that completely, and we may *want* to root out some dodgy bits of code that few people use. But breaking something so fundamental and so commonly used would be criminal, in my book. A per-module triggering of the new semantics might be done like this: from zope.component.__future__ import __new_lookup__ Is that implementable at all however? Someone needs to experiment. Alternatively we could do something special when we see this: IFoo(foo, bar). This is ambiguous - is the new semantics in use or the old one? If the adapter cannot be looked up using multi adaptation we *could* fall back on single adaptation under the assumption that the old semantics are desired. But this will lead to a problem if the new semantics *was* desired but the component simply could not be found. This is probably the minimum I'd be prepared to accept, personally. It's ugly and risky still, but at least it'll cover the 90% use case. I still don't like it, though. I think it's important not to do a big bang upgrade but instead allow people to upgrade bit by bit. It should be possible to compose an application that mixes code that expects the old semantics with code that expects the new semantics. A bit by bit upgrade I think would ideally be on a per-module basis. I think it's important to make sure we can support such an upgrade
Re: [Zope-dev] implementing zope.component 4.0
Hello Hanno, Seems that that was an adapter heavy app. Was before the cut: len(getGlobalSiteManager()._utility_registrations) 980 len(getGlobalSiteManager()._adapter_registrations) 1432 len(getGlobalSiteManager()._handler_registrations) 63 len(getGlobalSiteManager()._subscription_registrations) 50 After the cut: len(getGlobalSiteManager()._utility_registrations) 739 len(getGlobalSiteManager()._adapter_registrations) 933 len(getGlobalSiteManager()._handler_registrations) 37 len(getGlobalSiteManager()._subscription_registrations) 33 So around 1/3 of the registrations was gone and that made a difference (well, with z3c.form generated forms). Would be interesting to profile how many adapter lookups are done by a simple z3c.form to render... Saturday, November 28, 2009, 2:32:50 PM, you wrote: HS On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen HS faas...@startifact.com wrote: Adam GROSZER wrote: I had a feeling that adapter lookup can be alone slowish with lots of registrations. We had a large project that was cut in half and the z3c.form UI, which is rather heavily adaptation based got a boost after that. HS What is a large project in your case? Just as an example here's the HS size of the global registry in a typical Plone project: getGlobalSiteManager() HS BaseGlobalComponents base len(getGlobalSiteManager()._utility_registrations) HS 1091 len(getGlobalSiteManager()._adapter_registrations) HS 1283 len(getGlobalSiteManager()._handler_registrations) HS 139 len(getGlobalSiteManager()._subscription_registrations) HS 3 Interesting. It'd be interesting to do some experiments with this. Could you perhaps look into writing some kind of stress-test script? HS I haven't done any real performance measurements but the various HS zope.interface/component API's are among the top of every profile run HS I do in Plone. HS To me it looks like checking if an interface is provided by a context HS is non-trivial and the main bottleneck in our case. The classes HS underlying our typical contexts are pretty fat classes with a long HS inheritance chain contributing dozens of interfaces. HS The actual registry lookups seem to be rather fast, they should be HS essentially dict lookups, which perform well with a dict size of just HS about 1000. HS On the other hand I noticed that z3c.form and it's use of the ZCA is HS indeed much slower than stitching forms together via ZPT macros as HS done for example by Archetypes. HS Hanno HS ___ HS Zope-Dev maillist - Zope-Dev@zope.org HS https://mail.zope.org/mailman/listinfo/zope-dev HS ** No cross posts or HTML encoding! ** HS (Related lists - HS https://mail.zope.org/mailman/listinfo/zope-announce HS https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: The only way to amuse some people is to slip and fall on an icy pavement. ___ 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] implementing zope.component 4.0
* Martijn Faassen faas...@startifact.com [2009-11-27 12:32]: Are people okay with the proposed semantics? +1, I think making these disappear into the language as much as possible is a Good Thing(tm). Would people be okay with such an upgrade path? Any better ideas? Yes, I'm okay with it. I do think we should take care that the transition period is long enough, so that people have a chance to update their code. (The deprecation warnings proposed elsewhere should help there, I think this is a good use case for them.) Thus, we should not start requiring zope.component 4.0 everywhere immediately (because it's new, great and shiny ;), but rather use 3.9+future when we want to use the new semantics, and only after I don't know, 6 months maybe, start switching over completely. Most importantly, any volunteers? I'm interested, but I'm not sure whether I'll have free resources in the near future. :-/ Wolfgang ___ 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 )
