[Zope-dev] Zope Tests: 6 OK, 2 Failed
Summary of messages to the zope-tests list. Period Fri Apr 3 12:00:00 2009 UTC to Sat Apr 4 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: Fri Apr 3 20:53:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011383.html Subject: FAILED (failures=3, errors=1) : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Fri Apr 3 20:59:15 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011386.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri Apr 3 20:45:09 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011379.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Apr 3 20:47:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011380.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Fri Apr 3 20:49:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011381.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Fri Apr 3 20:51:11 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011382.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Fri Apr 3 20:55:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011384.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Fri Apr 3 20:57:15 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-April/011385.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
Wichert Akkerman wrote: > 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. An ssh server running on port 443 (HTTPS) can come in very handy. ssh -D gives you a socks proxy, tsocks makes using this transparent (e.g. tsocks bin/buildout). Failing that, 3G modems are quite reasonable nowdays. Laurence ___ 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] zdaemon is alpha?
Hey All, http://pypi.python.org/pypi/zdaemon indicates that zdaemon is alpha. I would have though it would be marked as stable, given how long its been around? Is there a reason for that? If not, I'll change it on trunk... 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
My 2 cents: I like svn over https. It works reliably, and is easy to use, and externals work as expected, etcs. So I'm +1 on allowing https access. That said, svn+ssh tunnels svn over ssh, and if you are in a place where ssh doesn't work, you need to find the network admit and punch him in the face. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 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
Using an interface class for a constant "container" would often be handy but it
might be an inappropriate use of interface classes. 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?
Chris Rossi wrote:
> On Fri, Apr 3, 2009 at 7:21 PM, Wichert Akkerman 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 )
___
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 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 )
Re: [Zope-dev] Constant values defined in interfaces
Chris McDonough wrote: > 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? +1 Shane ___ 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
Chris Rossi wrote:
> 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.
-1
I think having a more robust way to spell and namespace constants may be
interesting, but what we see above, with a mixed interface/class, is
actually not going to work given zope.interface's semantics. You'd end
up with an interface that promised an attribute that didn't exist.
In Java, you can do:
interface IFoo {
public static String FOO = "foo";
}
class Foo implements IFoo {}
f = Foo();
System.out.println(f.FOO);
In Python with zope.interface, implements() doesn't mean you inherit
attributes. Therefore, you'd need to do:
class IFoo(Interface):
FOO = Constant("foo")
class Foo(object):
implements(IFoo)
FOO = "foo" # or FOO = IFoo['FOO'].get() or something
f = Foo()
print f.FOO
Without repeating the definition of the FOO constant in each class
implementing IFoo, the interface would be promising an attribute that
didn't exist. validateInterface() would complain too.
In general, I don't have a problem with doing constants that are not,
strictly speaking, immutable. I tend to put them in interfaces.py if
they are part of the "contract" of my package. Codifying that as good
practice is probably a good idea. We certainly could come up with some
other way of spelling this, e.g.
class FooConstants(Constants):
FOO = Contant("Foo")
or whatever... maybe some way to mix in zope.schema to to describe the
fields in more details. But it feels like a fair amount of situps when
you can just do FOO = "Foo" at module level and be done with it. Python
is a dynamic language. We don't have privates or final methods or lots
of other things that you can spell in a strictly typed, compiled
language like Java.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Zope-Dev maillist - Zope-Dev@zope.org
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.testing.runner: protecting against rogue threads
Christian Theune wrote at 2009-4-3 08:45 +0200: > ... >I don't want to change the process structure: I only want to assure that >the processes we start also quit. Then no objection from me. -- Dieter ___ 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)]
Chris Withers wrote at 2009-4-2 20:36 +0100: > ... >> 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" The egg-repository can be a "virtualenv" (or even the "site-packages" of a standard Python installation). -- Dieter ___ 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] setting missing minimum version in setup.py
Chris Withers wrote at 2009-4-2 20:42 +0100: > ... >> KGS the >> concept is very easy to implement; you just make available on some URL a >> buildout versions.cfg, or you run your own package index. > >OK, the former I can see happening on an end-user project, the latter is >just too much work. Tres has earlier proposed a meta egg to represent "versions.cfg" in a setuptools only (non buildout) environment. A meta egg is an egg that only list dependencies and does not contain code of its own. -- Dieter ___ 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...
Chris Withers wrote at 2009-4-2 21:29 +0100: >Andreas Jung wrote: >> Andrew & others have been working on this issue at the sprint. There is >> consensus that www.zope.org must be turned into landing page with some >> mission statement and then links to the related subprojects. The current >> zope.org site should be moved to old.zope.org (it must remain >> available for the time being (with URL redirections to the Products >> and Member area). > >Why does it need to keep living even at old.zope.org? Because members put there content (product implementations) still usable? -- Dieter ___ 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 )
