[Zope-dev] File is not Contained

2005-12-13 Thread Thomas Lotze
Hi, I noticed that zope.app.file.File does not inherit from zope.app.container.contained.Contained. This does not stop a file from, e.g., getting added to a folder (and the File type does appear in the ZMI add menu). It does, however, stop you from getting at the File's parent. Currently, File

[Zope-dev] zope.fssync in Zope 2.11

2007-10-02 Thread Thomas Lotze
I just realized that Zope 2.11.0-a1 contains zope.app.fssync but not zope.fssync. This doesn't make much sense to me given that the former depends on the latter. Is there a good reason for it, should both be included, or none of the two? -- Thomas

[Zope-dev] Re: zope.fssync in Zope 2.11

2007-10-04 Thread Thomas Lotze
Philipp von Weitershausen wrote: Thomas Lotze wrote: I just realized that Zope 2.11.0-a1 contains zope.app.fssync but not zope.fssync. This doesn't make much sense to me given that the former depends on the latter. Is there a good reason for it, should both be included, or none of the two

[Zope-dev] Doc strings of IContentProvider

2007-11-11 Thread Thomas Lotze
While trying to implement the outcome of that zope3-dev discussion on pagelets being content providers, I noticed that the doc strings for IContentProvider talk about how content providers are to be looked up: They specify (informally) that content providers are discriminated by context, request,

[Zope-dev] Re: AW: Doc strings of IContentProvider

2007-11-17 Thread Thomas Lotze
Roger Ineichen wrote: The IContentProvider interfaces is a marker interface which describes what a component must support that it get collected by the Tales Expression. As an aside, I think that a marker interface is one that doesn't describe any interface elements at all, but just there to,

[Zope-dev] zope.traversing dependencies

2007-11-20 Thread Thomas Lotze
I just noticed that zope.traversing depends on dozens of packages, most of them (including a lot of zope.app stuff and the ZODB) only through the dependency on zope.app.applicationcontrol. According to the zope.traversing code, the only occasion on which zope.traversing needs

[Zope-dev] Re: zope.traversing dependencies

2007-11-21 Thread Thomas Lotze
Stephan Richter wrote: I think the application control namespace code could simply be moved to zope.app.applicationcontrol, since the latter package does needs zope.traversing anyways. True, but I don't see how to do this cleanly as long as the namespace handler for the etc namespace is

[Zope-dev] Re: zope.traversing dependencies

2007-11-21 Thread Thomas Lotze
Tres Seaver wrote: +100 to shedding the dependencies. Could we have the conditional import work as a fallback to a utility lookup? And then change 'zope.applicationcontrol' to register such a utility? This should be possible, but the utility lookup would have to be conditional as well since

[Zope-dev] Bug in zc.resourcelibrary?

2007-12-04 Thread Thomas Lotze
I found some behaviour of zc.resourcelib which I'm not sure is intended that way: The lib takes care to apply only to HTML and XML content, so it tests whether the content type (if set) is among text/html and text/xml: if content_type == 'text/html' or content_type == 'text/xml': ...

[Zope-dev] Re: Bug in zc.resourcelibrary?

2007-12-04 Thread Thomas Lotze
Benji York wrote: Feel free to make the change you outlined, especially if this is causing you to get incorrect results in one of your apps. I've released 0.8 now, having made the change including case and whitespace normalization as well as tests for the behaviour. It's only at

[Zope-dev] Re: Re: Bug in zc.resourcelibrary?

2007-12-04 Thread Thomas Lotze
Fred Drake wrote: I don't recall if whitespace is allowed around the / in the type; it might not be. The code should probably allow it on input. It wasn't even about whitespace around the / but leading whitespace in front of the major type. Feel free to make the required changes to

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

2007-12-05 Thread Thomas Lotze
Fred Drake wrote: On Dec 4, 2007 5:55 PM, Thomas Lotze [EMAIL PROTECTED] wrote: It wasn't even about whitespace around the / but leading whitespace in front of the major type. Wow. It probably didn't occur to me that would be screwed up. I've now looked up RfC 2045 which states

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

2007-12-05 Thread Thomas Lotze
Christian Theune wrote: That depends on the container format and therefore it's the responsibility of the container (e.g. a HTTP header) to remove the whitespace. Note that AFAICT RFC 2045 section 5.1 (that's what you're referring to AFAICT) defines the MIME type specification as done with

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

2007-12-05 Thread Thomas Lotze
Christian Theune wrote: IMHO we should assume whatever is given to us was unpacked by the container format and is intended to be a valid MIME type. Meaning we should not strip it. OK, then we agree. Good that I did zc.resourcelibrary 0.8, not 1.0 yesterday ;o) -- Thomas

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

2007-12-06 Thread Thomas Lotze
Thomas Lotze wrote: OK, then we agree. Good that I did zc.resourcelibrary 0.8, not 1.0 yesterday ;o) 0.8.1 is out now. It doesn't do any whitespace stripping anymore. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org

[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

[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

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

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

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

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

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

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

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

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

[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

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] zope.interface: verifyObject vs properties

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

[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

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

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

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

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

[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

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

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

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

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

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

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

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

[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

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

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

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

[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

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

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,

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

[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

  1   2   >