[Zope3-dev] DisplayWidget
Is there any reason why zope.app.form.browser.widget.DisplayWidget doesnt implement zope.app.form.interfaces.IDisplayWidget, or is this a bug? - Shaun ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zodb __parent__ and weakref
Chris, You need to get into the habbit of CC'ing in the list you're replying too... Sorry -- I was thinking that, if this was not a problem w/ ZODB and external objects, but I've missed something in implementation, maybe I should have been communicating on Zope3-users instead. Now I don't know if I've communicated clearly enough to conclude this yet. [EMAIL PROTECTED] wrote: The data is in Postgres, but I already have a python data marshalling/demarshalling/business logic used by other processes, so I want to use this interface with ZOPE as well. Okay, and what is this interface? Do you want to see the *whole* interface ? :) I would think it would suffice to say: it has interfaces to query the database and return python objects constructed from the data, and various business logic interfaces that trigger creation of new data in the database. Zope is only one client. Others will be interacting with the database. Should I be trying to inherit from Persistent rather than __getstate__, __setstate__? ... perhaps there is a way as flagging a member volatile?... Or that I want to control refresh myself? I don't see what implementing IContainer has to do with Persistent, __getstate__ or __setstate__... or am I missing something? I'm only implementing a prototype now, but in production, the database will have =30 million objects in it after 2 years of use. For this reason, and because the db will be changing outside, it doesn't seem sensible to store the db objects in ZODB. This was also the opinion in zope3-users when I asked about this earlier. Instead I want to have a container which queries the database for data itself, but avoids having these objects be put in the zodb, even if it itself is in the zodb. You are saying that it isn't a good approach to implement __getstate__ and __setstate__... but I don't see why this should be so? Can anyone explain why they are called so often? It seemed from other threads that the danger would rather be that your data doesn't get stored at all if you don't explicitly set _p_changed (or whatever its called) I've attached a version of my attempted implementation (cleaned up from the post in [Zope3-Users] newbie design questions for UI to external data. I thought that overriding __getstate__ and __setstate__ simply overrides pythons default versions of these, which would be called just as often as my versions. I guess perhaps the default versions are especially efficient because they just pass the instance dictionary back and forth(? -- but then what does ZODB do with the instance dictionary? Why does it ask for it if the object itself is ok?) Don't worry about any of these things, just don't try and implement anything funky, you don't need to and you're likely to get hurt, as you've found... How should I implement this differently, or what bad assumptions am I making? To my mind, __getstate__ and __setstate__ are the normal way to control persistence in pickle-using python, so funky is in the eye of the beholder. - Shaun Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zodb __parent__ and weakref
Opps,
The code I said would be attached...
-Original Message-
From: [EMAIL PROTECTED]
[mailto:zope3-dev-
[EMAIL PROTECTED] On Behalf Of Shaun Cutts
Sent: Friday, February 24, 2006 10:18 PM
To: 'Chris Withers'; [EMAIL PROTECTED]; 'zope3-dev'
Subject: RE: [Zope3-dev] zodb __parent__ and weakref
Chris,
You need to get into the habbit of CC'ing in the list you're
replying
too...
Sorry -- I was thinking that, if this was not a problem w/ ZODB and
external objects, but I've missed something in implementation, maybe I
should have been communicating on Zope3-users instead. Now I don't
know
if I've communicated clearly enough to conclude this yet.
[EMAIL PROTECTED] wrote:
The data is in Postgres, but I already have a python data
marshalling/demarshalling/business logic used by other processes, so
I
want to use this interface with ZOPE as well.
Okay, and what is this interface?
Do you want to see the *whole* interface ? :) I would think it would
suffice to say: it has interfaces to query the database and return
python objects constructed from the data, and various business logic
interfaces that trigger creation of new data in the database.
Zope is only one client. Others will be interacting with the database.
Should I be trying to inherit from Persistent rather than
__getstate__,
__setstate__? ... perhaps there is a way as flagging a member
volatile?...
Or that I want to control refresh myself?
I don't see what implementing IContainer has to do with Persistent,
__getstate__ or __setstate__... or am I missing something?
I'm only implementing a prototype now, but in production, the database
will have =30 million objects in it after 2 years of use. For this
reason, and because the db will be changing outside, it doesn't seem
sensible to store the db objects in ZODB. This was also the opinion in
zope3-users when I asked about this earlier.
Instead I want to have a container which queries the database for data
itself, but avoids having these objects be put in the zodb, even if it
itself is in the zodb.
You are saying that it isn't a good approach to implement __getstate__
and __setstate__... but I don't see why this should be so? Can anyone
explain why they are called so often? It seemed from other threads
that
the danger would rather be that your data doesn't get stored at all if
you don't explicitly set _p_changed (or whatever its called)
I've attached a version of my attempted implementation (cleaned up
from
the post in [Zope3-Users] newbie design questions for UI to external
data.
I thought that overriding __getstate__ and __setstate__ simply
overrides
pythons default versions of these, which would be called just as
often
as
my versions. I guess perhaps the default versions are especially
efficient
because they just pass the instance dictionary back and forth(? --
but
then what does ZODB do with the instance dictionary? Why does it ask
for
it if the object itself is ok?)
Don't worry about any of these things, just don't try and implement
anything funky, you don't need to and you're likely to get hurt, as
you've found...
How should I implement this differently, or what bad assumptions am I
making? To my mind, __getstate__ and __setstate__ are the normal way
to
control persistence in pickle-using python, so funky is in the eye
of
the beholder.
- Shaun
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-
dev/shaun%40cuttshome.net
class HollowContainer( IterableUserDict, Contained ):
Implements L{IHollowContainer}
Strategy: for add and delete, notify the database directly; for
update of contained object, however, we want to listen for
ObjectModifiedEvent. This is better than getting a notification
from the objects, as an edit form may set several fields, and then
send the notification when done; so the event can be treated as a commit
Keys: _iserial is key to objects in dictionary
from zope.interface.verify import verifyClass
verifyClass( IHollowContainer, HollowContainer )
True
implements( IHollowContainer, INameChooser )
# defaults for IHollowContainer
database = None
containedInterface = None
# defaults for ILocation (base of IHollowContainer)
__parent__ = None
__name__ = None
def __init__( self ):
super( HollowContainer, self ).__init__( )
self.__setstate__()
def __setitem__( self, key, obj ):
Implements L{cranedata.web.interfaces.IFundContainer.__setitem__}.
if key in self.data:
raise DuplicationError( key %s already present )
self.add( obj )
def add( self, obj ):
obj
RE: [Zope3-dev] zcml abbreviations
Could we call it obfuscate instead, so we know what it does? :-) I take it that's a no vote from you :) But I think it can be sensibly used. There are many places in the zcml defs where there are long blocks of repetitive definitions where only a few names change. If the number of directives is seriously paired back, these blocks are likely to get longer and more repetitive. If you set the abbreviation at the top of the block, then your eye can see the important parts that actually change in the following section of expands. And if there is something wrong with the definition, you can change it all in one place. Of course, you could also use it to make things confusing if you wanted to too. But if you really want to make things confusing, new zcml directives are more effective. ;-) - Shaun ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] zodb __parent__ and weakref
Chris, -Original Message- From: Chris Withers [mailto:[EMAIL PROTECTED] Shaun Cutts wrote: When a container gets pickled to be put into zodb, what happens to the subtree? If the container has references to stuff that is contains, one of two things could happen: 1. If the contents subclass persistent, then they will end up in their own pickle in the zodb and will be made persistent 2. If they don't, they will still be persisted but will end up in the container's pickle in the zodb. Is it just left as a big clump of stuff for the garbage collector to deal with? As with all object, not until nothing references it ;-) What I mean is this: assume that a subtree is *not* referenced anywhere else. It seemed to me that, every time I did a refresh on a container view from the browser, (__getstate__ and then) __setstate__ was called on the container. I would think that means that all the old objects were let go, and new copies were brought in. This would seem to be relatively inefficient to garbage collect that subtree. But it is 2x inefficient to have a tree with lots of cyclic references embedded in it (via __parent__) to garbage collect. However, the situation improves (in the vanilla case where the objects themselves don't have lots of cross references) if __parent__ is a weakref. Then the container, at least, can be immediately deallocated without the garbage collector having to trace the cycles; then the contained objects are also without references, and can be easily garbage collected. Further, it seems that the semantics of the situation dictate that the references from contained.__parent__ to the container should never be the ones keeping the container alive, anyway, as it is part of the tree. But maybe my I'm misinterpreting the calls to __setstate__? It seems unnecessary to call __setstate__ at all, as we already know the copies in memory are fresh. - Shaun ___ 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 3 web root
So my plea is: If we're going to have more than one way to do it, let's please not invent lots of special magical things that just work in one mode of development and have to be laboriously rewritten in the other mode of development. It makes the border between modes of working too hard to cross and makes Zope 2 feel rather un-agile at times. Would it be possible to define a contract for a way to do it: e.g. we always have the tree available; we have annotations on objects; we have access to core system and utilities. Then the core could be provided w/o zodb; the zodb would be a compliant persistence utility, and would interact w/ other objects via their persistence interface or whatever, so that if these other objects followed their own way of doing things they would plug together seamlessly. Excuse me if I'm merely restating the proposal that we are talking about. In my mind way of doing things is still too fuzzy, but perhaps it can be made tighter (or someone else understands it better). But in particular, wrt to Shane's original proposal, the web root would be another compliant persistence utility. A RDBMS store would be another type. So their wouldn't be one root to rule them all, but at any point in the tree a subtree could be provided by a different persistence utility. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zcml abbreviations
It seems to me that some of the tension around zcml arises because, on the one hand, everyone wants it to be as simple as possible, and on the other, too much simplicity of the language makes some things very tedious, which encourages magic shortcuts via new directives. To let out some of the steam, could zcml support a very simple abbreviate directive in over all namespaces? abbreviate name=shortcut variables=x y z / ... some complex boilerplate foo=x ... bar = y baz = z ... /abbreviate Then expand name=shortcut x=spam y=eggs z=more spam / would be equivalent to the abbreviation being expanded. Adding an abbreviation seems to be much less hard to understand than adding a whole new directive: you can grep it and, if you understand the base zcml you can see exactly what the abbreviation does without having to root around in the python code. On the other hand, many dotted names that are constant for a given use can be hidden in the abbreviation. With this *little* extension, it would seem easier to cut back on the rest of the directives, as someone's favourite quick way to do something is more easily removed without howls if they can quickly put it back as an abbreviation. Note I use abbreviate rather than template or macro not only because they are used in other parts of the system, but because they have more sophisticated abilities, whereas abbreviations are limited strictly to name-substitution. - Shaun ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zodb __parent__ and weakref
One thing I havent got my mind around yet: I notice that zodb is fairly active about calling __getstate__ and __setstate__. When a container gets pickled to be put into zodb, what happens to the subtree? Is it just left as a big clump of stuff for the garbage collector to deal with? If so, maybe __parent__ should be a weakref, because tracing around all of the cycles in the tree by the gc must surely be inefficient, and using a weakref here should make the subtrees dissolve more easily. - Shaun ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RE: [Zope3-Users] question: can I make a view trusted: A BUG
Ok everyone: it is a zope bug. The following should be included in zope.app.schema.fields.zcml: content class=zope.schema.Date factory id=zope.schema.Date title=Date Field description=Date Field / require like_class=zope.schema.Orderable / require like_class=zope.schema.Field / /content PS -- Jim -- I sent in my contributor form almost two weeks ago? Have you received it yet? I'd be happy to put this in myself, if I could. - Shaun ___ 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 3 web root
Max M wrote: The problem is that all the people used to LAMP will come to Zope and think Well I will need to think differently here. Thats a bother. I will use sql for everything like usual. And so we will get a lot of duplicated efforts and half-baked Zope developers, who will desperately try to use Zope for SQL development. Because of this concern, I'm putting this off for a while. I think it addresses a major hole in Zope, but it also creates two ways to accomplish similar tasks without a clear division between the two ways. Note that the Python language, despite its philosophy, has at least two ways to accomplish things: with functions or with classes. In this case, two ways are definitely better than one, IMHO. But before Zope acquires a new way to create web sites, we need to better understand whether that's a burden Zope ought to bear. It could turn out that people who don't want ZODB really shouldn't use Zope at all. I would find that conclusion disheartening, but maybe it's realistic. Shane I think that the discussion about whether one could or should completely replace ZODB with SQL is less important than providing good connections to SQL while other things are done with ZODB. (After all -- python provides functions and classes, but it never says: either develop only with one or the other!) In my application it is perfectly clear (for the moment at least:)) what things are part of the UI/application interface (ZODB) and what things are data that needs ACID transactions, write-ahead logging and ODBC (Postgres). In general, many people who use relational databases do so for a good reason. I once worked on a project where we had to rip out ObjectStore after much frustration delay and expense for scalability reasons. What I'm having to write myself in this project, would have liked to have had, and perhaps wouldn't mind contributing to ZPL versions, are containers that allow one to open a window on the SQL world rather seamlessly. As it turns out, I've already done my object marshalling because our system has a Twisted/spread interface as well, so I didn't need SQL specific object marshalling (though a way of mapping annotations to DB would have been nice, as I hadn't included that in DB design). Rather, I just need containers that know that their contents live out there somewhere in a transaction based system that is itself responsible for object keys. - Shaun ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zcml in config db?
Hello, Im new here.. almost certainly these comments are off-base then again, sometimes an idea from outside can be helpful. So heres a crazy thought before I go to bed. I wonder if the configuration done by zcml might not be better if it resided inside a ZODB, and was manipulable at runtime, and more importantly separate from the source code. It couldnt be the normal instance zodb, but rather sort of like a classinfo zodb that took care of all the linkage info. Of course, the system would have to be made a bit more robust so it stays up when modules w/ syntax errors are loaded, for example. The biggest reason: I can imagine that when deploying a package, various configurations, for instance security, but also adding internationalization, have to be adapted for the specific site. This way, they could be deployed without access/change to the source tree (after it has been plunked down in the python path), and further customization could be done, if necessary, remotely. Also, sites that have to stay up could be reconfigurable on the fly (though one would have to be careful about disabling the core system!). Also, those pythonistas who object to zcml not being in python will have less to see when they complain. This at least drives home the point that this config isnt logically part of the code. :) Zcml would stick around as an import/export/diagnostic/backup tool. - Shaun ___ 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 3 web root
Martin, Here here! I'm just learning to cross the gap starting from the RDBMS side. Just our initial deployment will have a DB growing by about 30K numbers per day, day in and day out. There are various workflows that are driven by this data. The parts of these that need people are now supposed to be available via Zope3. In my case, the business logic is in python, so I don't need (or want) to access the db directly, but I do need hollow, paged containers that live in the ZODB themselves but display data that lives elsewhere. I've started implementation, (... stumbling along so far... any comments on: Re: [Zope3-Users] newbie design questions for UI to external data would be welcome!) - Shaun -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Aspeli Sent: Monday, February 13, 2006 5:37 PM To: zope3-dev@zope.org Subject: [Zope3-dev] Re: Zope 3 web root On Mon, 13 Feb 2006 07:51:34 -, Chris Withers [EMAIL PROTECTED] wrote: Scripts and RBDMS are the fast food of the web development world, not the salad. Looks nice, tastes great, eventually leaves you fat and unhealthy. ZODB and maybe an ORM is the greens for me, it might not be to everyone's taste at first, but it's the best option in the long run... I think that's certainly true for content-centric applications, which is what people seem to build the most of in Zope. But if you were storing 80 million records of numbers and short strings that you needed to query across multiple dimensions, you'd probably put them in postgresql. Zope 3 should really have a better story on SQL. Not replace the ZODB, but show how in your code you best deal with an RDBMS. I think that should leverage existing python APIs and ORM tools (I think there's a place for both SQL-style queries and ORM, depending on how much you need ad-hoc queries or at least complex, one-off representations of data, and how much you need one logical view of your data), but there should be patterns and integration layers (if needed) to show how to get data from an RDBMS into a view, how to make an edit form for that data, and how to integrate that with the rest of your probably content-centric application. Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/shaun%40cuttshome.net ___ 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.schema: defaults for non-immutables... questions
Stephan, By delegation support I mean support for being a proxy for an interface, and delegating its fulfillment to a subobject. For instance (by example): class ISomeContainer( Interface ): ... class ISoup( Interface ): ... class SomeContainer: implements( ISomeContainer ) class SoupedUpContainer: implements( ISomeContainer, ISoup ) delegateToInstanceAttribute( ISomeContainer, 'theContainer' ) def __init__( self ): self.theContainer = SomeContainer() What delegateToInstanceAttribute does is use __metaclass__ to create member functions in the SoupedUpContainer interface to implement the ISomeContainer interface by calling the functions on getattr( self, 'theContainer' ) delegateToClassAttribute would create classmethod members that did the same, except they delegated to a class attribute. (Note -- these names are more descriptive, but long-winded.) In my experience, it is quite common to want to delegate one interface but not another. Currently, even automating this outside of zope.interface now takes messing around with the advise internals, as a custom metaclass is called before the class interfaces are set up, where here we want to do the delegation afterwards. But some mechanism would be very useful, as proxying code is repetitive and thus boring and easy not to maintain. ... I will work up a proposal on this at some point, and post about it to the zope.interface list (which I had overlooked). I just wanted to explain what I meant in case it caught your fancy. As for the separation of zope.interface and zope.schema, I don't really feel Strongly; I just wanted to know why it was done the way it was done. If zope.interface provided better hooks (e.g. in advise) that would make implementing non-core features elsewhere easier. -Original Message- From: Stephan Richter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 07, 2006 5:15 AM To: zope3-dev@zope.org Cc: Shaun Cutts Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions On Monday 06 February 2006 11:53, Shaun Cutts wrote: I've thought of several things I'd like to see in it The biggest would obviously be (optional) type checking of method calls, together with a more robust Method definition. Yes, there has been suggestions in this direction before. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/MethodS pecification http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Specifi cationUnification Obviously this might be a subject for zope.interface. Also it would be nice to have something like delegateImplementation( iface, cvar ) and delegateProvision( iface, ivar) to delegate the fulfillment of an interface to a class variable or an instance variable. I don't understand what you mean. But my overall question is: since zope.schema is generally useful for components, why is it separate from zope.interface? I can think of two answers: one, pragmatically, zope3 wants a stable zope.interface so the rest of the system can come up to speed. Thus we can think of schema as sort of like the __future__ version of zope.interface. Second, as schema came from abstracting away zope-like features from gui support, it is meant as proto-gui-support. Well, it is a matter of overhead. We don't feel that everyone needs zope.schema. See the twisted guys for example. I would argue that, though it does support some features that would be useful for a gui, it is more generally applicable to component-based programming. If you feel strongly about this, bring it up on the zope.interface mailing list. (I have been using it for-- among other things-- some souped-up database Rows, which support transparently some postgress-specific features. The extra introspection capabilities in zope.schema have been useful.) Yep, it is nice for RDB things. But maybe Jim resists changes because he has a more specific role in mind for zope.schema, and the development of zope.interface? You have to ask him and the zope.interface mailing list. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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.schema: defaults for non-immutables... questions
I'll keep getting Jim's agreement or putting up a proposal in mind. As I start to think of how to extend it, I have some general question about zope.schema. I should note that I am not currently a zope user proper (though I will be soon), but was referred to the zope.interface package via twisted. When I looked at it, and the zope3 book, I immediately thought that type checking of attributes could be useful, and so started using zope.schema. I've thought of several things I'd like to see in it The biggest would obviously be (optional) type checking of method calls, together with a more robust Method definition. Also it would be nice to have something like delegateImplementation( iface, cvar ) and delegateProvision( iface, ivar) to delegate the fulfillment of an interface to a class variable or an instance variable. But my overall question is: since zope.schema is generally useful for components, why is it separate from zope.interface? I can think of two answers: one, pragmatically, zope3 wants a stable zope.interface so the rest of the system can come up to speed. Thus we can think of schema as sort of like the __future__ version of zope.interface. Second, as schema came from abstracting away zope-like features from gui support, it is meant as proto-gui-support. I would argue that, though it does support some features that would be useful for a gui, it is more generally applicable to component-based programming. (I have been using it for-- among other things-- some souped-up database Rows, which support transparently some postgress-specific features. The extra introspection capabilities in zope.schema have been useful.) But maybe Jim resists changes because he has a more specific role in mind for zope.schema, and the development of zope.interface? - Shaun -Original Message- From: Stephan Richter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 05, 2006 4:40 PM To: zope3-dev@zope.org Cc: Gary Poster; Shaun Cutts Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions On Sunday 05 February 2006 14:42, Gary Poster wrote: ...as I said, Jim disagreed with this sort of change the last time it was brought up. Okay, I did not know that. This needs to have a proposal, or at least needs to have Jim weigh in on it, IMO. Yeah, I forgot about a proposal. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.schema: defaults for non-immutables... questions
It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a Foo is not immutable this doesnt make sense. (In my case, I want a to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) A proposal to remedy: if the default is a callable object, it is assumed to be a factory. How does this sound? (This would apply to missing_value as well.) A few further questions: 1) who should be responsible for setting defaults, and how should it be done? I have a base class from which I derive (e.g.) Bar, whose constructor loops through fields of interfaces provided by the instance: for iface in zope.interface.providedBy( self ): for fname, field in zope.schema.getFields( iface ).iteritems(): It checks default missing_value, and sets them. However, if one field shadows another in the interfaces, there is no guarantee that I hit them in the right order. Might it not be good to have a attributesProvidedBy( instance ) in zope.interface that guarantees that it passes back the most derived versions (and resolves consistently when there is no most derived )? Also, currently, when something doesnt have a definition, and is not required, I check first for default then for missing_value, and use the first I find as a missing value. Is this correct? How should default and missing_value interact with each other? What makes most sense to me is: (pseudocode): If not specified: If default defined Use default Else If required Raise error Else If missing value defined Use missing value Else Raise error Finally, a missing missing_value eventually gets None in the current Field constructor. Shouldnt it be left undefined when it wasnt specified? (Same for default.) - Shaun ___ 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.schema: defaults for non-immutables... questions
Shane, I considered 'default_factory' myself It seems good, but it complicates the logic internally. For one thing, logically, we'd have to also have 'missing_value_default' (unless we decree that missing values have to be not-non-immutable, ah... immutable). A further thought on where to put filling in of defaults code -- this should probably be a separate routine in zope.schema: setDefaults(instance), which would set defaults (and validate? -- or maybe call it setDefaultsAndValidate). - Shaun PS anyone have idea or best practice on how to best through attributes, avoiding shadowed ones? Seems like this is generally useful for introspection of metadata. -Original Message- From: Shane Hathaway [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 12:39 PM To: Shaun Cutts Cc: zope3-dev@zope.org Subject: Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: Mutable is a better way to say non-immutable. :-) class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) But if a Foo is not immutable this doesn't make sense. (In my case, I want a to be a collection providing IFoo, which defaults to an empty collection. Each Bar implementing IBar should have its own instance of Foo.) I've run into this myself. How about: a = Object(schema=IFoo, default_factory=Foo) ? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.schema.Orderable -- additional tests
I have a version of zope.schema.Orderable (in
zope.schema._bootstrapfields.py) that passes additional tests having to
do with combination of missing_value with other constraints. (Released
version fails these.)
What should I do with it? I am new, and haven't contributed anything
before. Does someone want to see it? (Orderable included below.)
Can/should I just put it in SVN?
Thanks, - Shaun
Here are the additional tests (from zope.schema.tests.test_intfield.py):
def testValidateMissing( self ):
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=False,
missing_value = -1)
field.validate(-1)
field.validate(-10)
field.validate(10)
self.assertRaises( WrongType, field.validate, None )
def testValidateRequiredAndMissing(self):
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=True,
missing_value = -1)
self.assertRaises(WrongType, field.validate, None)
self.assertRaises(RequiredMissing, field.validate, -1)
def testValidateMinAndMissing(self):
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=False,
missing_value = -2, min = 0)
field.validate(-2)
field.validate( 10 )
self.assertRaises(TooSmall, field.validate, -1)
def testValidateMaxAndMissing(self):
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=False,
missing_value = 100, max = 0)
field.validate(0)
field.validate(100)
self.assertRaises(TooBig, field.validate, 1)
def testValidateMinAndMaxAndMissing(self):
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=False,
min=0, max=10, missing_value = -1)
field.validate(-1)
field.validate(0)
field.validate(5)
field.validate(10)
self.assertRaises(TooSmall, field.validate, -10)
self.assertRaises(WrongType, field.validate, None)
self.assertRaises(TooBig, field.validate, 11)
self.assertRaises(TooBig, field.validate, 20)
# in theory, missing_value could be in middle of range
# (maybe derived type defines invalid subranges, for instance)
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=False,
min=0, max=10, missing_value = 5)
field.validate(0)
field.validate(5)
field.validate(10)
self.assertRaises(TooSmall, field.validate, -10)
self.assertRaises(TooSmall, field.validate, -1)
self.assertRaises(WrongType, field.validate, None)
self.assertRaises(TooBig, field.validate, 11)
self.assertRaises(TooBig, field.validate, 20)
# however, when missing_value is equal to min or max, the
# bound is undefined
field = self._Field_Factory(title=u'Int field', description=u'',
readonly=False, required=False,
min=0, max=10, missing_value = 0)
field.validate(-10)
field.validate(-1)
field.validate(0)
field.validate(5)
field.validate(10)
self.assertRaises(WrongType, field.validate, None)
self.assertRaises(TooBig, field.validate, 11)
self.assertRaises(TooBig, field.validate, 20)
new version of Orderable (from _bootstrapfields.py):
class Orderable(object):
Values of ordered fields can be sorted.
They can be restricted to a range of values.
Orderable is a mixin used in combination with Field.
min = ValidatedProperty('min')
max = ValidatedProperty('max')
__missing_value_marker = object()
def __init__(self, min=__missing_value_marker,
max=__missing_value_marker,
default=__missing_value_marker, **kw):
# Set min and max to None so that we can validate if
# one of the super methods invoke validation.
self.min = None
self.max = None
super(Orderable, self).__init__(**kw)
# make sure that
