Re: [Zope-dev] zope.testing.runner: protecting against rogue threads
On Thu, 2009-04-02 at 21:17 +0200, Dieter Maurer wrote: Christian Theune wrote at 2009-4-2 13:30 +0200: if tests spawn non-daemon threads, then the test runner can get stuck. The easiest way that I see is to always --exit-with-status and to make --exist-with-status also call sys.exit() when the tests passed. I do not understand the implication. Do you plan that any test runs in a separate process? Then, I would have an objection -- test suites would take far longer. No. What I meant was this: - if non-daemon threads remain after the test runner is done and the main thread exits, the Python interpreter will not exit - we already have the option --exit-with-status which will make the test runner always exit (even when non-daemon threads remain). However, --exit-with-status doesn't use sys.exit() in the case of a test success. I don't want to change the process structure: I only want to assure that the processes we start also quit. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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] uuid.UUID as a rock in zope.security
Hi,
We're using UUIDs a lot, and it's pretty painful that they are security
proxied. They're in the standard library from python 2.5
(http://docs.python.org/library/uuid.html) and are immutable according
to the documentation.
I think they meet all the all the requirements to be rocks. So unless
someone complains, I'll commit the attached patch in a few days.
--
Brian Sutherland
Index: CHANGES.txt
===
--- CHANGES.txt (revision 98805)
+++ CHANGES.txt (working copy)
@@ -5,7 +5,8 @@
3.6.4 (unreleased)
--
-- None so far.
+- Make uuid.UUID a rock, they are immutable and in the python standad library
+ from python 2.5.
3.6.3 (2009-03-23)
--
Index: src/zope/security/checker.py
===
--- src/zope/security/checker.py(revision 98805)
+++ src/zope/security/checker.py(working copy)
@@ -624,6 +624,13 @@
type(pytz.UTC): NoProxy,
})
+try:
+# NOTE: remove try/except when we depend on python2.5 and up. uuid in
standard library from python 2.5.
+from uuid import UUID
+BasicTypes[UUID] = NoProxy
+except ImportError:
+pass
+
# Available for tests. Located here so it can be kept in sync with BasicTypes.
BasicTypes_examples = {
object: object(),
Index: src/zope/security/tests/test_standard_checkers.py
===
--- src/zope/security/tests/test_standard_checkers.py (revision 98805)
+++ src/zope/security/tests/test_standard_checkers.py (working copy)
@@ -424,6 +424,14 @@
from pytz import UTC
int(type(ProxyFactory( UTC )) is type(UTC))
1
+
+ try:
+... # NOTE: remove try/except when we depend on python 2.5 and greater
(uuid in standard library)
+... from uuid import UUID
+... int(type(ProxyFactory( UUID('12345678123456781234567812345678')
)) is UUID)
+... except ImportError:
+... 1
+1
def test_iter_of_sequences():
___
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] z3c.pt bug
2009/4/3 Roger Ineichen d...@projekt01.ch: Can you run the group.txt tests in z3c.form and confirm the issue. A div tag get skipped after some nested repeat tags. (line 898, in group.txt) Running with the latest ``chameleon.core``, ``chameleon.zpt`` and ``z3c.pt``, I only get one test failure: File /Users/mborch/co/z3c.form/src/z3c/form/tests/../group.txt, line 447, in group.txt Failed example: event Expected: zope.app.event.objectevent.ObjectModifiedEvent object at ... Got: zope.lifecycleevent.ObjectModifiedEvent object at 0x26a6bb0 \malthe ___ 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] Dependencies on new packages should require feature releases
Hi, (this message probably just has a reminder function) in one of my apps I had to upgrade many packages to a lot of new versions suddenly when updating zope.publisher. That was caused because zope.publisher started depending on a new (previously non-existing) package within a bugfix release and I was only interested in that bugfix. Reading the Steering Group decisions, I think that's what the last sentence wants to say, but it abruptly ends mid-sentence. @Martijn: You started writing that sentence, you mind finishing whatever you tried to say? (I think it's what I wanted to say with this mail.) :) Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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 Tests: 5 OK, 2 Failed, 1 Unknown
Summary of messages to the zope-tests list. Period Thu Apr 2 12:00:00 2009 UTC to Fri Apr 3 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Test failures - Subject: FAILED (failures=1) : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Thu Apr 2 20:53:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011375.html Subject: FAILED (failures=3, errors=1) : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Thu Apr 2 20:59:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011378.html Unknown --- Subject: UNKNOWN : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Apr 2 20:51:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011374.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 2 20:45:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011371.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 2 20:47:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011372.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 2 20:49:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011373.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 2 20:55:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011376.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Apr 2 20:57:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011377.html ___ 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 Source Code Repository
On Apr 2, 2009, at 7:35 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition. [snip saying I'll do it later, and apology for misunderstanding of Foundation membership] The foundation members are a *subset* of all committers, with sponsoring companies added on. There are under 50 nominated members (formerly committer members, whereas there are something like 375 committers. Any decision to move the repository will need to be formally made by the foundation (via its board), but that would only happen if the consensus of the members and the wider community were clearly in favor of a move. Good to know, thank you. Off to write the email... Gary ___ 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 Source Code Repository
On Apr 2, 2009, at 6:34 PM, Marius Gedminas wrote: - the web front end is ancient and not as good as other options (Trac, WebSVN) +1 for having trac as a subversion browser. In fact, see http://zope3.pov.lt/trac The svn repository mirror used by that trac instance is updated with svnsync every 5 minutes Should we all just use that? Jim -- Jim Fulton Zope Corporation ___ 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 Source Code Repository
On Fri, Apr 3, 2009 at 14:41, Jim Fulton j...@zope.com wrote: Should we all just use that? It's running trac 0.10. I'd love to see trac 0.11, which has additional features that I miss every time I use a 0.10 trac instance, such as the annotate view. Also, I'd include the subversion location plugin, which includes a link to the http:// or svn+ssh:// url for the currently viewed location, for easy checking out. -- Martijn Pieters ___ 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: zope.annotation/trunk/setup.py Whitespace fixes
2009/4/2 Marius Gedminas mar...@gedmin.as: looks like a mistaken assignment of a tuple to a name, while setup( many lines foo=bar, many more lines ) looks like a function call. Agreed; the common use of spaces around the equal signs in setup.py is a holdover from Greg Ward's coding style (Greg being the original author of distutils). AFAICT, they remain prevalent in setup.py because most new setup.py files are generated by copying an existing setup.py from another project. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 Source Code Repository
On Fri, Apr 03, 2009 at 03:04:47PM +0200, Martijn Pieters wrote: On Fri, Apr 3, 2009 at 14:41, Jim Fulton j...@zope.com wrote: Should we all just use that? (that being http://zope3.pov.lt/trac) Sure, I don't mind. It sits behind an ADSL line with puny uplink (512 Kbit/s), but I don't think that will be a problem. It's running trac 0.10. I'd love to see trac 0.11, which has additional features that I miss every time I use a 0.10 trac instance, such as the annotate view. Trac 0.11 has annotate? *WANT* Also, I'd include the subversion location plugin, which includes a link to the http:// or svn+ssh:// url for the currently viewed location, for easy checking out. Sounds good. I'll look into this some time soon. Ping me in a week or so if I forget. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital 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 Source Code Repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.04.2009 17:22 Uhr, Marius Gedminas wrote: On Fri, Apr 03, 2009 at 03:04:47PM +0200, Martijn Pieters wrote: On Fri, Apr 3, 2009 at 14:41, Jim Fulton j...@zope.com wrote: Should we all just use that? (that being http://zope3.pov.lt/trac) Sure, I don't mind. It sits behind an ADSL line with puny uplink (512 Kbit/s), but I don't think that will be a problem. Nothing against your generous offer but I think that trac belongs as a central service on the central repository server. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknWKqsACgkQCJIWIbr9KYzcDgCfaKnN7ogpElGw4JoaRENrlCi4 Kf0AnjeaWL88tkrB4taIzL4/KczpQc9U =8ugy -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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] [ZF] Zope Source Code Repository
Christian Theune wrote: See: http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvements However, this only *allows* clients to manage their password reasonably, it doesn't force them to. Well, you can't force someone to keep their private key private either... At the end of the day, if an svn account is compromised, we'll see a load of bogus commits. My understanding of svn is that those are moderately easy to remove. From my understanding, the interesting part is what the DVCSs do: let people sign their commits with e.g. their PGP key (strong auth) and allow them to share that data somewhere (different mechanism maybe not so strong auth). Well, the only auth bit seems to be where the offical changesets are.. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] [ZF] Zope Source Code Repository
Tres Seaver wrote: - the web front end is ancient and not as good as other options (Trac, WebSVN) Fixing the web front-end should be a matter for the zope-web list. The zope-web list is pretty dead... So I thought I'd ask what the plans are now that the foundation owns all the Zope IP (has this happened yet or am I imagining things?) The foundation now owns the copyrights. Trademarks are still in other hands. This is why I was cc'ing in the foundation list, there is relevant stuff for the foundation group in this discussion... The other option would be to follow Python and move to Mercurial, but that has the same problems for me as with Bzr (no decent gui tools, less mature, etc) although it's a toolset I'll have to learn at some point anyway... +1 to sticking with svn+ssh for write requests. - -1 to non-pubkey-based authentication for write requests. ParseError: what does the above line mean? +1 to making svn-over-http read-only checkouts work. - -1 to switching away from svn, at least until the Python developers have some experience with the transition (I would wait at least 6 months). ParseError: what does the above line mean? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] [ZF] Zope Source Code Repository
Jens Vagelpohl wrote: On Apr 2, 2009, at 22:53 , Tres Seaver wrote: +1 to making svn-over-http read-only checkouts work. This is now working. The repository can be reached under... http://svn.zope.org/repos/main/ Jens, you're my hero :-) Remind me that I owe you beer next time I see you... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 Source Code Repository
Marius Gedminas wrote: The story may be different for Windows users (as usual). +0.5 for alternatively accepting authenticated https access (I'm not the admin, so it doesn't cost me, but I'm also not going to use it) BTW I've yet to see a firewall that blocks SSH. Am I lucky? Yup. In fact, see http://zope3.pov.lt/trac The svn repository mirror used by that trac instance is updated with svnsync every 5 minutes. Wouldn't it be great if you didn't have to do the mirroring (which must do a bit of pounding on svn.zope.org) I would not mind spending some time in a sprint writing a Zope 3 svn key management web app, but that's only a small part of the solution. Authentication and deployment are the other---bigger--two parts. Yes, this was why I was asking on the Foundation list: I want to know what's happening about what machines get used for this stuff... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 Source Code Repository
Andreas Jung wrote: Sure, I don't mind. It sits behind an ADSL line with puny uplink (512 Kbit/s), but I don't think that will be a problem. Nothing against your generous offer but I think that trac belongs as a central service on the central repository server. +1, although if we were to give Marius access to the box, I'm sure he could set it up there and we'd all get what we want (including Marius desire to do the work ;-) ) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 4.0, maybe not such a bad idea...
Gary Poster wrote: Within the constraints above, then, in line with your original proposal, I think we'd be fine with Zope Framework, and Zope 2. We certainly don't need Zope-3-the-tarball, if that's what you meant. Zope Framework (and maybe even ZF4) seems to have general agreement. Zope 2 can't stay as is, because people stick in in the chain of: Zope 1, Zope 2, Zope 3, Zope Framework 4 ...so there will be confusion. Zope Standard 4.0 is my current choice, on the basis that I've not heard any complaints against it yet and I know Andreas hates Zope Classic ;-) As a related aside, I personally think that Plone should be featured here. Indeed. ZF4 as the base for ZS, Plone, Grok and Repoze works for me :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
Tres Seaver wrote: Personally, I evaluate such eggs in a sandbox, and then add them to the project-specific index once I'm sure that they work with the other software in the index: I don't use PyPI at all when building out production sites. That seems overly heavyweight for the average new user. no, sorry, you can't use Zope 2.12 with anything other than what it comes with unless you get your own egg repository running Who is talking about an average new user? We're talking about the standard was of doing things, that encompasses the average user. I don't see how the setup you describe can work unless every user runs their own egg server... new stuff: it sucks as the basis for a repeatable build environment. I think that's a little harsh, if you use buildout and a locked down versions section all you have to worry about is PyPI being down when you don't have the eggs in a local buildout cache. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 Apr 3, 2009, at 12:35 PM, Chris Rossi wrote: Hello, Hi Chris. 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. ... FWIW, interfaces.py is often regarded as a contract itself. A current best practice is to define constants and exceptions in that file, and import them from the module. 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.) How would that be a win for you (or anybody else) over just putting the constant in the interfaces module? If it is in the interface, that implies we need to implement it someplace--the constant will be defined in the interface and in the implementation? Or we would offer automation to copy the values over from the interface to objects that implement the interface? Using descriptors, the results could be both static and immutable. Mostly static and immutable, anyway. :-) In Python, there's almost always a way around absolutes like that unless you are working with something in which the constraint has been coded in C. I don't find enforcing a constant's immutability in any way other than relying on a programmer's good sense to be particularly valuable. I have sympathy for enterprise-y concerns, in which you have some belt- and-suspenders--we use security proxies for that kind of thing, and appreciate them despite their added pain--but I don't see how a programmer might forget to not overwrite an ALL_CAPS constant. And finally, this Constant constructor would control the interface, not the implementation, so you'd have to do the static/immutable things elsewhere. So, I'm -1 on Constant unless someone gives a convincing reason why it is preferable to putting constants in the module, in which case I will suddenly have a polar shift to +0. :-) Gary ___ 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] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Tres Seaver wrote: Personally, I evaluate such eggs in a sandbox, and then add them to the project-specific index once I'm sure that they work with the other software in the index: I don't use PyPI at all when building out production sites. That seems overly heavyweight for the average new user. no, sorry, you can't use Zope 2.12 with anything other than what it comes with unless you get your own egg repository running Who is talking about an average new user? We're talking about the standard was of doing things, that encompasses the average user. I don't see how the setup you describe can work unless every user runs their own egg server... That wasn't what I said: the Personally part was a pretty clear signal that I was being descriptive of my practices, and not prescriptive for others'. new stuff: it sucks as the basis for a repeatable build environment. I think that's a little harsh, if you use buildout and a locked down versions section all you have to worry about is PyPI being down when you don't have the eggs in a local buildout cache. No, you also have to worry about people removing eggs you formerly installed, or uploading new versions without changing the version number, or uploading new, backwards-compatibility-breaking versions, etc. *Nothing* about getting an egg from PyPI is repeatable. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ1k76+gerLs4ltQ4RAtXtAJ9fyMa0g6rB2dJN9soxwEvQ1Vho+gCdHvJw vDbs6CIqAYfvvDgdJm7Vrdc= =fRRq -END 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] [ZF] Zope Source Code Repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Andreas Jung wrote: *This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests. They'll end up being the same group pretty quickly, volunteers are thin on the ground :-/ Maybe, but the one group is doing policy (who should be a committer?), while the other is doing mechanism (get approved committers set up). The groups don't have to overlap, as long as the workflow is clear. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ1l1W+gerLs4ltQ4RAkpoAKCodutcQ4SqhReTJOCFbNkHo67W/gCggtDG /E4Mx4ojLHKH6etlKLxc9ko= =beMU -END 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] [ZF] Zope Source Code Repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.04.2009 21:02 Uhr, Tres Seaver wrote: Chris Withers wrote: Andreas Jung wrote: *This* part needs some fixing, largely because Jim's role their is an artifact of ZC's role, now lapsed, as custodians. At a minimum, there should be a group (I suggest the zope-web regulars) who can take over the maintenance of that application. A *different* group should have the role of collecting / approving the committer access requests. They'll end up being the same group pretty quickly, volunteers are thin on the ground :-/ Maybe, but the one group is doing policy (who should be a committer?), while the other is doing mechanism (get approved committers set up). The groups don't have to overlap, as long as the workflow is clear. The Plone folks use a bugtracker for managing the committer access. A new contributor has to file a new ticket. A similar approach might be suited for managing new Zope committers. Speaking in workflow terms: a policy group could accept or reject the request. The mechanism group will deal with setting up the stuff for the committer and close-ing the case. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknWYSMACgkQCJIWIbr9KYxa4wCfdMbn7xVwowTRTVY9GlRAPMJ9 Mk4AmweFBudg2Z7XHA7JVfrMDVX2fLsk =eB1A -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 Source Code Repository
Previously Marius Gedminas wrote: BTW I've yet to see a firewall that blocks SSH. Am I lucky? Yes. Blocking ssh is very common in larger companies in me experience. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
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. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 Apr 3, 2009, at 7:21 PM, Wichert Akkerman wrote: This looks like a poor man's enum. I'ld prefer to have a proper enum like thing. Seems a little different to me. For what it is worth, though, if you do want an enum in zope.schema, Canonical has lazr.enum: http://pypi.python.org/pypi/lazr.enum . Gary ___ 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 )
