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
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
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
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,
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,
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
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
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
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':
...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
'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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
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
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,
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
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.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
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
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
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
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
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
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
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.
--
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 113 matches
Mail list logo
