[Zope-dev] New ssh keyfor svn access

2012-04-05 Thread Thomas Lotze
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] New ssh keyfor svn access

2012-04-05 Thread Thomas Lotze
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 )


Re: [Zope-dev] Zope Tests: 140 OK, 13 Failed

2010-12-11 Thread Thomas Lotze
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::
 
   include file=meta.zcml package=zope.component/

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

2010-11-01 Thread Thomas Lotze
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 l...@lrowe.co.uk 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 )


Re: [Zope-dev] Functional areas of Zope

2010-11-01 Thread Thomas Lotze
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 shrug.

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

2010-11-01 Thread Thomas Lotze
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 )


[Zope-dev] Functional areas of Zope

2010-10-18 Thread Thomas Lotze
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

2009-12-21 Thread Thomas Lotze
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 have a plugin system
of any kind (including monkey-patching, for the sake of 

Re: [Zope-dev] A summary of Interfaces vs ZCA concepts

2009-12-21 Thread Thomas Lotze
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

2009-12-20 Thread Thomas Lotze
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] Interfaces vs ZCA concepts

2009-12-17 Thread Thomas Lotze
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] A summary of Interfaces vs ZCA concepts

2009-12-17 Thread Thomas Lotze
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 component lookup
and in particular 

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Thomas Lotze
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

2009-12-16 Thread Thomas Lotze
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 )


[Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Thomas Lotze
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] Interfaces vs ZCA concepts

2009-12-15 Thread Thomas Lotze
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 )


Re: [Zope-dev] the ZCA API decision

2009-12-05 Thread Thomas Lotze
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

2009-12-04 Thread Thomas Lotze
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

2009-12-03 Thread Thomas Lotze
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] the ZCA API decision

2009-12-03 Thread Thomas Lotze
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] implementing zope.component 4.0

2009-12-02 Thread Thomas Lotze
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 t...@gocept.com 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

2009-12-02 Thread Thomas Lotze
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

2009-12-02 Thread Thomas Lotze
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

2009-12-01 Thread Thomas Lotze
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

2009-11-30 Thread Thomas Lotze
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

2009-11-27 Thread Thomas Lotze
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

2009-11-26 Thread Thomas Lotze
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

2009-11-26 Thread Thomas Lotze
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] Releasing zope.browserresource

2009-11-25 Thread Thomas Lotze
Benji York wrote:

 On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com 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] improving the utility and adapter lookup APIs

2009-11-25 Thread Thomas Lotze
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] improving the utility and adapter lookup APIs

2009-11-25 Thread Thomas Lotze
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

2009-11-25 Thread Thomas Lotze
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 )


[Zope-dev] Making zope.dublincore independent of zope.annotation

2009-11-24 Thread Thomas Lotze
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 )


[Zope-dev] Releasing zope.browserresource

2009-11-24 Thread Thomas Lotze
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 )


Re: [Zope-dev] Releasing zope.browserresource

2009-11-24 Thread Thomas Lotze
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 )


Re: [Zope-dev] Where does ISite belong conceptually?

2009-11-03 Thread Thomas Lotze
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] zope.site.hooks

2009-10-19 Thread Thomas Lotze
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] Proposal: cleaning up the content-type story

2009-10-19 Thread Thomas Lotze
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] allow-picked-versions=false in ztk.cfg?

2009-10-08 Thread Thomas Lotze
Martijn Faassen wrote:

 Martin Aspeli wrote:
 Hanno Schlichting wrote:
 On Wed, Oct 7, 2009 at 10:29 PM, Martijn Faassen
 faas...@startifact.com 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] zope.site.hooks

2009-10-07 Thread Thomas Lotze
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] zope.site.hooks

2009-10-07 Thread Thomas Lotze
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

2009-10-07 Thread Thomas Lotze
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] Proposal: cleaning up the content-type story

2009-10-07 Thread Thomas Lotze
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] Proposal: cleaning up the content-type story

2009-10-07 Thread Thomas Lotze
Fred Drake wrote:

 On Wed, Oct 7, 2009 at 11:10 AM, Hanno Schlichting ha...@hannosch.eu
 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 )


[Zope-dev] Removing zope.testrecorder from the ZTK

2009-10-07 Thread Thomas Lotze
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] Removing zope.testrecorder from the ZTK

2009-10-07 Thread Thomas Lotze
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 )


Re: [Zope-dev] Proposal: cleaning up the content-type story

2009-10-06 Thread Thomas Lotze
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] Proposal: cleaning up the content-type story

2009-10-06 Thread Thomas Lotze
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 )


[Zope-dev] zope.site.hooks

2009-10-06 Thread Thomas Lotze
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] Updating the ZTK KGS

2009-10-06 Thread Thomas Lotze
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 )


Re: [Zope-dev] Updating the ZTK KGS

