Re: [Zope-dev] New ssh keyfor svn access
Hi Tres, thank you for your reply, everything works fine now. -- Thomas ___ 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] New ssh keyfor svn access
Hi, I'd like to have a new ssh public key installed for svn access to svn.zope.org. Whom would I need to send it to? The web interface says webmaster at zope.org but that doesn't seem to get me a response. Thank you. -- Thomas ___ 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] Zope Tests: 140 OK, 13 Failed
Tres Seaver wrote:
> These are all failing due to a bad directive in a new ZCML file in
> zope.componentvocabulary::
>
> - - %< -
> ZopeXMLConfigurationError: File
> "/home/ccomb/ztk1.0dev-slave/Python2.4.6-Linux-64bit/build/src/zope.componentvocabulary/src/zope/componentvocabulary/configure.zcml",
> line 3.2-3.60
> ZopeXMLConfigurationError: File
> "/home/ccomb/ztk1.0dev-slave/Python2.4.6-Linux-64bit/build/src/zope.component/src/zope/component/configure.zcml",
> line 3.2
> ConfigurationError: ('Unknown directive',
> u'http://namespaces.zope.org/zope', u'subscriber') -
> - %< -
>
> I think Thomas Lotze added this file yesterday. I think it likely needs
> to have the following near the top::
>
>
This not entirely correct. The file has been there all along and I added
a test to make sure it can actually be loaded. This led me to add a
directive for loading the zope.component configuration.
I've fixed the new directive to now, making the test pass.
--
Thomas
___
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] Functional areas of Zope
Thomas Lotze wrote: > To get the discussion started, I'll give a few random examples of > functional areas that we thought of immediately: > > - software architecture (interfaces, components) > - data persistence (ZODB) > - URL resolution (object traversal) > - form generation (form libs for HTML forms, other possibilities?) > - resource handling (CSS, Javascript delivery) > - client-side programming framework Let me add a few more that Wolfgang and I have been thinking about in the meantime, hoping that they provoke more discussion and maybe give a better idea of what I'm trying to talk about: - general templating to generate HTML & friends - security: authentication, authorisation - logging, error handling - providing web services - i18n - caching - sessions - testing -- Thomas ___ 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] Functional areas of Zope
Jim Fulton wrote: > but I would hope that we wouldn't contradict the decision, made some time > ago that Zope, unless qualified (as in "Zope Community" or "Zope > Toolkit"), refers to Zope 2. If we did, it would have been because we > were speaking informally. Agreed. >> I'd like to pursue this by starting a discussion about Zope's functional >> areas among the developer community and hope to come up with a number of >> commonly agreed-upon items. Wherever it matters, I suggest limiting >> ourselves to discussing the ZTK in order to keep things focussed. > > I think you mean "ZTK" functional areas. Or, perhaps better, Zope > Community functional areas. I'd say let's talk about Zope Community functional areas as long as we're trying to identify what's involved in web programming and what, therefore, are the problems a community of web developers is being faced with. I think, however, that the Zope toolkit is what will profit most from an understanding of functional areas, so let's switch to talking about the ZTK's functional areas when the discussion becomes ZTK specific. >> the project would be the possibility to organise the large and grown set >> of individual packages that make up Zope's code. > > OK, so a benefit is to organize packages. I guess I can see that. So, a > documentation exercise. Perhaps this would be better left to people > writing documentation. > > I have a feeling that some people want to organize community development > efforts around these areas, although I don't think you're saying that, > although perhaps you hint at that in your summary. Obviously I didn't clearly enough say so, but I do think that organising development and communication are the primary benefits of identifying functional areas, but OTOH I wouldn't dismiss the aspect of organising (and better documenting) the code itself as a lesser task, even though I do understand that it may not be everybody's first concern (obviously not yours and not mine, either. >> - client-side programming framework (no good solution so far, people use >> all sorts of Javascript technologies and programming styles) > > Huh? There are many good client side development libraries. There isn't > one obviously "right" javascript library, but there shouldn't be. (I > think Tim made a mistake when he included TOOWTDI in the Zen of Python). But while there are good client-side frameworks, integrating them with the server side is still something I'd consider a functionality of the server framework or application, which is why I'm inclined to count client-side programming among the functional areas. (I'd like to suggest, however, discussing the Zope community's or the toolkit's answer to that in a separate thread so this one can stay focussed on identifying the functional areas in the first place.) > - integrating with form-generation libraries based on zope.schema, > > - transactional REST interfaces, and > > - perhaps more direct ZODB data access . Would you agree that these items define a functional area? -- Thomas ___ 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] Functional areas of Zope
First of all, please excuse the long time without a reply - I spent the last two weeks sick. Jim Fulton wrote: > On Mon, Oct 18, 2010 at 8:29 AM, Laurence Rowe wrote: >> I would say that javascript and client side programming frameworks are >> out of scope for Zope the project. There are plenty of existing client >> side frameworks (jquery, YUI, etc.) with varying degrees of weight and >> functionality. We don't want to build another. > > I agree. The only exception would be if someone came up with something so > innovative that we chose to embrace it. I think that the focus of the > community should be better leveraging existing libraries. I agree with that as well. In fact, I wasn't saying that Zope (the community) should invent a client-side framework of its own, but was rather mentioning client-side programming as one example of a problem domain that web programming nowadays includes and which I suggest the Zope community should have at least some answer to, making "client-side programming" one functional area of Zope in my opinion. That answer may of course be something that involves deploying one or more existing Javascript framework(s). To stay focussed on defining functional areas, however, let me suggest focussing this thread on the question whether we want to consider client-side programming a functional area of Zope in the first place, and maybe opening a new thread for discussing possible answers the Zope community might come up with. > A number of people have done work in this area. We should find some forum > to compare notes. > >> We also want to make it easy to communicate between client side >> javascript and server side python via JSON (bobo implmented some json >> help classes IIRC). > > So does zc.ajax (and our unfortunately internal zc.ajaxform). These fit > better with zope.publisher, fwiw. I'm sure there are other examples of > this in the zope ecosystem. IMO, this speaks for considering client-side programming a functional area of Zope and at the same time, indicates how identifying such areas enables us to better understand and coordinate development efforts and communication. -- Thomas ___ 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] Functional areas of Zope
Hi all, at the Zope summit in September, we were talking about what Zope actually is or should be and how to define the goal of the Zope project. This led to the idea of identifying the functional areas of Zope. I'd like to pursue this by starting a discussion about Zope's functional areas among the developer community and hope to come up with a number of commonly agreed-upon items. Wherever it matters, I suggest limiting ourselves to discussing the ZTK in order to keep things focussed. As functional areas (for some examples, see below), we consider diverse, broadly defined tasks and problems that a web developer is being faced with, and that a web framework ought to have an answer for. We hope to be able to define better what Zope is and is not and how it compares to other web frameworks by starting from a set of functional areas and trying to state Zope's answer to each of them. Another benefit from having a grip on functional areas of Zope the project would be the possibility to organise the large and grown set of individual packages that make up Zope's code. To get the discussion started, I'll give a few random examples of functional areas that we thought of immediately: - software architecture (interfaces, components) - data persistence (ZODB) - URL resolution (object traversal) - form generation (form libs for HTML forms, other possibilities?) - resource handling (CSS, Javascript delivery) - client-side programming framework (no good solution so far, people use all sorts of Javascript technologies and programming styles) I hope for the discussion to produce a list of functional areas that most developers agree upon, maybe further areas that need more consideration, and possibly even some clues about Zope's answers to the challenges of each functional area. Thank you very much for your participation. -- Thomas ___ 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] A summary of "Interfaces vs ZCA concepts"
Chris McDonough wrote: > Thomas Lotze wrote: >> Because then, if you use third-party code that uses >> zope.interface.Interface and other code (third-party or your own) that >> uses the subclassed interfaces, you'll have to deal with both types at >> the same time in your client code. You could use the new API on some >> interfaces but not on others, possibly on the same line of code. How >> readable or maintainable would such code be? > > I'm not sure, but if we had it to do all over again, this would be an > obvious solution. It would be the work of maybe two days to convert all > "ZTK" packages to use a z.c.interface.Interface, and any existing package > would need to be touched anyway to use .adapt and .utility. So it bears > some weight I think, even if it is eventually rejected. It does certainly bear some weight as one possibility to be considered. However, my point wasn't so much about converting a limited existing amount of code; you're obviously right about having to touch that anyway in order to use the new methods. My objection is this: If we go to the trouble of implementing basic interfaces in zope.interface plus derived ones with component lookup capabilities in zope.component and keep both around for their respective reasons of existence, then it is expected that there will be code that uses both types of interfaces for these very reasons (and maybe other types which have other added behaviour). Such code would become a lot less maintainable since you'd never know whether a given interface has a particular method just because the one next to it does. OTOH, registering all behaviour an application needs onto the same interface type doesn't create that problem. As long as you're familiar with the application at large, you will know for every interface that occurs in it which methods is has, how they need to be called and what their semantics are. Also, subclassing for adding behaviour introduces the typical problems of hierarchies and tight coupling. This isn't a practical problem as long as we only ever talk about adaptation as the only use of interfaces, but I'm trying to discuss "interfaces as a language feature" with a greater set of possible use cases. -- Thomas ___ 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] A summary of "Interfaces vs ZCA concepts"
Hi, this is a long message with a lot of replies to things that I don't agree with. Since I realize that making those points over and over again doesn't get us anywhere, I'd like to point out first that I'm going to implement Martijn's suggestions anyway on one of my branches, hoping that seeing more actual code to talk about might help getting to more consensus. Martijn Faassen wrote: >>> * It'd be nice if __call__ came back with a LookupError instead of a >>> TypeError, but how to get from A to B without breakage? >> >> It's not possible without breakage. > > Unless we create a zope.interface specific LookupError which subclasses > both the built-in LookupError and TypeError. zope.component's > ComponentLookupError should subclass this special LookupError then. Technically true, so my statement was admittedly too strong. I just don't feel comfortable with the idea, which may well be just because it's the "let's make both exceptions work sowmehow" solution to me instead of the clear change I thought we were considering. OTOH, it's not that big an issue either, so I guess I'd be fine with it. >>> * the methods can be on zope.interface even if zope.component isn't >>> installed. They will behave as if the component registry is empty. >> >> This isn't covered by the consensus you mentioned above as far as I'm >> concerned. > > Yeah, I put that in so we can reach consensus on it. I thought Tres had a > good idea going on there that makes the plugin behavior a lot cleaner. Hm, I can't help feeling pushed into this. While this plugin stuff is indeed nice *assuming* that we want all the zope.component concepts in zope.interface, it doesn't contribute to the decision about *whether* we want that in the first place. >>> IFoo.adapt(context) raises LookupError, unless the context provides >>> IFoo, in which case it returns context. >>> >>> IFoo.adapt(context, default=default) returns default unless context >>> provides IFoo, in which case it returns context. >>> >>> IFoo.utility() raises LookupError. >> >> IFoo.utility(default=default) returns default >> >> I think looking at that API explains why we have trouble with having >> stub methods defined by zope.interface: these methods contain enough >> information about component concepts to blur the distinction between >> zope.interface and zope.component, but they still lie about the actual >> method signature. > > I don't understand you: why do you say they lie about their method > signature? They should have the same signature and have a well-defined > behavior if zope.component is not installed: there is nothing registered > at all. zope.interface provides a plugin point that allows one to plug > lookup behavior into it. When I wrote that, I was assuming that we were talking about patching interfaces with methods that have zope.component's full lookup semantics, including `name` and `context` parameters - which abviously would change the signatures. If we're talking about something that doesn't add those parameters, there's no lie involved but I don't see how our lookup methods could then access the full feature set of zope.component's lookups. > In that case, I want the real contract to be in zope.interface. That's > where the methods are, after all. We need to talk about the concept of an > adapter and a utility briefly in zope.interface and defer to > zope.component as the most common implementation. We already have this > kind of behavior going on anyway with __call__() (even though not > documented!). Well, we obviously disagree completely about this. The existing __call__ method is neither a good example of a zope.component lookup API, nor do I think that it was fortunate to wire up the adaptation concept in zope.interface through __call__ in the first place. I'd rather try to loosen this reference to component concepts than use it as a reason for adding more. > You'll have to go into more detail. Why does it feel wrong to you? Because it is just another way of encoding the zope.component details within zope.interface. I would love to add a plugin API that is generic enough to apply equally to other uses of interfaces than component lookup, and that would allow implementations of component lookup with different concepts and different lookup methods than those of zope.component. > Why is it a problem that the zope.interface package gains knowledge about > adaptation (which it always had, anyway) (and which, IMO, it shouldn't have in the first place) > and utility lookup? Because if we're serious about making interfaces more of a language feature, they should at their core be reduced to *being* mostly information (maybe with a bit of verification code) instead of extended to *doing* things that derive mainly from *our* particular ways of using them. > Because to > the user of those methods on Interface, it looks exactly like the > packa > does have such knowledge. We shouldn't lie.ge I don't think that we lie as long as we state that we h
Re: [Zope-dev] A summary of "Interfaces vs ZCA concepts"
Chris McDonough wrote: > I'll throw out the obvious... > > Why not subclass Interface in zope.component and make the required API > additions there? If it were anybody but us thinking about doing this, > they'd probably just subclass. Because then, if you use third-party code that uses zope.interface.Interface and other code (third-party or your own) that uses the subclassed interfaces, you'll have to deal with both types at the same time in your client code. You could use the new API on some interfaces but not on others, possibly on the same line of code. How readable or maintainable would such code be? -- Thomas ___ 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] A summary of "Interfaces vs ZCA concepts"
Martijn Faassen wrote: > Here's a summary of what has been going on in this thread with some > attempts at conclusions that have support of the consensus so that Thomas > can proceed Thank you, half an hour later and I'd have written the summary ;o) > * We want to implement .adapter(), .utility() and .__call__() in > zope.component as much as possible. The method's name is `adapt`, JFTR. > * we want a similar mechanism for each of them to plug in. Agreed, even though (AFAICT) we haven't been talking about moving the implementation of __call__ to zope.component so far. > * It'd be nice if __call__ came back with a LookupError instead of a > TypeError, but how to get from A to B without breakage? It's not possible without breakage. I'd say changing the error is worth a 4.0 release, but we might want to postpone this change and see whether there's anything else we want to change about zope.interface in a backwards-incompatible way, and if so, put that in the 4.0 release as well. I guess we don't want too many backwards-incompatible releases of such a central package. One thing I start questioning is an adapter registry being implemented by zope.interface. Moving it to zope.component seems to me to be related to keeping the implementations of the new method within zope.component. > * there was some discussion about general plugin points on Interface. > Those have a complexity cost compared to simply poking the methods into > the class. As for poking the methods into the class, see the new tlotze-patching-interfaces branches of zope.interface and zope.component for the minimum change this would take IMO. The change to zope.interface is really just about documentation. > * the methods can be on zope.interface even if zope.component isn't > installed. They will behave as if the component registry is empty. This isn't covered by the consensus you mentioned above as far as I'm concerned. > Their behavior should be: > > IFoo.adapt(context) raises LookupError, unless the context provides IFoo, > in which case it returns context. > > IFoo.adapt(context, default=default) returns default unless context > provides IFoo, in which case it returns context. > > IFoo.utility() raises LookupError. > > IFoo.utility(default=default) returns default I think looking at that API explains why we have trouble with having stub methods defined by zope.interface: these methods contain enough information about component concepts to blur the distinction between zope.interface and zope.component, but they still lie about the actual method signature. In that sense, these stubs would be worse than zope.interface not documenting the methods at all. In my and Wolfgang's opinion, we can either have zope.interface implement methods with the real contract, which would mean defining the full concepts of the ZCA within zope.interface (if not their implementation), or not even have method stubs in zope.interface and leave the whole business of defining specialised uses of interfaces to other packages such as zope.component. > What's the behavior of __call__ now if zope.component isn't around? Similar to what you've just described of your `adapt` method, up to the name of the `default` parameter and the exception raised. > * Tres brought up that we can come up with a clean plugin interface > instead, and now I'm tempted to go for that instead of monkey-ing around. [...] I'd have to think about that some more, but while reading it the first time, it feels quite wrong to me. > I realize that the proposal for a plugin API gives zope.interface some > knowledge about adaption and utility lookups, which is what Thomas and > Wolfgang had trouble with. But after all that's what we're doing anyway by > putting those methods on the API, one way or another. No: the zope.interface package doesn't have any knowledge about the particulars of any of the uses of interfaces. One might claim that interfaces do after they've been patched by other code, but then, that's after some application has made its choice about plugin certain packages together. It's not baked into zope.interface, and that's what we're trying so hard to achieve. > [Philosophically from my own perspective I think we'd have much less > conceptual difficulty with this if we just made __call__ do all lookups, > as that hides the whole set of concepts of utility versus adapter a bit, > but we can't get consensus for that unfortunately. But I'm biding my > time..] Implementing __call__ within zope.interface in that way would get the package rid of the method names `adapt` and `utility`, but the technical problem with the method signatures and the more philosophical one about whether zope.interface should really make adaptation stand out as a use of interfaces remains. Which brings me back to the question I asked earlier, and which nobody has replied to so far: Do we want to make zope.interface completely unaware of any particular uses of interfaces, or do we want to treat co
Re: [Zope-dev] Interfaces vs ZCA concepts
Martijn Faassen wrote: > Hey, > > Tres Seaver wrote: > [snip] >> Any code today which wants a utility is calling 'getUtilty' (if it >> *knows* the utility must be registered) or 'queryUtility' (if it thinks >> it might not be). Less facetiously than my first challenge: please >> point to actual code in the wild which looks like:: >> >> try: >> foo = getUtilty(IFoo, name='bar') >> except ComponentLookupError: >> # do something >> >> instead of:: >> >>foo = queryUtility(IFoo, name='bar') >>if foo is None: >># do something >> >> I will argue that any code doing the first, outside of maybe tests of >> the ZCA itself is plain broken. > > I have code like that in the wild - I have no real reason why I didn't > queryUtility, but I didn't think it mattered. > > Why is it plain broken? Isn't getUtility supported to raise > ComponentLookupError if it cannot find the required utility? The interface declaration for the zope.component API does assert that getUtility raises a CLE if it cannot find the utility. Also, I wouldn't say that queryUtility should be used instead of using getUtility and catching the CLE, as that would deprive us of all the advantages of using exceptions, such as propagation along the call stack. -- Thomas ___ 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] Interfaces vs ZCA concepts
Thomas Lotze wrote: > I'm > not sure whether we should make the name of that parameter consistent > between zope.component and zope.interface, Sorry, nevermind. Of course we'll want to rename that parameter as our secret plan is to access the ZCA through Interface.__call__ one day. -- Thomas ___ 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] Interfaces vs ZCA concepts
Martijn Faassen wrote: > Thomas Lotze wrote: >> Martijn Faassen wrote: >>> * have dummy implementations in zope.interface that raise >>> NotImplementedError >> >> That would still introduce too many zope.component concepts into >> zope.interface IMO: obviously that of utilities as one of the dummy >> methods would bear that name, and those of named components and lookup >> contexts if the methods were to be specified by IInterface. > > I think having these markers is very important for code readability. > People reading the code will otherwise have no idea whatsoever where these > methods come from. I see your point, but I have two objections: - The very concept of the ZCA introduces a related problem with code readability: just by reading the code that uses components you will never be able to tell where a particular adapter or utility comes from, or even what adapters or utilities you can hope to look up in the first place. So having to have some knowledge of the larger system that uses the interface mechanics isn't an entirely new thing, and having to learn about these two methods is a very small one-time effort compared to the "readability obstacles" that using the system thus entails. - As pointed out before, I consider it a goal to treat all uses of interfaces equally (which seems to me to be related to the effort to make interfaces more of a part of the language). By implementing stubs for `adapt` and `utility` (or specifying them in IInterface) we'd make the ZCA stand out as a particular use of interfaces. IMO, we serve those who seek to understand the API just as well by documenting the two methods as prominent examples of interface usage. I guess we should make a decision about the latter point of view before discussing a particular implementation strategy. > I'm not sure whether much of a general mechanism is really needed, after > all we already have monkey patching (um, sorry Tres, modifying a class). > I can see there being an API in zope.interface that allows one to plug > into .utility() and .adapt() If you're talking about the component hooks, then that's the part I hope to get rid of as it causes more trouble than it helps. (This is what I tried to point out in the message that started this thread.) >> parameter isn't even called 'default' but 'alternate' in >> Interface.__call__. The very name of the default argument is another >> thing that is sneaking from zope.component into zope.component. > > Let's deprecate 'alternate' and introduce 'default' then. Might actually > make the deprecation more easy.. I don't think so. We're going to deprecate not spelling out the name of the parameter, so it won't matter which name not to spell out. OTOH, we'll additionally have to deprecate the name `alternate` where it is used. I'm not sure whether we should make the name of that parameter consistent between zope.component and zope.interface, or leave it alone in order not to pretend the relation between the different implementations of adaptation to be stronger than it actually is. -- Thomas ___ 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] Interfaces vs ZCA concepts
Martijn Faassen wrote: >> * The hook invokes the `query*` functions to play nice with any other >> component hooks and the interface methods raise a TypeError if all of >> them fail to find a component. > > A TypeError instead of a ComponentLookupError? > > I was thinking we should keep the behavior as close to zope.component as > we can, including ComponentLookupError. Don't you get a > ComponentLookupError with the classic adapter hook too? So I'm -1 to > making this a TypeError. The ComponentLookupError is defined by zope.component. So the only way of getting a CLE raised by Interface.adapt or Interface.utility would be to call the non-query-style lookup functions from the zope.component API and let the error propagate. The current implementation of the new interface methods pretend, however, to allow for more hookability than just calling a zope.component function, so it is intentional to not let any error propagate but defer to the next hook instead and raise an exception of a type known to zope.interface (i.e. not CLE) if none of the hooks succeeds. The choice of TypeError was made in analogy with __call__. Currently, you get a TypeError if IFoo(bar) fails while zope.component.getAdapter(bar, IFoo) raises CLE. IMO, the clean way to solve this is to drop the analogy with the __call__ implementation and no longer try to cater for generic `adapt` and `utility` behaviour. Together with avoiding a direct dependency of zope.interface on zope.component, this leads to injecting non-hookable implementations of `adapt` and `utility` from zope.component itself. > I think a monkey patch would be fine. Opinions about making it more > structured: > > * have dummy implementations in zope.interface that raise > NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and those of named components and lookup contexts if the methods were to be specified by IInterface. > * have that NotImplementedError say to look for implementations in > zope.component I would actually like a mechanism that doesn't care about what package will inject which pieces of API. Do you think such generality is asking too much (at least at this point in time)? > * have the docstring on the methods that are injected be clear that they > are being injected into zope.interface Of course. > That way someone reading the zope.interface code can at least find out > that this functionality is injected from zope.component. IMO, we should mention this as a usage example but not as a requirement. > [as an aside it'd be interesting to find out how much of of zope.component > functionality could sensibly make it into zope.interface, but that's > another project; Gary Poster has some ideas in relation to this] I think before doing such a thing, we should come up with a precise definition of which concepts are the concern of interfaces, which are that of the ZCA and exactly where to draw the line. Anything else looks IMO dangerously like a slippery slope towards mixing it all up into zope.interface. > I'm still sneakily hoping that in a few years we'll be able to get calling > the interface be the one true way of looking up implementations of that > interface (utilities and adapters and whatnots), but we'll see. Me too. > Did you make an implicit 'default' deprecated on __call__ yet by the way? Not yet; the other issue looked more interesting so far ;o) BTW, that parameter isn't even called 'default' but 'alternate' in Interface.__call__. The very name of the default argument is another thing that is sneaking from zope.component into zope.component. -- Thomas ___ 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] Interfaces vs ZCA concepts
So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? -- Thomas ___ 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] the ZCA API decision
Lennart Regebro wrote: > I'm +1 on this decision, and would also like to announce that I have > cleaned up my Python3 compatible branch of zope.interface. Even though the > decision now is to only add new stuff and not break any backwards > compatibility I think adding the Python 3 support into 4.0 would be a good > time to add this anyway, so we get all API changes at once, even if they > are fully backwards compatible. Do we still want to call the new release 4.0 if no backwards-incompatible change is going to be made? -- Thomas ___ 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] the ZCA API decision
Gary Poster wrote: > I would think we would want to follow the pattern of the adapter_hooks in > zope.interface.interface, including the C optimizations. Speaking of adapter hooks: If I'm not completely mistaken, adapter hooks know about exactly one object to be adapted. To follow the pattern of adapter hooks in the implementation of our new lookup methods, we need hooks that handle zero, one or more objects instead. We could work with a second set of hooks in order to keep the existing ones untouched, but that would require every user of the hooks feature to implement both kinds of hooks. We could also change the signature of adapter hooks, which would be backwards-incompatible, either with tuple adaptation or with named adapters (since the name is the first keyword argument for adapter hooks). So I'd like to hear opinions: Would a backwards-incompatible change to adapter hooks be acceptable, considering that this wouldn't be visible to users of the component architecture but only to implementors of component frameworks like zope.component? -- Thomas ___ 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] the ZCA API decision
Gary Poster wrote: > I don't know if too much experimentation is needed for this in particular. > > I would think we would want to follow the pattern of the adapter_hooks in > zope.interface.interface, including the C optimizations. > > I would be comfortable with you leading the effort, in a shared branch, if > that works for you. You could specify what parts you wanted help on. > > Or would you prefer someone else to take charge? I'd be happy to lead this effort, if you like to put it like that. I wouldn't want to take it out of Martijn's hands, though, unless he's happy with it as well, given that he's the one who started the discussion. As for any technical questions, it's too late in the night over here now for me to say anything serious, so I'll reply to that tomorrow. -- Thomas ___ 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] the ZCA API decision
Martijn Faassen wrote: > Thomas Lotze, are you happy enough with this to still help with the > implementation? I am indeed. This isn't the ideal solution I had hoped for, but it is a big step in a good direction from my point of view and I don't see any part of it that might take us away from the ideal solution which I still hope we can implement at some point in the future. How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first? -- Thomas ___ 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
Gary Poster wrote: > Without this distinction, AFAICT either you want to conflate the ideas, or > you have a concept of the differences between the two that is more > esoteric than I think is useful. I get the impression that it is on the > second point of those that we disagree. Right, I understand the motivation behind your arguments, and I do have a different opinion. OTOH, it's probably helpful for the discussion to have spelled this disagreement out. -- Thomas ___ 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: > * a utility never has a connection. That's because it already got > instantiated long before the lookup takes place. Isn't it the other way around: A utility never has a connection to any adapted object, and that's *why we can* instantiate it long before the lookup takes place. I think the difference between these two perspectives may have to do with why some people in this discussion confuse (as I see it) the concepts of instance vs. factory registration and adapter vs. utility lookup. -- Thomas ___ 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
Gary Poster wrote: > > On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: > >> On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze wrote: >>> To be honest, I just don't see why this whole singleton business >>> shouldn't be orthogonal to the concepts of the component architecture. >> >> Well said. If an application cares about singleton creation or >> ownership of factory-returned objects, it can describe those >> requirements using interfaces. > > You are arguing for the unification of utilities and adapters? IMO we're arguing that singletons, the registration of instances vs factories and the distinction between utilities and adapters are three completely different subjects that are orthogonal to each other. I.e. I consider all eight of these combinations conceivable: take a class that may or may not implement a singleton and register an instance of it or the class itself as an adapter or a utility. (I do agree that an adapter being a singleton is a pathological case but I wouldn't consider it conceptually unthinkable.) -- Thomas ___ 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
Chris McDonough wrote: > Furthermore he'll believe he "owns" the resulting object, because normal > classes are always constructors that create a new object. Except when they don't. Apart from cases like short strings and small integers where Python itself doesn't create objects more than once, you can always implement classes that define __new__ or use metaclasses in such a way that you cannot be sure that (or whether) calling them under given circumstances will create new objects. To be honest, I just don't see why this whole singleton business shouldn't be orthogonal to the concepts of the component architecture. -- Thomas ___ 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
Lennart Regebro wrote: > On Sat, Nov 28, 2009 at 16:39, Charlie Clark >> The >> most common example I know of the syntax is with INameChooser() which >> brings us back to the differences (real or imaginary) between utilities >> and adapters. > > I agree that calling an interface like that is a strange thing to do. I > don't know what that would do, even. I have however never ever seen that > done. To me, it feels rather naturally like calling a class: both give you an object that has a well-defined relation to what you called, i.e. "is an instance of the class" or "provides the interface". Both relations are very similar IMO in that they describe how the object behaves and what you can do with it, the difference being only that calling an interface adds some abstraction and flexibility. -- Thomas ___ 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: > Are people okay with the proposed semantics? I am. > Would people be okay with such an upgrade path? Any better ideas? I'm not comfortable with the idea of an automatic fall-back for IFoo(x, y) but maybe that changes after thinking about it some more. > Most importantly, any volunteers? I'd like to work on this. -- Thomas ___ 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
Martijn Faassen wrote: > Thomas Lotze wrote: > [snip] >> Then let me suggest not changing the call signature of an interface at all >> but only add one or a few new methods. Firstly, this will keep backwards >> compatibility even with code that adapts a tuple, and secondly, it >> allows us to implement a simple and consistent API anyway. > > That was my original proposal, right? (I only propose adding a 'name' > argument to the IFoo() lookup if it isn't there already, otherwise it's > all new methods). I specifically wanted to suggest not adding that name argument but leaving the existing call untouched. I think once we add a new method, we shouldn't at the same time improve the existing one as that would IMO suggest rather forcefully that there's more than one way to do the same thing; just leaving it in there for compatibility is bad enough from the point of view of a clean API. -- Thomas ___ 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
Martijn Faassen wrote: > Thomas Lotze wrote: >> You didn't explicitly mention the subject of backwards compatibility in >> your original message, so let's make it explicit now: Is backwards >> compatibility a goal in this discussion? > > True. It's indeed a goal, as I'd like to be able to use this sooner > rather than later. If we break backwards compatibility then we'd have to > go through all the IFoo() calls everywhere in all our code to see > whether a default argument is in use. Understood. >> If it isn't, I'm rather against an API that interprets an argument to >> IFoo() as meaning different things depending on whether it's a tuple or >> not. Python itself has an API that works like this (string formatting) and >> is moving away from it. Requiring the default to be specified as a named >> argument would also help readability IMO. > > Sure. But if we want to retain backwards compatibility we'll have to go > another way. Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. My favourite option under these circumstances would be something like IFoo.query(*args, default=None, ...) though possibly with a method name in a different color of bike shed, where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may be written as IFoo.query(x, y). -- Thomas ___ 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
Martijn Faassen wrote: > Thomas Lotze wrote: > [snip] >> What about a simple and consistent API for all components including >> utilities, adapters and multiadapters: >> >> IFoo() >> IFoo(x) >> IFoo(x, y) > > The last one won't work if we want to maintain backwards compatibility. > The second argument is the default. Technically, that's obvious. I guess I meant to say "How about..." then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. -- Thomas ___ 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
Gary Poster wrote: > > On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: > >> What about a simple and consistent API for all components including >> utilities, adapters and multiadapters: >> >> IFoo() >> IFoo(x) >> IFoo(x, y) >> >> I seem to remember there had been some discussion at some point about >> dropping or at least loosening the distinction between utilities and >> adapters anyway, so this would be the opportunity to do so at the API >> level. > > That was discussed and rejected near the very beginning of the Z3 > effort, in my memory. OK. If that was a hard and fast decision, I'll not argue further. > They are too different. Our use of adapters > generally involves looking something up and automatically calling it. > Our use of utilities generally involves simply looking something up and > returning it. I do think, however, that this is more a problem with registration than with look-up. You need to know whether to register a factory or an instance of a component, but whatever you look up will provide the interface you require and doesn't have to be called in either case. -- Thomas ___ 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
Martijn Faassen wrote: > Adapter: > > IFoo(x) [...] > Multiadapter: > > IFoo.multi(x, y) [...] > Utility: > > IFoo.utility() > > [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. -- Thomas ___ 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] Releasing zope.browserresource
Benji York wrote:
> On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze wrote:
>> Argh, now the PyPI UI is really broken for me... No, seriously - thank you
>> very much.
>
> If you're a GreaseMonkey user, try this:
>
> // turn off (potentially) long list of projects
> GM_addStyle('div#document-navigation {overflow: scroll; max-height:
> 15em; width: 15em; overflow-x: hidden}');
I'm not yet, but this may well be a reason to change that. Thank you very
much for the pointer.
--
Thomas
___
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] Releasing zope.browserresource
Stephan Richter wrote: > On Tuesday 24 November 2009, Thomas Lotze wrote: >> Could somebody please give me PyPI rights for zope.browserresource? I'd >> like to release a new version of it which includes the recent fixes to its >> dependencies. Thank you very much. > > I am in the process of making you all powerful. :-) Argh, now the PyPI UI is really broken for me... No, seriously - thank you very much. -- Thomas ___ 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] Releasing zope.browserresource
Could somebody please give me PyPI rights for zope.browserresource? I'd like to release a new version of it which includes the recent fixes to its dependencies. Thank you very much. -- Thomas ___ 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] Making zope.dublincore independent of zope.annotation
I'd like to see the hard dependency of zope.dublincore on zope.annotation gone. This would lift the indirect dependency on the ZODB. zope.dublincore uses zope.annotation in three places: - For defining the IZopeDublinCoreAnnotatable marker interface which isn't used in any of the packages mentioned in ztk.cfg, which basically amounts to all of Zope. I suggest simply deleting this interface. - For implementing and registering the ZDCAnnotatableAdapter which only makes sense if zope.annotation is installed in the first place. I suggest making the registration of this adapter conditional on whether zope.annotation is installed, which removed the hard dependency. - For tests, which would require zope.annotation to remain a testing dependency of zope.dublincore. If there are no objections, I'd like to make these changes and release zope.dublincore in the course of this week or the next. -- Thomas ___ 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] Where does ISite belong conceptually?
Martijn Faassen wrote: > Thomas Lotze wrote: >> I wonder: should we start requiring that the object passed to setSite() >> implement (or even be adaptable to) IPossibleSite? > > I think the simplest way forward would be not to change the semantics as > part of this step. Agreed. -- Thomas ___ 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] Proposal: cleaning up the content-type story
Thomas Lotze wrote: > I'm still going to move the zope.publisher.contenttype functionality to > zope.contenttype which will ease some packages' dependencies, JFTR: I've done that now, including updates to packages which used to import from zope.publisher.contenttype. -- Thomas ___ 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] zope.site.hooks
After having been sick for a week I'm back on track now... Fabio Tranchitella wrote: > I want to bring the test coverage for zope.component.zcml and > zope.component.security to 100% before asking to merge it back to the > trunk. I'd like to tackle the move of zope.site.hooks to zope.component this week. While I'm sure that that wouldn't conflict with your work, I would prefer releasing both refactorings at once as they both involve using the new scheme of conditional zope.security imports. Do you suppose you could get your branch finished and merged this week? If not, I'd be willing to help you with it. -- Thomas ___ 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] allow-picked-versions=false in ztk.cfg?
Martijn Faassen wrote: > Martin Aspeli wrote: >> Hanno Schlichting wrote: >>> On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen >>> wrote: > [ztk.cfg] contains a line > allow-picked-versions = false I agree with Thomas that we should remove this from ztk.cfg, as if we publish this for reuse we don't want to impose this policy on everybody who builds on it. [...] >> If we do that, I'd also suggest we use the 'buildout.dumppickedversions' >> extension. This prints the picked versions with some explanation >> about >> what required them, either to a file or to the console. This is a >> useful sanity check: if you see a package in there that looks spurious >> you may ask whether it should've been pinned somewhere. > > Does that make sense? After all, if we say allow-picked-version is > false, there never will *be* any picked versions to dump. Or am I > misunderstanding something? I think Martin wants to dump picked versions in the case that allow-picked-versions=false is removed from ztk.cfg. -- Thomas ___ 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] Removing zope.testrecorder from the ZTK
Martijn Faassen wrote: > Jim Fulton wrote: > [snip] >> In any case, I agree it should be dropped from the ZTK. > > +1 on dropping it too. Done. -- Thomas ___ 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] Removing zope.testrecorder from the ZTK
I just noticed that zope.testrecorder, which is listed in ztk.cfg as an included package, imports from Globals, OFS, AccessControl and Products.PageTemplates. This looks to me as if zope.testrecorder shouldn't actually be part of the ZTK. It's also not used by any package mentioned in ztk.cfg. -- Thomas ___ 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] Proposal: cleaning up the content-type story
Fred Drake wrote: > On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting > wrote: >> If someone would document srichter's magic grant-all-powerful PyPi >> script, I'd run it :) > > That's a horrible thing to do to somebody! > > Note that I'm not smiling, either. It's too easy to grant people access > to way too many packages that way. Somebody ran it for me, without my > knowledge, and I learned about a lot of packages I'd never heard of > before. That just makes PyPI harder to use when updating something I *am* > actually a maintainer for. I think the issue this points at is actually with usability of PyPI. There shouldn't be this miles-long list of packages on the right when logged in in the first place. OTOH, even with good usability I'd rather not have rights for packages I'm not interested in, just to be able to deny responsibility if anything goes wrong with one of them. Having rights for all packages involved with ZTK refactorings would be helpful, though. -- Thomas ___ 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] Proposal: cleaning up the content-type story
Thomas Lotze wrote: > I'm still going to move the zope.publisher.contenttype functionality to > zope.contenttype which will ease some packages' dependencies, and I'll try > to move some appropriate bits of code from zope.mimetype to > zope.contenttype. Before doing so, however, I'd like to release the current state of some packages and update their versions in ztk.cfg in order to have a clean state to proceed from. The zope.publisher trunk doesn't work with the zope.app.publisher version from the current ZTK. Also, zope.server, zope.app.authentication and zope.app.i18n need some modifications not yet released in order for their tests to pass with the current zope.publisher. So as a first step, I'd like to release the current code of zope.publisher, zope.server, zope.app.authentication and zope.app.i18n. Can somebody please grant me PyPI rights for these packages? Thank you very much. -- Thomas ___ 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] zope.site.hooks
Tim Hoffman wrote: >> GAE users and repoze.bfg users as repoze.bfg doesn't use zope.security >> at all > > I did a quick grep and it appears that repoze.bfg never actually loads > zope.component.zcml > so I think if the only dependancies you introduce are via zcml then you > should be ok. And given I am running repoze.bfg on app engine it would > seem to > confirm this ;-) To clarify: We're considering the addition of a module that wouldn't have anything to do with the zcml extra but would talk about zope.security nontheless. Only it wouldn't be a dependency declared in setup.py or in the sense that things would break without zope.security. We'd rather try to import it and if it isn't there, just not do one or two things in the code on the grounds that they'd be irrelevant in that case anyway. As we're thus not requiring zope.security to be installed, I think you should be fine on GAE. I mentioned the zcml extra only because that's how zope.component has to do with the security concept already, as a motivation of why I'm letting go of my opposition to introducing more of that concept into zope.component. -- Thomas ___ 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] zope.site.hooks
Thomas Lotze wrote: > I thought about that one briefly, but I don't like it because it > introduces at least some knowledge about the security concept to > zope.component. The more I think about it, the less evil this appears to me, though. After all, the zope.component.zcml module has been dependent on zope.security all along (requiring one to install zope.component [zcml] which pulls in zope.security if one wanted to use it). I think I'd be willing to use zope.security optionally for the site stuff provided that we can get the GAE users to agree and with the intention of cleaning up things later according to those old comments in the code which I mentioned previously. -- Thomas ___ 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] zope.site.hooks
Martijn Faassen wrote: > Thomas Lotze wrote: >> IMO it would be interesting to have the concept of the current site >> available separately from the rest of zope.site with its 30 >> dependencies. (For example, zope.browserresource demonstrates how with >> the present zope.site the need to know the current site in order to >> determine a URL leads to a dependency on the ZODB.) > > +100 if this makes site-aware code have less dependencies. One can really > get rid of a *lot* of dependencies this way. That's what I thought ;o) > We could investigate two options: > > * just removing that code that remove proxies and sees what happens to > significant Zope 3 code bases. Risky. To begin with, compat-tests of a number of ZTK packages and a lot of the packages under review for the ZTK fail if I do that. This is why I said the code is currently needed. Typically, this has to do with something about interactions not being available to code like zope.component.subscribers(). > * alternatively, putting in an optional dependency on zope.security in > zope.component. If zope.security proxy is importable, try removing the > proxies, otherwise don't. I thought about that one briefly, but I don't like it because it introduces at least some knowledge about the security concept to zope.component. While I can't follow why others consider an optional dependency bad from a technical point of view such as usability on GAE, I think zope.component is so low-level that we should value its conceptual clarity greatly. -- Thomas ___ 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] Updating the ZTK KGS
Martijn Faassen wrote: > Whether ztk.cfg can be reused directly or whether we should extract > something in it with just the version indicators I'm not sure about. I've > noticed when modifying the buildout.cfg of the ZTK to add > z3c.recipe.depgraph support that I had to pin down *everything* that was > pulled in by depgraph as well if I wanted to avoid getting buildout errors > (some weird version conflict was taking place). I hope that ztk.cfg isn't > triggering that. I'd say it does; it contains a line allow-picked-versions = false which makes buildout complain if it ends up using a package whose version it had to pick from the index, so you're required to specify a version for every package used by any part of the buildout. This line is a piece of policy that I'd like to see gone from ztk.cfg as well; if someone wants the behaviour, they can specify it in their buildout.cfg. > The reason I mentioned docs.zope.org as the release location is because we > will also publish release-specific ZTK documentation when we make a > release. The release-specific documentation should be maintained and > tagged along with the ZTK itself, and we should have easy access to > previous versions of the docs on versioned URLs. Agreed. -- Thomas ___ 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.site.hooks
zope.site.hooks is a rather light-weight module that is concerned with the concept of a current site, where the notion of a site is used in the same sense as in zope.component, which actually prefers to only talk about a component registry. In contrast, the rest of zope.site deals with local site managers and container stuff including the implementation of folders. IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.) I would propose moving zope.site.hooks to zope.component.hooks if it wasn't for its use of zope.security in order to remove security proxies in two places. These places have rather old comments that suggest reconsidering the handling of security proxies at some point. Right now, the code that removes the proxies is needed but I'd like to raise the question whether we should try to get rid of it. If there's no objection to this goal, I'd like to investigate what it would take. (Even if zope.site.hooks were to remain a part of zope.site, this would rid zope.site of the dependency on zope.security and at least one other package.) -- Thomas ___ 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] Proposal: cleaning up the content-type story
Martin Aspeli wrote: > Thomas Lotze wrote: > >> - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME >> type of file contents, preferrably without dependencies within the ZTK > > Can I suggest that we use a different name? 'content type' to me sounds > like CMS-y functionality. We have interfaces like IContentType and methods > like queryContentType, neither of which would be relevant to > zope.contenttype. :) > > Maybe zope.mimeparsing or something like that? Fine with me. OTOH, there's also good reason to talk about content types since at least the relevant RfCs talk about the kind of strings being parsed mostly (only?) in the context of the Content-Type header field. Personally, I don't care enough to risk bike-shedding about this, though. -- Thomas ___ 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] Proposal: cleaning up the content-type story
Thomas Lotze wrote: > At present, zope.contenttype doesn't have any dependencies within the ZTK, > and zope.mimetype depends on zope.configuration, zope.component and > zope.interface. zope.publisher.contenttype doesn't import any zope code. > > - Switching packages that depend on zope.mimetype would therefore add no > additional dependencies to them. > > - There are three packages within the ZTK and the set of packages under > review which depend on zope.contenttype: zope.browserresource, > zope.app.file and zope.app.onlinehelp. All of them already depend on > zope.mimetype's dependencies, so there's nothing to be lost for them > either. A closer look at the actual zope.mimetypes code reveals that it really depends on a great lot of packages which just hadn't been listed among the dependencies. These include zope.app.form so that zope.mimetype ends up with 12 direct dependencies (excluding testing dependencies) and 48 dependencies counting transitive ones, including the ZODB. We should try to resolve some of them, in particular the one on zope.app.form, but we'll likely not get significantly smaller numbers. Therefore I change my original proposal: Let's no longer try to merge all content-type-related functionality into one package but let's rather stick with two packages: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK - zope.mimetype: Zope interfaces for content types plus all the fancy form and icon stuff, preferrably sane dependencies I'm still going to move the zope.publisher.contenttype functionality to zope.contenttype which will ease some packages' dependencies, and I'll try to move some appropriate bits of code from zope.mimetype to zope.contenttype. -- Thomas ___ 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] Updating the ZTK KGS
Martijn Faassen wrote: > So I'd propose the following development process: > > * developers can change the version numbers in the ZTK > > * if the compattests all run, they can check in I'll go ahead and update the KGS with my proposed new versions then; if someone experiences a problem with this, feel free to flame me ;o) > * what does a release look like exactly? We should at least have a > documentation release sitting somewhere on docs.zope.org, with the release > number in the URL. The 'current' URL should also point to this > documentation. Along with this we should also publish the lists of > versions for reuse. How? I see two options: - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL - release a ztk egg that depends on the exactly versioned packages The latter is probably the more reusable. -- Thomas ___ 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] Proposal: cleaning up the content-type story
Tres Seaver wrote: > Thomas Lotze wrote: >> Following up to Martijn's observations on the ZTK, I'd like to propose a >> clean-up of how we handle content types. There are several unrelated >> pieces of code concerned with content types, these include at least >> zope.contenttype, zope.mimetype and zope.publisher.contenttype. >> >> - zope.contenttype does some content-type guessing from file names. It's >> just a few lines of code and comes with a table of some 30 >> associations of file-name extensions with content types. >> >> - zope.mimetype is a more substantial package that deals with >> content-type specific marker interfaces. I actually forgot to mention that zope.mimetype comes with another table associating content types with file name suffixes and other information. It would certainly be a good idea to have only one such data collection to maintain. >> - zope.publisher.contenttype contains a parser for content-type >> specifications. >> >> I propose merging those two packages and one module into one package, >> zope.contenttype. [...] > > - How do 'zope.file' and 'zope.filerepresentation' interact with these >modules? zope.file uses zope.mimetype to have a structured way of talking about content-type-related properties of file objects, and zope.publisher.contenttype for parsing content-type strings. zope.filerepresentation only defines some interfaces and uses none of the modules in question. > - How do these modules interact with the standard library's 'mimetypes' >module? Both zope.contenttype and zope.mimetype use the mimetypes module to guess content-types from file names. In fact, both even do some guesswork based on the first bytes of file content. Probably merging the two involves essentially dropping one of the implementations. I also wonder whether it might make sense to utilise the /etc/mime.types database (or the system's equivalent) for guessing based on the file-name extension, and libmagic (if available) for magic-number tests based on file contents. But of course, these ideas don't have much to do with the restructuring discussed in this thread. -- Thomas ___ 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] Proposal: cleaning up the content-type story
Following up to Martijn's observations on the ZTK, I'd like to propose a clean-up of how we handle content types. There are several unrelated pieces of code concerned with content types, these include at least zope.contenttype, zope.mimetype and zope.publisher.contenttype. - zope.contenttype does some content-type guessing from file names. It's just a few lines of code and comes with a table of some 30 associations of file-name extensions with content types. - zope.mimetype is a more substantial package that deals with content-type specific marker interfaces. - zope.publisher.contenttype contains a parser for content-type specifications. I propose merging those two packages and one module into one package, zope.contenttype. At present, zope.contenttype doesn't have any dependencies within the ZTK, and zope.mimetype depends on zope.configuration, zope.component and zope.interface. zope.publisher.contenttype doesn't import any zope code. - Switching packages that depend on zope.mimetype would therefore add no additional dependencies to them. - There are three packages within the ZTK and the set of packages under review which depend on zope.contenttype: zope.browserresource, zope.app.file and zope.app.onlinehelp. All of them already depend on zope.mimetype's dependencies, so there's nothing to be lost for them either. - Finally, the same holds for zope.publisher which would only acquire a new dependency on zope.contenttype if zope.publisher.contenttype were to be merged with the latter. Further, the parser in zope.publisher.contenttype needs to be made more conformant with RfC 2045 and be used by other code that does some content-type matching of its own right now, such as zope.publisher.http. -- Thomas ___ 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] Updating the ZTK KGS
Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages: zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0 -- Thomas ___ 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] Dependencies of zope.error
Martijn Faassen wrote: Thomas Lotze wrote: >> I think I'll release the current zope.error later today so people get >> the benefit of the lighter dependencies. > > Given you access to this too. :) Thank you, I've just made the release. -- Thomas ___ 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] Undeclared dependency of zope.site on zope.app.publication
Martijn Faassen wrote: > Thomas Lotze wrote: >> I just noticed that zope.site depends on zope.app.publication, both via >> configure.zcml and the tests. The dependency isn't currently declared. >> On the other hand, zope.app.publication doesn't yet depend on zope.site. >> >> I'd like to get rid of the dependency of zope.site on zope.app.publisher >> and I think it would be OK to invert it by moving the relevant ZCML >> declarations (two event handler registrations) and the two pieces of >> test regarding traversal behaviour to zope.app.publisher, which would >> thereby grow a new dependency on zope.site. What do others think? > > At first glance I'm +1 on doing this. We'll need analyze what we can do > with zope.app.publication too. I've just committed changes to the packages to remove any trace of zope.app.publication from zope.site. The handlers in question are still implemented by zope.site as they are not z.a.p specific, and conditionally registered by z.a.p if zope.site is installed. This makes zope.site a testing dependency of zope.app.publication. Could someone with the appropriate privileges please grant me PyPI access to the two packages so I can make releases? (Though releasing zope.site might wait until another issue involving it has been resolved.) -- Thomas ___ 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] Dependencies of zope.error
Tres Seaver wrote: >> - zope.error depends on zope.container solely in order for the error >> reporting utility to be able to subclass Contained, which in turn >> calls itself a silly mix-in class. Also, zope.error makes no use of >> the fact that the utility is Contained. Should the Contained support >> be dropped or somehow made conditional on whether zope.container is >> available? > > +1 for dropping Contained. +0 for making it conditional. I've dropped the dependency on the Contained mix-in class but not the fact of the utility being contained: it now implements zope.location.interfaces.ILocation directly. This means I've dropped the package dependency on zope.container but kept one on zope.location. > +sys.maxint to using a mock request object, and dropping the dependency. Done. I think I'll release the current zope.error later today so people get the benefit of the lighter dependencies. -- Thomas ___ 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] Testing guideline (was: zope.location.pickling.PathPersistent and BBB)
Thomas Lotze wrote: > I've considered all packages mentioned in the current ztk.cfg that come > from the zope.* namespace. [...] > > Come to think about it, I'm not sure whether and how far I should > investigate beyond the ztk for removals like this; are there zope.* > packages in the repository that should no longer be cared about at all? I'd like to take this up again: during the last few days I've stumbled on a number of things I'd like to clean up, such as inter-package dependencies or small changes to some API. Everytime I want to go ahead and try some change, or ask this list about opinions along with a best possible description of what it would imply for other Zope packages, I keep finding that it is still not well defined what's the minimal or the optimal set of packages that need to be taken into consideration before committing to the trunk or even releasing a new version of a package. There's also nothing about this on to be found in the ZTK docs unless I've overlooked something obvious. There are a number of sets of packages that are or might conceivably be of interest: - obviously what ztk.cfg lists as included packages - probably what ztk.cfg lists as packages under review - possibly what other packages are pinned by ztk.cfg as dependencies - probably not what's called zope.* in subversion While it is clear that the packages included in the ZTK need to be OK at all times, I'm pretty sure that they alone aren't sufficient. As an additional observation, not all the packages listed as dependencies in ztk.cfg are passing their tests currently: zope.kgs and zope.app.keyreference don't. I'd be very much interested in a clear guideline on which packages need to pass their tests after a change for a developer to feel safe about committing it to the trunk. Stephan: We've talked about this and some related things when you visited us at our office in Halle. Have you made your notes from that meeting available yet? Apologies if I just haven't noticed that you did. -- Thomas ___ 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] Dependencies of zope.error
- The last release of zope.error doesn't have all dependencies declared while work has been done on the trunk to fix that. Is there a specific reason why no new release has been made since? - zope.error depends on zope.container solely in order for the error reporting utility to be able to subclass Contained, which in turn calls itself a silly mix-in class. Also, zope.error makes no use of the fact that the utility is Contained. Should the Contained support be dropped or somehow made conditional on whether zope.container is available? - zope.error depends on zope.publisher which is only used by the tests in order to provide a request object from which to read some information for the error log. However, the code that reads that information is rather liberal as to what the request actually is, and doesn't technically require it to be a zope.publisher HTTP request. I think this should be made more consistent by either making the error logging code stricter or using a minimal request object in the tests. Opinions? Cutting the dependency on zope.container would drop the total number of dependencies of zope.error (trunk) from 30 to 22, additionally cutting the dependency on zope.publisher would make it 10. -- Thomas ___ 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] various ZTK observations
Martijn Faassen wrote: > Thanks for doing this analysis! It'd be great if you could turn this into > a proposal for future actions... Do you mean a proposal that would go in the "Proposals" section of the ztk docs? > I'm surprised about the difference in dependencies between zope.file and > zope.app.file: isn't zope.file an extracted version of zope.app.file? If > not, we need to think about that too. It isn't, they both have a long separate history. They also provide completely unrelated interfaces and implementations of file content objects. -- Thomas ___ 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] Undeclared dependency of zope.site on zope.app.publication
Michael Howitz wrote: > Am 23.09.2009 um 08:06 schrieb Thomas Lotze: >> I just noticed that zope.site depends on zope.app.publication, both via >> configure.zcml and the tests. The dependency isn't currently declared. >> On the other hand, zope.app.publication doesn't yet depend on zope.site. >> >> I'd like to get rid of the dependency of zope.site on zope.app.publisher > > Do you mean zope.app.publication here and in the following lines? Yes, of course. -- Thomas ___ 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] Undeclared dependency of zope.site on zope.app.publication
I just noticed that zope.site depends on zope.app.publication, both via configure.zcml and the tests. The dependency isn't currently declared. On the other hand, zope.app.publication doesn't yet depend on zope.site. I'd like to get rid of the dependency of zope.site on zope.app.publisher and I think it would be OK to invert it by moving the relevant ZCML declarations (two event handler registrations) and the two pieces of test regarding traversal behaviour to zope.app.publisher, which would thereby grow a new dependency on zope.site. What do others think? -- Thomas ___ 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] various ZTK observations
Martijn Faassen wrote: > * zope.contenttype: we should analyze what is using zope.contenttype. Of the packages mentioned in ztk.cfg, zope.browserresource, zope.app.file and zope.app.onlinehelp are. There's also zope.mimetype which seems to be concerned with the same subject and is used by zope.file and zope.html, and there's some MIME-type handling being done without using either zope.contenttype or zope.mimetype by zope.publisher and possibly others. Last time I looked, these different pieces of code didn't even treat content type declarations consistently nor correctly wrt the relevant RfC. I guess one might want to clean up this story as a whole. -- Thomas ___ 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] zope.location.pickling.PathPersistent and BBB
Martijn Faassen wrote: > Sounds like you did the research. I've considered all packages mentioned in the current ztk.cfg that come from the zope.* namespace. The BBB stuff from zope.location.pickling is neither used by any of them, nor do compat-tests involving the pinned versions of those packages and the modified zope.location fail. Come to think about it, I'm not sure whether and how far I should investigate beyond the ztk for removals like this; are there zope.* packages in the repository that should no longer be cared about at all? > I'm +1 on removing it. Done. -- Thomas ___ 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] zope.location.pickling.PathPersistent and BBB
I asked about this before; let me do so again before assuming silence to mean consent: There's a PathPersistent class in zope.location.pickling which is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code. As PathPersistent is the only user of the ITraverser interface within zope.location, removing it would also make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally. Does anyone object to these changes? -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
Andreas Jung wrote: > I can not remember having seen any support this feature. If you need it, > please add it to the Zope 2 trunk I'll see about it ASAP. > (however too late for the Zope 2.12 release, sorry :-)) That's fine. -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
Andreas Jung wrote: > On 15.09.09 08:00, Thomas Lotze wrote: >> - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. >> should the two be linked to each other in the first place? >> > What is the ZCML dev-mode? It's a so-called ZCML "feature" that can be used with ZCML conditionals. It can be switched on like this: and used elsewhere like this: -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
I asked this a month ago without getting any responses, so I'll give it one more try: We recently ran into an issue with debug/development mode when making z3c.hashedresource work with Zope2: The package implements different behaviour depending on whether the dev-mode feature is enabled in the ZCML of a Zope3 application, and we sort of expected this feature to be automatically enabled or disabled in a Zope2 application using Five when Zope2 debug-mode is switched on or off, resp. As this doesn't seem to be the case, we were wondering a few things: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? - If so, is it a bug that ZCML dev-mode isn't controlled by Zope2 debug mode in a Five application? Or is it and we're just missing something? - If the the two should be connected but aren't, what's the best way to fix things? Should this be fixed in Five? Otherwise, how to achieve switching on the ZCML dev-mode feature the right way? Independently of these questions, wouldn't it make sense for ZCML to have, in addition to "feature" and "installed", a conditional verb "expression" that allows referencing a Python expression defined in a module whose boolean value to use for deciding the condition? -- Thomas ___ 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] Python versions supported by the ZTK
Adam GROSZER wrote: > If you're thinking of testing the ZTK KGS packages, there shall be > buildbots for that soon running tests on the (supported OSs x supported > Python versions) matrix. While this is nice, I think it's also a good idea to make it easy for developers to run all relevant tests *before* committing their changes. -- Thomas ___ 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] Python versions supported by the ZTK
Martijn Faassen wrote: > Good point. I think right now the ZTK is supposed to support 2.4 to 2.6 > (thanks to Jim's work in particular to fix it). I've added this to the > Zope Toolkit documentation now, under "development process". Maybe there should also be a standard way of executing tests for all supported versions of Python. Some packages such as zope.testing already do this. -- Thomas ___ 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] Python versions supported by the ZTK
What's the oldest Python version the ZTK is supposed to support? 2.4? The ZTK docs don't seem to say anything about this. -- Thomas ___ 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] zc.buildout, substitution and templating
Encolpe Degoute wrote: > Can I add it in the trunk or does anybody want a branch ? Do it on a branch, even if it seems trivial. At least you'll want to run the tests on different systems before modifying the trunk, which will be easier when you can check the changes out from a branch. -- Thomas ___ 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] Needed: zc.recipe.cmmi release
Wichert Akkerman wrote: > The latest zc.recipe.cmmi release started using the zc.buildout download > API but does not depend on zc.buildout 1.4 or later, which broke several > buildouts for me. I've fixed the dependency in r103703. Can someone make a > new release? Done. -- Thomas ___ 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.location.pickling.PathPersistent and BBB
While wondering about the ITraverser interface being defined by zope.location, we noticed that the zope.location.pickling.PathPersistent class (which is this package's only user of the interface) is decorated with a recent BBB comment, and had been questioned by a XXX comment for some time before that. The class doesn't seem to be used anywhere in Zope, so removing it would rid zope.location of some unused code as well as make it possible to move ITraverser back to zope.traversing where it fits much better conceptionally. What are your opinions on this, does anyone object? -- Thomas ___ 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] zc.buildout, substitution and templating
Encolpe Degoute wrote: > As zc.buildout is using something near string.template I patched > gocept.recipe.env to replace '$' by '$$' and collective.recipe.template to > replace '$$' by '$'. For the record: gocept.recipe.env hasn't yet been patched; I'd rather discuss the issue first before applying your patch. > As _sub method in builout just split text around '$$' and join it again > with '$$' we need to make the replacement with the result of this > method. > > Is it the good way to deal with escaping data ? Or is this a bug of > zc.buildout ? I think it's a bug in zc.buildout if it cannot read the configuration storage it wrote earlier itself. A good API for dealing with configuration options shouldn't require client code such as recipes to care about encoding and decoding values in order to work around the details of buildout's option representation. This would be awkward and, as we can see with the issue at hand, would only work if all client code handled the encoding consistently. I therefore propose fixing buildout so that it encodes option values when writing .installed.cfg just as it would decode them when reading the file. -- Thomas ___ 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] Move implementation of getParent to zope.location?
Martijn Faassen wrote: > One question to ask is whether getParent and getParents are used all over > the place or just by zope.traversing. If they're only used by > zope.traversing we might not want to move them to a more general place, > but perhaps we can even see about removing them. getParent is used by a number of zope.app.* packages (apidoc, container, dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its only other occurrence is in zope.traversing where it is defined, but not used. getParents is used by zope.app.* packages as well (rotterdam, tree, workflow) and definitions of it occur in zope.location and zope.traversing, where it isn't used either, though. Seeing this now, I agree to removing the functions provided nobody objects against removing parts of the API that might be depended on by client code out there. (Both functions are actually exported by zope.traversing.api.) -- Thomas ___ 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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals
We recently ran into an issue with debug/development mode when making z3c.hashedresource work with Zope2: The package implements different behaviour depending on whether the dev-mode feature is enabled in the ZCML of a Zope3 application, and we sort of expected this feature to be automatically enabled or disabled in a Zope2 application using Five when Zope2 debug-mode is switched on or off, resp. As this doesn't seem to be the case, we were wondering a few things: - Is Zope2 debug mode semantically equivalent to ZCML dev-mode, i.e. should the two be linked to each other in the first place? - If so, is it a bug that ZCML dev-mode isn't controlled by Zope2 debug mode in a Five application? Or is it and we're just missing something? - If the the two should be connected but aren't, what's the best way to fix things? Should this be fixed in Five? Otherwise, how to achieve switching on the ZCML dev-mode feature the right way? Independently of these questions, wouldn't it make sense for ZCML to have, in addition to "feature" and "installed", a conditional verb "expression" that allows referencing a Python expression defined in a module whose boolean value to use for deciding the condition? -- Thomas ___ 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] Move implementation of getParent to zope.location?
There are two functions in zope.traversing.api, getParent and getParents, that are rather closely related. The former is implemented right in that module while the latter adapts its argument to zope.location.interfaces.ILocationInfo and calls getParents() on that. Why is getParent not a part of ILocationInfo? If there's no good reason, I'd propose adding getParent() to the interface and changing the getParent function in zope.traversing to work similarly to getParents, i.e. call a method on an ILocationInfo adapter. -- Thomas ___ 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] Creating new five.* package
We've started a new package, five.hashedresource, that is supposed to integrate z3c.hashedresource into Zope2. Just to make sure not to step on someone's toes: is it OK to just create such a package in that namespace? -- Thomas ___ 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] Manuel Beta
Benji York wrote: > I've just released the first beta of Manuel, my next-generation doctest > project. Many thanks for the ideas and work you put in manuel! > I'm interested in any feedback and/or questions you may have be it > technical, documentation, or "marketing" (i.e., how do I describe what > Manuel does and what benefits it has). I have a technical comment: If you want to use manuel for writing some test logic that works region by region (which I suspect is a rather standard use case), you have to do some boilerplate wiring that involves iterating over region and making sure that you really only evaluate matching regions and format your own results. It would be nice to have a way to create a Manuel object from just some matching expressions and code that applies to a single example. To see what I mean, you might take a look at tl.testing (the cairo module). The code there is split up into testing logic that compares cairo surfaces to images of the expectations (the Test and Result classes) and a Manuel class that just ties it all up. To have something like that Manuel class provided by the manuel package would be quite helpful. That module also defines its own doc file suite, mainly in order to have a test suite factory with all the features of the standard (or rather, zope.testing) doc test suite. To have a more elaborate doc file suite available from manuel would also be good. -- Thomas ___ 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] Standard request/response API
Jim Fulton wrote: > Speaking for myself, I'd be happy to change my code to comform to a > python-standard request API assuming that it had enough in it to adapt it > to existing APIs. Without having used it myself yet, and without making any claim about it being a Python standard, this makes me think of WebOb by Ian Bicking. It defines request and response implementations around WSGI and has evolved from Paste. -- Thomas ___ 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.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList
Gary Poster schrieb: > OK. I'll give it a whirl sometime over the next couple of weeks, if > that's soon enough for you. Sure. > FWIW, I'd be strongly tempted to release *without* the generation > code, and leave it up to users to switch as they desire. Fine with me. I'm pretty confident of the other changes I've made, BTW, and there's not exactly a lot of them either. > 1) That's particularly pertinent for library bits like this because a > tree walker would have to walk over *all* attributes and __getitem__s > in order to find instances of things like a blist, which will > generally be hidden deep in application objects; or would have to use > an iteration protocol like the one that FileStorage provides. Right. Looking closer at the utility function I've used so far for walking the objects, I think it doesn't nearly cover all the places a dict could hide. > 2) Old instances (with lists, not blists) will still work fine with > the new code, and in fact should continue to work even with new apis > as long as the ordered dict apis use the list apis (like slices) to > manipulate the order. They do. > 3) How many people are really using the blist right now anyway in > production? No idea... > Generation code is hard to test in the abstract. Do we actually have any best practices for that? Viele Grüße, Thomas -- Thomas Lotze · t...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] [Checkins] SVN: zc.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList
Thomas Lotze schrieb: > Yes, and I think that we're talking about two steps here anyway. I'd > like to finish and release a version that uses BLists ASAP; Well, I think the switch to BLists is finished, so I'd be ready to merge it to the trunk after someone reviewed the changes. In particular, I'm not sure that wiring up and testing the database generation follows best practices. Viele Grüße, Thomas -- Thomas Lotze · t...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] [Checkins] SVN: zc.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList
Gary Poster schrieb: > Hi Thomas. Very cool that you are working on zc.dict + zc.blist. Better than letting that branch get old ;o) > The updateOrder API is a sucky API for blists, as I'm sure you've > realized. :-) It is sucky even when used with a PersistentList; it's just that the disadvantages of its implementation are more obvious in the context of BLists. > FWIW, I seem to recall that Plone has a reasonable-to-nice API for > changing order in containers, and the API would be able to take much > better advantage of using blists for the ordering. I was intending to > study that when I designed the new API (even if the Plone API were > perfect, I would be wary of copying it because of GPL vs. ZPL, but > maybe you could get them to relicense if you wanted it). I'll take a look at that, thanks for the pointer. > You'd probably still want to keep updateOrder around, I guess, since > that's the Zope 3 interface, but I would have documentation > discouraging it. Yes, and I think that we're talking about two steps here anyway. I'd like to finish and release a version that uses BLists ASAP; an additional API can always be added in a subsequent release. Viele Grüße, Thomas -- Thomas Lotze · t...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zope.interface: verifyObject vs properties
Jim Fulton wrote: > I would change it to just use getattr rather than hasattr. > > try: > getattr(ob, name) > except AttributeError: > return False > ... Given the controversy about our original proposal, I think I'll just implement Jim's suggestion. I'll do so as soon as possible. -- Thomas ___ 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.interface: verifyObject vs properties
Tres Seaver <[EMAIL PROTECTED]> schrieb: > Dieter Maurer wrote: > > class C(object): > >implements(I) > >m = property(lambda self: lambda ...: ...) > > > > > > i.e. when a method (declared by the interface) is implemented by a property. > > Why would I want to do that, rather than using 'def m(self):'? - to win an obfucated-code contest - to get an additional closure for the method that is created each time the method is accessed Viele Grüße, Thomas Lotze -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zope.interface: verifyObject vs properties
"Dieter Maurer" <[EMAIL PROTECTED]> schrieb: > "verifyObject/verifyClass" is likely not to handle the following > case correctly: > > class I(Interface): >def m(...): > ... > > class C(object): >implements(I) >m = property(lambda self: lambda ...: ...) > > > i.e. when a method (declared by the interface) is implemented by a property. Ah, I see. Thank you. Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zope.interface: verifyObject vs properties
"Dieter Maurer" <[EMAIL PROTECTED]> schrieb: > And if the attribute is implemented by a property (of the class, i.e. > the decriptor is on the metaclass), then the descriptors "__get__" > is called (in the same way as for "verifyObject"). > Instance properties (descriptor on the class) may not define methods > (probably a bug). I don't understand what you're saying in that last sentence; can you elaborate? Viele Grüße, Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zope.interface: verifyObject vs properties
Christian Theune <[EMAIL PROTECTED]> wrote: > Arguably, the check for an attribute would be sufficient if it checked > whether an attribute implementation is around -- either by a simple > attribute value or a descriptor providing that. At this point, I guess the outcome of the discussion depends on whether it is considered legal or abuse to implement a data descriptor in such a way that it hides an attribute defined on a base class by raising an AttributeError. > There's another method: verifyClass. This definitely only checks the > presence of an implementation. To be more precise: the declaration of implementation of an interface as opposed to actual implementation of its attributes. > Thomas: There is an issue that we regularly see with verifyClass that > makes us instanciated the objects and then use verifyObject. I don't > remember what it was right now. Do you? Not really, other than to avoid the case of a happy verifyClass() call with the application dying of a forgotten attribute implementation. Could there be classes we subclass that claim to implement an interface but don't fully do so until after instantiation? Just a guess... Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zope.interface: verifyObject vs properties
"Dieter Maurer" <[EMAIL PROTECTED]> wrote: > I fear your must describe your proposed change more precisely: Nothing to be afraid of here ;o) > When your problem is the stated use case: "verifyObject" fails > because something necessary for the interface to be properly implemented > is missing in the test but available in a real environment, Yes, this is what I'm talking about. > I would say: that is very fine: Do not change "verifyObject" but > give the test instead the resources expected to be available in the > real environment. I think this line of reasoning intermingles two different things to be tested: the existence of an implementation of an attribute (as a data descriptor, whatever its getter method tries to do), and whether the attribute's value is sensible at any given point of time. You can compare this to a plain attribute promised by an interface: if it exists on an object that claims to provide the interface, verifyObject will be happy. The attribute's particular value at the time verifyObject looks at it may still be something very stupid from the point of view of the application. The latter is the subject of a different test, not one of interface implementation. To put it differently: If I implement a class and give its instances all attributes defined by a given interface then I expect verifyObject to damn well see that those attributes are there, without having to do all sorts of stuff in a completely different part of the code just in order to satisfy verifyObject's implementation. I'm aware that this is purely from the point of view of the user and does not take into account any design discussions that may have taken place when verifyObject was created. > When you want to provide a better (more informative) exception > (not "fails to implement" but "ComponentLookupError"), then I am with you. This would be better than the current behaviour, but it would still lie because of the difference between the existence of an implementation of the attribute in question and its successful execution in a given set of circumstances. Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zope.interface: verifyObject vs properties
Jim Fulton <[EMAIL PROTECTED]> wrote: > I would change it to just use getattr rather than hasattr. > > try: > getattr(ob, name) > except AttributeError: > return False > ... This doesn't handle the case that the attribute exists as a property but raises an AttributeError when trying to produce its value. Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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 )
[Zope-dev] zope.interface: verifyObject vs properties
There has been a problem with zope.interface's verifyObject function that occurs in conjunction with Python properties: when verifyObject checks for the presence of an object's attribute, it does so by using hasattr() which in turn tries a getattr() call. If the attribute is implemented as a property, this may raise an exception which will be masked by hasattr() due to a bare except: clause. One scenario where this is a problem is a property that performs some component lookup which will succeed at application runtime but not in unit tests where verifyObject is commonly used. While it has also been argued that behaviour so complex that it may raise an Exception should not be implemented as a property in the first place, we believe that verifyObject should handle this case better than it currently does. A possible fix would be to add an additional check for a data descriptor on the object's class if the hasattr() test returns False. Are there any objections against modifying verifyObject in this way? Thomas -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc 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] zc.dict.OrderedDict efficiency
Gary Poster wrote: [zc.blist] > To release it responsibly now, someone needs to claim maintainership. As I was the one asking in the first place, I'm willing to do this unless there's a policy for zc.* packages to be maintained by ZC people or something similar. -- Thomas ___ 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] zc.dict.OrderedDict efficiency
The documentation of OrderedDict from zc.dict 1.2.1 states that the current implementation is inefficient for large collections because it uses a PersistentList to store the order. It also says that a BList which would be preferrable is not used as it is not yet released. - What's the state of those BLists? Are they just around the corner or would it be worthwhile to consider some interim solution to the efficiency issue? - If the latter, what about storing the order by * introducing internal integer keys incremented for each newly added item and * mapping from integers to keys and values in one BTree and from keys to integers and values in a second (or using more BTrees to avoid storing those pairs)? This introduces somewhat more overhead in general but prevents the bad behaviour for large collections. Would that be an acceptable trade-off? -- Thomas ___ 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.app.form: Make "no value" always available?
Tres Seaver wrote: > Thomas Lotze wrote: >> Oh well, it turns out that this doesn't really work well as the class in >> question is used as a base class by all the items edit widgets. The >> next-best approach we'd try would be a module-global flag that turns the >> old behaviour back on and must be set during application start-up for >> BBB. Would that be an acceptable solution? > > +0 if you release it with a new "major" release number (i.e., 3.6.0), and > document clearly how to get the BBB behavior. If you need to release with > a new "minor" number (i.e., 3.5.1), then the BBB behavior must be the > default. I've done that. Dropdown widgets now display a "no value" item instead of selecting the first option, while select widgets and radio button groups don't need this since they can just leave everything unselected. Also, I've changed SourceSelectWidget so that it doesn't turn its `required` attribute off except in BBB mode. This is no longer useful for SourceDropdownWidgets and seems to have been a bug anyway for SourceSelectWidgets and SourceRadioWidgets. I'll release zope.app.form 3.6.0 tomorrow if nobody objects. If someone gives me access to the package on PyPI (username: tlotze), I can also upload it there. -- Thomas ___ 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.app.form: Make "no value" always available?
Thomas Lotze wrote: > Roger Ineichen wrote: > >> Since this is a miss behavior and I agree that this should get fixed. We >> probably should think about a solution which supports the old behavior >> by default. >> >> Note, this whould probably also break other packages like >> z3c.csvvocabulary. > > We've thought about this some more. Our current suggestion is to > implement both behaviours using a class attribute for switching, with > the base class implementing the new, better one and a subclass setting > the attribute differently for BBB. Oh well, it turns out that this doesn't really work well as the class in question is used as a base class by all the items edit widgets. The next-best approach we'd try would be a module-global flag that turns the old behaviour back on and must be set during application start-up for BBB. Would that be an acceptable solution? -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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.app.form: Make "no value" always available?
Roger Ineichen wrote: > Since this is a miss behavior and I agree that this should get fixed. We > probably should think about a solution which supports the old behavior by > default. > > Note, this whould probably also break other packages like > z3c.csvvocabulary. We've thought about this some more. Our current suggestion is to implement both behaviours using a class attribute for switching, with the base class implementing the new, better one and a subclass setting the attribute differently for BBB. We'd like to register the base class with changed behaviour as the default, though, in order to facilitate adoption of the new and better implementation and provide an override registration for the BBB widget. Applications would then have an easy migration path, having to add only one line of ZCML after the zope.app.form update. Also, we'd like to implement the new behaviour in such a way that the "no value" value isn't shown for required fields that already have a valid value set. What do others think about this? Viele Grüße, Thomas Lotze -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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.app.form: Make "no value" always available?
Roger Ineichen wrote: > I agree with this but... > The 2750 test in one of our well tested application will explode. And > probably some tests in the zope core and z3c will break too. > > Since this is a miss behavior and I agree that this should get fixed. We > probably should think about a solution which supports the old behavior by > default. Fine with me. > If nobody else objects I'm fine with this changes and will fix a Zope3 > revision for this project and start to migrate to z3c.form. We have to do > that anyway sometimes. I don't understand what you're saying here. Are you talking about that application of yours that you've refered to earlier? Who has to migrate to z3c.form, and how does this affect the development of zope.app.form? -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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.app.form: Make "no value" always available?
zope.app.form items edit widgets don't provide the "no value" value if the corresponding field is required. While this prevents invalid input, it means that e.g. a drop-down box may then have one of the valid values pre-selected. If user forgets to change that value, he could save the form without noticing that the default value is implicitly selected, which may be completely wrong. In some cases it would be preferrable for the widget to default to a "no value" value even if the field is required so the form won't validate if the user doesn't consciously select a value. One of our customers asked for this behaviour, for example. If noone objects, we'd like to change zope.app.form accordingly. -- Thomas Lotze · [EMAIL PROTECTED] gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] Post-commit hooks break on svn.zope.org
Just to note: I received a warning 'post-commit' hook failed with error output: (with no output, though) after committing to svn.zope.org. -- Thomas ___ 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 )
