Re: [Zope-dev] naming Zope
On Sat, Apr 11, 2009 at 9:05 PM, Chris McDonough chr...@plope.com wrote: On 4/11/09 7:32 PM, Roger Ineichen wrote: That much dependency cleanup would be fantastic. Yes, cool, but what exactly whould you like to cleanup? The bits that I use are already pretty nicely cleaned up. But in theory, if we did a more reasonable job of dependency management, I'd be able to use, say, zope.catalog without getting zope.publisher and ~30 other seemingly unrelated dependent packages sucked down too. That said, I've already created a forked catalog implementation (repoze.catalog) that requires only ZODB and zope.index, so that particular example is not very useful to me personally. Maybe there are other pieces that could have a life outside of Zope-the-application-server. Or maybe not. Maybe they'll just die inside the appserver. It's actually a heck of a lot easier to clean nothing up and just continue to do what I've been doing, which is to fork every package that I find useful so it can be used sanely outside an appserver context. That's been working out ok so far, and it feels better than needing to communicate on this maillist in emails like this one. ;-) Heh. Repoze (unqualified with a suffix) is a whole separate thing; BFG obviously has its own naming issues. I know that the spring turns many people crazy sometimes but hey, we are developer and there a no girls arround ;-) Let me know if the renaming excess is over and please let me know with what I'm working and on what my applications are running at that time. Hey, don't blame me, I didn't create the Zope Framework/Toolkit idea (personally I am not a fan of the concept). But it probably doesn't matter anyway. You needn't pay attention to any of this: nothing has changed at all except for a bunch of names, and even those, not too much. Rightly or wrongly, before the naming discussion came up, I was basically already considering Repoze to be the Zope toolkit. Or Zope 4. The *stated* goals for Zope Mega(tm) seem to align fairly closely with what Repoze already is: extraction of the good, useful ideas from Zope into reusable modules, refactored so as to avoid dependency hell. Some packages in the zope.* namespace are already nice and reusable as is--I don't really care if the tool of the moment starts with zope.* or repoze.*. If the trend were merely to continue these sorts of refactors, call it Zope, or Repoze, or whatever, you would find no complaint from me. Chris ___ 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] naming Zope
I can't believe no one's suggested Zope Mega, yet. Chris On Thu, Apr 9, 2009 at 4:25 PM, Martijn Faassen faas...@startifact.comwrote: Hey, Joy, another naming discussion. Oh well, I started it. :) Zope Toolkit is better name than Zope Framework. I'm fine with renaming Zope Framework to Zope Toolkit if: * someone goes and changes the name in: * the Zope Framework sphinx documentation in SVN * renames the SVN directory * renames the Zope Framework Steering Group to the Zope Toolkit Steering Group * bothers Jens to change the /zopeframework URL to zope toolkit. * updates the story website to talk about the Zope Toolkit, not the the framework. I.e. a great renaming action. If nobody volunteers to do this (feel free to organize more volunteers), we'll stick with Zope Framework. Let me know if you're going to do this and when you're done. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Constant values defined in interfaces
On Fri, Apr 3, 2009 at 7:21 PM, Wichert Akkerman wich...@wiggy.net wrote: Previously Chris Rossi wrote: I was wondering if the Zope collective had given any consideration to allowing constants to be defined in interfaces. To be clear, these are constant values that make up the protocol defined by the interface. Just to have a concrete example, let's say we're modeling an http response: class IHttpResponse(Interface): Models an HTTP 1.1 response. status = Attribute(HTTP status code for this response.) It might be useful to include in our interface spec what some proper values for status code might be and make them available to applications as static constants on the interface class. A naive implementer might do something like this: class IHttpResponse(Interface): Models an HTTP 1.1 response. HTTP_OK = 200 Ok HTTP_NOT_FOUND = 404 Not Found status = Attribute(HTTP status code for this response.) This looks like a poor man's enum. I'ld prefer to have a proper enum like thing. I'm sure you can think of a lot of uses of constant values where an enum wouldn't be appropriate. I don't know that I'd even use an enum in this made up example. Some use cases might be covered by an enum, sure, but that's not really the point here. Thanks, Chris ___ 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] Constant values defined in interfaces
On Sat, Apr 4, 2009 at 6:04 PM, Chris McDonough chr...@plope.com wrote: Using an interface class for a constant container would often be handy but it might be an inappropriate use of interface classes. I would argue that it is appropriate, but that's probably related to my experience with languages other than Python. FTR, I do often put constants in an interfaces.py module at module scope (if there are more than one related, sometimes in a dictionary or within a non-interface class statement) in order to not feel I need to create some constants.py module. Maybe we could just agree that doing so isn't some sort of violation of intent? That works, too. Seeing as I how I don't see much interest, I'll consider this something not worth pursuing further. Thanks, Chris ___ 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] Constant values defined in interfaces
Hello, I was wondering if the Zope collective had given any consideration to allowing constants to be defined in interfaces. To be clear, these are constant values that make up the protocol defined by the interface. Just to have a concrete example, let's say we're modeling an http response: class IHttpResponse(Interface): Models an HTTP 1.1 response. status = Attribute(HTTP status code for this response.) It might be useful to include in our interface spec what some proper values for status code might be and make them available to applications as static constants on the interface class. A naive implementer might do something like this: class IHttpResponse(Interface): Models an HTTP 1.1 response. HTTP_OK = 200 Ok HTTP_NOT_FOUND = 404 Not Found status = Attribute(HTTP status code for this response.) As you can see, the HTTP_OK and HTTP_NOT_FOUND constants are conceptually part of the interface--they help define our contract for http responses. We might expect to then be able to do something like this in application code: response.status = IHttpResponse.HTTP_OK Of course, if you try this currently, Interface will complain: InvalidInterface: Concrete attribute, HTTP_OK I did do some poking around in the source code and in the documentation, such as it is, and didn't see anything like constants in interfaces, but it's possible this use case has already been addressed somehow and I am just ignorant of how, in which case, my apologies, and thanks for telling me the already accepted way to do this. If this hasn't been done yet, I can envision doing something like: from zope.interface import Constant class IHttpResponse(Interface): Models an HTTP 1.1 response. HTTP_OK = Constant(200 Ok, An HTTP Ok response.) HTTP_NOT_FOUND = Constant(404 Not Found, An HTTP Not Found response) status = Attribute(HTTP status code for this response.) Using descriptors, the results could be both static and immutable. Does this seem useful to anyone besides me? Anyone who's done much Java programming will recognize that I did not have an original idea here. If there is a general buy in, I would be happy to attempt an implementation and submit a patch. Thanks, Chris PS I did find a hack that will let you accomplish this, although it is a hack rather than a supported feature of the component architecture: class IHttpResponse(Interface): Models an HTTP 1.1 response. status = Attribute(HTTP status code for this response.) IHttpResponse.HTTP_OK = 200 Ok IHttpResponse.HTTP_NOT_FOUND = 404 Not Found Because the interface class is decorated after the type is instantiated, the InvalidInterface check is avoided. ___ 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 )