2009-10-05 Thread Thomas Lotze
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 )


[Zope-dev] Updating the ZTK KGS

2009-10-01 Thread Thomas Lotze
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 )


[Zope-dev] Proposal: cleaning up the content-type story

2009-10-01 Thread Thomas Lotze
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 )


Re: [Zope-dev] Proposal: cleaning up the content-type story

2009-10-01 Thread Thomas Lotze
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 )


Re: [Zope-dev] Undeclared dependency of zope.site on zope.app.publication

2009-09-29 Thread Thomas Lotze
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

2009-09-29 Thread Thomas Lotze
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] Dependencies of zope.error

2009-09-28 Thread Thomas Lotze
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 )


Re: [Zope-dev] various ZTK observations

2009-09-24 Thread Thomas Lotze
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 )


[Zope-dev] Dependencies of zope.error

2009-09-24 Thread Thomas Lotze
- 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 )


[Zope-dev] Testing guideline (was: zope.location.pickling.PathPersistent and BBB)

2009-09-24 Thread Thomas Lotze
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] Undeclared dependency of zope.site on zope.app.publication

2009-09-23 Thread 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
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] Undeclared dependency of zope.site on zope.app.publication

2009-09-23 Thread Thomas Lotze
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 )


Re: [Zope-dev] various ZTK observations

2009-09-21 Thread Thomas Lotze
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

2009-09-17 Thread Thomas Lotze
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

2009-09-16 Thread Thomas Lotze
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 )


[Zope-dev] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals

2009-09-15 Thread Thomas Lotze
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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals

2009-09-15 Thread Thomas Lotze
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:

meta:provides feature=devmode/

and used elsewhere like this:

adapter zcml:condition=have devmode factory=foo.bar.baz/

-- 
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

2009-09-15 Thread Thomas Lotze
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] Python versions supported by the ZTK

2009-09-14 Thread Thomas Lotze
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 )


[Zope-dev] Python versions supported by the ZTK

2009-09-13 Thread Thomas Lotze
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] Python versions supported by the ZTK

2009-09-13 Thread Thomas Lotze
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 )


Re: [Zope-dev] zc.buildout, substitution and templating

2009-09-12 Thread Thomas Lotze
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

2009-09-10 Thread Thomas Lotze
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

2009-09-09 Thread Thomas Lotze
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

2009-09-03 Thread Thomas Lotze
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?

2009-08-12 Thread Thomas Lotze
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] Move implementation of getParent to zope.location?

2009-08-04 Thread Thomas Lotze
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] Zope2 debug-mode vs ZCML dev-mode, ZCML conditionals

2009-08-04 Thread Thomas Lotze
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] Creating new five.* package

2009-07-13 Thread Thomas Lotze
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

2009-06-25 Thread Thomas Lotze
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

2009-03-02 Thread Thomas Lotze
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

2008-12-23 Thread Thomas Lotze
Gary Poster gary.pos...@gmail.com 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] [Checkins] SVN: zc.dict/branches/tlotze-blist/src/zc/dict/ordered.txt added a test to ensure the order is stored in a BList

2008-12-23 Thread Thomas Lotze
Thomas Lotze t...@gocept.com 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

2008-12-23 Thread Thomas Lotze
Gary Poster gary.pos...@gmail.com 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] zope.interface: verifyObject vs properties

2008-10-23 Thread Thomas Lotze
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

2008-10-17 Thread Thomas Lotze
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

2008-10-17 Thread Thomas Lotze
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

2008-10-17 Thread Thomas Lotze
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

2008-10-16 Thread Thomas Lotze
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 )


[Zope-dev] zope.interface: verifyObject vs properties

2008-10-15 Thread Thomas Lotze
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] zope.interface: verifyObject vs properties

2008-10-15 Thread Thomas Lotze
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 )


Re: [Zope-dev] zc.dict.OrderedDict efficiency

2008-09-23 Thread Thomas Lotze
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

2008-09-18 Thread Thomas Lotze
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?

2008-08-21 Thread Thomas Lotze
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?

2008-08-20 Thread Thomas Lotze
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?

2008-08-19 Thread Thomas Lotze
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 )


[Zope-dev] zope.app.form: Make no value always available?

2008-08-12 Thread Thomas Lotze
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 )


Re: [Zope-dev] zope.app.form: Make no value always available?

2008-08-12 Thread Thomas Lotze
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] Post-commit hooks break on svn.zope.org

2008-04-30 Thread Thomas Lotze
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 )


[Zope-dev] Re: Re: MIME type syntax (was: Bug in zc.resourcelibrary?)

2007-12-07 Thread Thomas Lotze
Thomas Lotze wrote:

 0.8.1 is out now. It doesn't do any whitespace stripping anymore.

And 0.8.2. It doesn't do any failing on a content tpe of None anymore...

-- 
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 )


  1   2   >