Fred Drake wrote:
On Thu, Apr 1, 2010 at 7:29 AM, Martin Aspelioptilude+li...@gmail.com
wrote:
I'm pretty sure it is. The pdb rabbit hole ended at pyexpat.c. I can't
see what's going on there, but when I did 'r' it blew up.
If you can point me at the ZCML file you were trying to parse (or
Hanno Schlichting wrote:
On Thu, Apr 1, 2010 at 9:33 AM, Martin Aspelioptilude+li...@gmail.com
wrote:
Hanno Schlichting wrote:
- Five deprecation
+1 - sounds hairy, though.
Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView
(already done, I guess) would be a good
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Fred Drake wrote:
On Thu, Apr 1, 2010 at 7:29 AM, Martin Aspelioptilude+li...@gmail.com
wrote:
I'm pretty sure it is. The pdb rabbit hole ended at pyexpat.c. I can't
see what's going
Marius Gedminas wrote:
On Thu, Apr 01, 2010 at 06:07:26PM +0800, Martin Aspeli wrote:
I'm not sure if this is a Python issue or a zope issue. We're getting a
segfault on 64-bit SuSE Linux (SLES 11), originating from
z3c.autoinclude, which in turn called zope.configuration'sinclude
Lennart Regebro wrote:
On Thu, Apr 1, 2010 at 18:24, Lennart Regebrorege...@gmail.com wrote:
On Thu, Apr 1, 2010 at 15:53, Tres Seavertsea...@palladion.com wrote:
As you can see from the diffs, I gut sidetracked writing tests for
HTTPResponse, since I needed to make changes to it to do the
Fred Drake wrote:
On Thu, Apr 1, 2010 at 2:17 PM, Tres Seavertsea...@palladion.com wrote:
/me is deeply suspicious of *any* distro-provided python, ever.
I'm also suspicious of 64-bit builds, given that I'm not using one on
my dev machine.
I've picked up the OpenSuSE installation ISOs;
Charlie Clark wrote:
Am 30.03.2010, 17:31 Uhr, schrieb Hanno Schlichtingha...@hannosch.eu:
It simplifies the release process for Zope2. In most cases upgrading
to a new version of Zope2 won't involve any changes to C code. If the
C code is split out, we won't have to release any new Windows
Charlie Clark wrote:
Am 31.03.2010, 13:54 Uhr, schrieb Martin Aspelioptilude+li...@gmail.com:
Why -1 if it's just about windows binaries?
Because I don't think that, if this were the case, this would be the best
solution to the problem.
What would be a better solution?
Windows is sometimes
Christian Theune wrote:
Hi,
here's this week's summary.
For those of you who can't/don't participate in those meetings, there's
the open question about how useful you consider my summaries to be.
Please tell!
Also in short: we decided to keep going with the meetings, so I'd be
happy to
Hanno Schlichting wrote:
Hi there,
I was in too much of a good mood while having some vacation. So I
thought I need more work to do :)
I'd like to step up as the release manager for Zope2 for the 2.12 and
2.13 (trunk) releases.
Sucke^H^H^H^H^H Good man!
Very happy you're doing this. I was
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
What's the next step? I'd love to see some roadmapping ala that you did
for Plone 5, in particular to discuss our WSGI story (which I'm
interested in helping out with if others can help too).
FWIW, I'm
Hanno Schlichting wrote:
Hi.
For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of
the Zope2 distribution itself. Ideally it would not have any C
dependencies in its own distribution
Why?
Martin (who spent all day trying to get Zope 2 to build on SuSE Linux
before realising
Hanno Schlichting wrote:
On Tue, Mar 30, 2010 at 5:26 PM, Martin Aspelioptilude+li...@gmail.com
wrote:
Hanno Schlichting wrote:
For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of
the Zope2 distribution itself. Ideally it would not have any C
dependencies in its own
Log message for revision 110186:
Merge r110185 from 2.12 branch
Changed:
U Zope/trunk/src/Products/Five/browser/resource.py
U Zope/trunk/src/Products/Five/browser/tests/resource.txt
-=-
Modified: Zope/trunk/src/Products/Five/browser/resource.py
Log message for revision 110187:
Hoping that silence (or apathy?) is consent here. :) Adding an event to
indicate when streaming is starting in case of chunked/streamed responses using
response.write()
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U
Log message for revision 110188:
Merge c105589 from 2.12 branch, adding IPubBeforeAbort event
Changed:
U Zope/trunk/doc/CHANGES.rst
U Zope/trunk/src/ZPublisher/Publish.py
U Zope/trunk/src/ZPublisher/interfaces.py
U Zope/trunk/src/ZPublisher/pubevents.py
U
Hi,
In some cases (e.g. large OFS.File/Image responses), Zope 2 will use
response.write() to stream the response.
We have events that fire before and after a regular response is
returned, but none that allow us to set headers (caching headers, in
this case) before such a streaming response is
Hanno Schlichting wrote:
On Sun, Mar 21, 2010 at 10:07 AM, Martin Aspeli
optilude+li...@gmail.com wrote:
We'd therefore like to add a new event in the HTTPResponse class (in
ZServer, though I think it makes sense to add to the ZPublisher base
class version as well). It'd hook in something
Hanno Schlichting wrote:
On Sun, Mar 21, 2010 at 12:05 PM, Martin Aspeli
optilude+li...@gmail.com wrote:
Hanno Schlichting wrote:
Why would you need to have the event on the request, if all you want
is to set headers? Why not make it an event with the response as the
argument instead
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Hi,
In some cases (e.g. large OFS.File/Image responses), Zope 2 will use
response.write() to stream the response.
We have events that fire before and after a regular response is
returned, but none
Hi,
I posted about this earlier, but the message seems to have gotten lost
in the ether.
I am trying and struggling to use ComputedErrorViewMessage. So far, I've
discovered two problems, one which affects IValue adapters in general.
1. The last discriminator of a ComputedErrorViewMessage (and
Hi,
I'm struggling to get custom ComputedErrorViewMessage adapters to work
in z3c.form. I'm still debugging, but I came across this:
In error.py:
ErrorViewMessage = value.StaticValueCreator(
discriminators = ('error', 'request', 'widget', 'field', 'form',
'content')
)
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Glick wrote:
Log message for revision 109667:
add a failing test for a regression in parsing ISO format datetimes from
DateTime 2.10, as discussed at http://dev.plone.org/plone/ticket/10140
...note that this will
Wichert Akkerman wrote:
On 3/1/10 13:41 , Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Gedminas wrote:
On Sun, Feb 28, 2010 at 05:05:51PM +0100, Wichert Akkerman wrote:
On 2010-2-26 18:25, Tres Seaver wrote:
Wichert Akkerman wrote:
I see this as naming
Hi,
The z3c.form doctests make it look like raising zope.interface.Invalid()
would be an acceptable thing for a validator to do. It also makes it
look like the argument passed to the Invalid() constructor is a string
that would be displayed as an error message.
However, when I do this (in a
Stephan Richter wrote:
On Friday 26 February 2010, Martin Aspeli wrote:
The z3c.form doctests make it look like raising zope.interface.Invalid()
would be an acceptable thing for a validator to do. It also makes it
look like the argument passed to the Invalid() constructor is a string
Wichert Akkerman wrote:
On 2/23/10 11:09 , Hanno Schlichting wrote:
On Tue, Feb 23, 2010 at 10:56 AM, Wichert Akkermanwich...@wiggy.net
wrote:
In Zope 2.10 exception views were acquisition-wrapped in the publisher
context.
In Zope 2.10, exception views didn't exist in Zope2. They were
Hi,
A lot of the forms I write perform a redirect at the end of the action
handler for a successfully submitted form.
z3c.form's __call__() indiscriminately calls update() and then render().
This means that even if something in update() (the action handler in
this case) causes a redirect, the
Charlie Clark wrote:
Am 06.02.2010, 15:21 Uhr, schrieb Matthew Wilkes
matt...@matthewwilkes.co.uk:
It seems like a lot of work for no gain. I can think of a couple of
examples where DTML templates are monkey-patched in Plone and none of
those are anything particularly vital. DTML works for
Christian Theune wrote:
As a matter of constructive criticism, it would be useful to have
something like this on the z3c.caching PyPI page. Right now, there is no
That's a typo, right?
D'oh; z3c.coverage, I meant.
way that I can see to understand how the package is meant to be used
from
Jan-Wijbrand Kolman wrote:
Martijn Faassenfaas...@startifact.com wrote:
Hi there,
This is to announce my withdrawal from the Zope Toolkit steering
group.
I'm not sure if you're reading this, but I wanted to thank you anyway
for the tremendous amount of energy you've put into the steering
Hi,
A couple of questions about zope.testing's --coverage option:
1. When specifying the coverage output directory, I have to specify an
absolute path:
./bin/test -s plone.caching --coverage=$(pwd)/coverage
works
./bin/test -s plone.caching --coverage=coverage
does not. Is this
Stephan Richter wrote:
On Sunday 17 January 2010, Martin Aspeli wrote:
I'm using zope.testing-3.7.7, which is what comes with Zope 2.12.
Here is what I have in effectively any package:
[coverage-test]
recipe = zc.recipe.testrunner
eggs = pkg [test]
defaults = ['--coverage
Michael Howitz wrote:
Am 13.01.2010 um 06:08 schrieb Martin Aspeli:
Michael Howitz wrote: Hi,
it seems to me that z3c.form.group.GroupForm does not send
enough ModificationEvents: only one event for the context of the
GroupForm but not for each modified object in the groups.
-1
Michael Howitz wrote:
Hi,
it seems to me that z3c.form.group.GroupForm does not send enough
ModificationEvents: only one event for the context of the GroupForm
but not for each modified object in the groups.
-1 to this being default behaviour.
IObjectModifiedEvent is fired from EditForms,
Log message for revision 108041:
Let OFS File/Image fire lifecycle events
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U Zope/branches/2.12/src/OFS/Image.py
U Zope/branches/2.12/src/OFS/tests/testFileAndImage.py
-=-
Modified: Zope/branches/2.12/doc/CHANGES.rst
Log message for revision 108042:
Merge c108040 from 2.12 branch (OFS File/Image lifecycle events)
Changed:
U Zope/trunk/src/OFS/Image.py
U Zope/trunk/src/OFS/tests/testFileAndImage.py
-=-
Modified: Zope/trunk/src/OFS/Image.py
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I would like to inform you that I intent to retreat from the Zope 2
release manager position soon. I have been serving the Zope community in
this position for almost seven years and now it is time to move on and
Wichert Akkerman wrote:
On 2010-1-10 04:36, Martin Aspeli wrote:
so in your test, `DateTime(md.CreationDate())` will always be the
current time, but with an implicitly added 'GMT+0' while `DateTime()`
will be the current time in your local time zone. so if i'm not
mistaken, on plone 4.0
Laurence Rowe wrote:
2010/1/10zopyxfil...@gmail.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Aspeli wrote:
Wichert Akkerman wrote:
On 2010-1-10 04:36, Martin Aspeli wrote:
so in your test, `DateTime(md.CreationDate())` will always be
the current time, but with an implicitly
Hi,
We have a failing test in plone.app.dexterity 1.0a7. This is simply
trying to compare two dates:
from DateTime import DateTime
DateTime() DateTime(md.CreationDate())
True
At least here in Australia, the second test fails. Right now, the
following expressions are:
Tres Seaver wrote:
You can lock the status and body of the response, which causes
subsequent attempts to set them to fail silently.
Oh, that's great! I even remember reading that code and it never struck
me. Thanks a lot!
Martin
--
Author of `Professional Plone Development`, a book for
Jan Ulrich Hasecke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05.01.10 08:36, Martin Aspeli wrote:
+1. It puts the final nail in the Zope 3 coffin and allows a reborn
vampire to emerge from slumber.
Ok, we all hate the damage that Zope 3 did and I have no problem to call
one
Andreas Jung wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Baiju M wrote:
Hi All, I am proposing to call Zope 3 - the web frame work as
BlueBream. The main use for name is documentation. But the
package named bluebream will not provide any part of framework
code by itself. All the
Martijn Faassen wrote:
Hey Tres,
Tres Seaver wrote:
You're kidding, right?
[snip]
My self-interest? Not really: you are appealing to my altruism, in the
fact that I care about the *broader* Zope community (broader than Zope2,
Grok, Plone, or whatever. Neither of my chosen platforms
Jens Vagelpohl wrote:
How is that any different from people who won't use the ZTK because they
don't want to deal with any zope.app* baggage?
We have a proposal for dealing with that now: To maintain two KGS', one
for ZTK and one for ZopeApp.
We can and should run tests for both, and ensure
Jim Fulton wrote:
- When we refactor zope.app.foo to be zope.foo (or something else),
rather than changing
zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible.
One problem with this is that if you have interfaces for which there are
components registered, this can
Baiju M wrote:
On Mon, Jan 4, 2010 at 11:53 PM, Baiju Mmba...@zeomega.com wrote:
Hi All,
I am proposing to call Zope 3 - the web frame work
as BlueBream.
I am unable to make a conclusion out of this discussion as many
real users of Zope 3 - the web frame work is not given +1
But
Martin Aspeli wrote:
Baiju M wrote:
On Mon, Jan 4, 2010 at 11:53 PM, Baiju Mmba...@zeomega.com wrote:
Hi All,
I am proposing to call Zope 3 - the web frame work
as BlueBream.
I am unable to make a conclusion out of this discussion as many
real users of Zope 3 - the web frame
Laurence Rowe wrote:
2009/12/31 Martin Aspelioptilude+li...@gmail.com:
Hi,
A few of us are playing with some caching tools, trying to get to a more
sane and less monkey patch-laden approach than CacheFu
(Products.CacheSetup), for use with Zope 2.12.
It is relatively easy to set response
Martijn Faassen wrote:
Martin Aspeli wrote:
[snip]
We've had good success with
http://pypi.python.org/pypi/collective.recipe.sphinxbuilder
I'm having trouble with this. I'm trying to set up a narrative_docs
directory in a package but:
* the documentation on collective.recipe.sphinxbuilder
Martijn Faassen wrote:
Hi there,
This is a summary of the previous discussions for those who weren't
paying attention last week and don't want to read a huge thread coming
back from vacations. I'm talking about you in particular, other steering
group members. I'll spread it out over multiple
Martijn Faassen wrote:
What lowered the quality of this discussion? I think it is because
various people became quite upset and annoyed. That's because I reverted
Hanno's changes to the ZTK trunk. I shouldn't have done that just like
that, but I needed the subsequent discussion to come up
Hi,
So here's my proposed solution for the ZTK shrinking issue:
The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since
Zope 2 forked the ZTK in response and continued to make changes to their
fork, I've tried to keep it in sync with the Zope 2 fork.
I've created a new
Martijn Faassen wrote:
Hi there,
I am interested in creating sphinx-driven documentation for Zope Toolkit
packages. I'd like to maintain the documentation for a package (say,
zope.component) in that package, in a 'doc' directory.
I'm wondering what experiences people have with maintaining
Hi Paul,
Nicely done! I think it'd be useful to wrap this into a small library
and release it for people who want to use it, with a bit of narrative
documentation on its own for the PyPI front page.
One thing you may want to think about, is to have an option for delaying
the registration
Hanno Schlichting wrote:
On Wed, Dec 30, 2009 at 6:38 PM, Martijn Faassenfaas...@startifact.com
wrote:
zope.testing.doctestunit emits a deprecation warning. It also defines a
function pprint. How does one use pprint without getting a deprecation
warning? It seems impossible now, and an
Hi,
A few of us are playing with some caching tools, trying to get to a more
sane and less monkey patch-laden approach than CacheFu
(Products.CacheSetup), for use with Zope 2.12.
It is relatively easy to set response headers, e.g. in an
IPubBeforeCommit event handler.
However, we also need
Baiju M wrote:
The packages that we might want to break out (like we did with
Acquistion, ExtensionClass, DateTime) should retain their name, so
nobody has to change any code to work with them.
I think we could have added those packages in a namespace.
Why? A million things depend on these
Hanno Schlichting wrote:
From my point of view most of the original UI building blocks of Zope
3 have failed to catch on. More modern systems like repoze.bfg prefer
a much simpler model using ZPT macros or trying to mirror the CMF
skins model. In the Plone world we adopted the CA to build and
Hanno Schlichting wrote:
Hi Tres,
I've seen you started some work on Zope2 and its WSGI publisher. This
is awesome :)
How does this relate to repoze.zope2?
I'd love to have Zope2 actually support WSGI out-of-the-box. It should
probably be based on either a simplified repoze.zope2 codebase
Tres Seaver wrote:
After a question on the repoze list about running Zope 2.12.x behind a
WSGI server, I went to try that out. I came up with a minimal .wsgi
file to run behind mod_wsgi::
$ cat src/Zope2/utilities/skel/bin/zope2.wsgi.in
from Zope2.Startup.run import configure
from
Helge Tesdal wrote:
On 18. des.. 2009, at 13:24, Andreas Jung wrote:
Publisher events are part of Zope 2.12 (not sure if they were
backported to older versions).
Perhaps of interest:
http://pypi.python.org/pypi/haufe.requestmonitoring
http://pypi.python.org/pypi/haufe.ztop
Thanks, I
Tres Seaver wrote:
In either case, I think TypeError (or maybe LookupError) is the *right*
choice: we don't want to hide zope.component's API functions and then
turn around and require folks to import zope.component just to catch its
local exception types.
Yeah, that's a compelling reason.
Tres Seaver wrote:
+1 to TypeError: nobody really cares about the type of the error: code
that wants to be robust about a failure uses the 'query' methods. As
long as the message is informative enough (which ComponentLookupError
isn't, really) we should be fine. If we made CLE derive from
On 15/12/09 5:45, Tres Seaver wrote:
I've committed this in r106436 and merged to trunk in r106437.
OK, sounds fine to me. Can you merge to the 2.11 branch as well? I
think Andreas will be releasing 2.9.x through 2.12.x fairly soon.
Sure, I'd forgotten about that one.
If anyone objects,
Log message for revision 106436:
Fix regression in treatment of trusted code in view page templates.
Changed:
U Zope/branches/2.12/doc/CHANGES.rst
U
Zope/branches/2.12/src/Products/Five/browser/tests/test_pagetemplatefile.py
U
Log message for revision 106437:
Merge r106436 from 2.12 branch, fixing a regression in the ZPT engine for
trusted code
Changed:
U Zope/trunk/src/Products/Five/browser/tests/test_pagetemplatefile.py
U Zope/trunk/src/Products/PageTemplates/Expressions.py
-=-
Modified:
On 13/12/09 10:52, Tres Seaver wrote:
Doesn't smell like a regression to me: the code there hasn't changed in
a good long while. Can you write a test case for it, so that we can
test against earlier versions?
I'm almost completely sure that this was an issue ages ago, and slightly
less
On 13/12/09 10:52, Tres Seaver wrote:
Doesn't smell like a regression to me: the code there hasn't changed in
a good long while. Can you write a test case for it, so that we can
test against earlier versions?
Aha! http://codespeak.net/pipermail/z3-five/2007q2/002185.html
This is the same
On 13/12/09 16:49, Martin Aspeli wrote:
On 13/12/09 10:52, Tres Seaver wrote:
Doesn't smell like a regression to me: the code there hasn't changed in
a good long while. Can you write a test case for it, so that we can
test against earlier versions?
Aha! http://codespeak.net/pipermail/z3
Hi,
Ages ago, I started a thread (I think on this list) about the use of TAL
expression in Zope 3-style page templates (i.e. ViewPageTemplateFile's
used on views) incorrectly performing security checks when using TAL
expressions.
I think Tres fixed it at the time (I can't find the original
Lennart Regebro wrote:
On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote:
I think I could get fully behind the following proposal that others have
made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Change that to Martins IFoo.adapter(...) and
Martijn Faassen wrote:
Martin Aspeli wrote:
[snip]
Thinking out loud further, I think I may actually prefer IFoo.instance()
instead of .utility(), but maybe that debate is already passed.
.utility() is OK too.
Haven't you been one of the people who has maintained that changing
Martijn Faassen wrote:
Hi there,
I think we've had enough discussion to make a decision.
I'm a little worried that neither Stephan Richter, nor Jim Fulton have
had much weight in on this. They seem like important stakeholders. :)
Hopefully
everybody is at least reasonably happy with
Shane Hathaway wrote:
Martin Aspeli wrote:
Can we all get back to our lives now? :-)
FWIW, I try to participate in discussions like these by reading and
writing only short emails. I find that I don't miss much that way.
Life is more enjoyable without essay-mails.
You don't know me very
Chris McDonough wrote:
Thomas Lotze wrote:
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*
Gary Poster wrote:
I think I could get fully behind the following proposal that others
have made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
I could get behind this too.
We'd need the current IFoo(context, default) for single adaptation to
continue to work,
Gary Poster wrote:
On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote:
Gary Poster wrote:
I think I could get fully behind the following proposal that
others have made (Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
I could get behind this too.
We'd need
Gary Poster wrote:
I think I could get fully behind the following proposal that others have made
(Shane I think was one of several?).
IFoo.adapt(...)
IFoo.utility(...)
Thinking about it a bit, it strikes me that IFoo.adapt(context) may not
be right. This reads IFoo adapt context, which
Martijn Faassen wrote:
I don't like the word singleton very much either. Singleton in the
Design Patterns book has a very particular implementation that is
criticized by a lot of developers and in particular that particular
pattern is very uncommon in the Python world (people just use
Martijn Faassen wrote:
Joachim König wrote:
[snip]
To me the fact that an object is a singleton or a factory is
orthogonal to the registry stuff.
Why can't utilities be factories too that simply return themselves when
being called? Then being
a singleton or not would be in the
Martijn Faassen wrote:
First a statement about the goal of this discussion. The goal of this
discussion is to convince people to unify the lookup API. I wouldn't
want to make lookup API improvements depend on improvements to
zope.component inspired by the discussion below. I'm in favor of
Chris McDonough wrote:
I am more or less somewhere between -0 and +0
That is a high degree of precision. Maybe we need to start thinking of
our voting system as a Decimal instead of an int?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with
Joachim König wrote:
Martin Aspeli wrote:
Clearly, it could. But that's not the way we went. Changing it now would
be really damaging, and I'm not sure what would be gained.
I can imagine use cases where getting a new instance each time would be
useful.
But that is under the full controll
Martijn Faassen wrote:
Martin Aspeli wrote:
Martijn Faassen wrote:
Multi-adaptation:
IFoo(one, two)
Please note that this will break an incredible amount of code in the
wild. A good number of my packages do something like this:
foo = IFoo(context, None)
if foo is None
Hanno Schlichting wrote:
On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli optilude+li...@gmail.com
wrote:
Martijn Faassen wrote:
This implies we don't want to release zope.component 4.0 for a long time
yet.
I think the answer should be never. :)
I think never is a rather long time. I'd
Hanno Schlichting wrote:
On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wich...@wiggy.net wrote:
We could also say that we will clean up the API when we move to Python
3. That is a natural breaking point anyway, so it will not any extra
pain for users of the ZCA.
Except that is precisely
Martijn Faassen wrote:
The most elegant backwards compatible solution would be multi adaptation
using a tuple. I think 'name' can probably also be added to the adapter
hook without breaking stuff. People adapting tuples will need an
explicit way to do so. It's still backwards incompatible,
Martijn Faassen wrote:
Stephan Richter wrote:
On Friday 27 November 2009, Martijn Faassen wrote:
Are people okay with the proposed semantics?
Would people be okay with such an upgrade path? Any better ideas?
Looks good.
Note: We had Thanks Giving over the weekend, so please allow more US
Tim Hoffman wrote:
Just re-inforcing this I almost never do IFoo. adaption as I am almost
always using
multiadapters and utilities so I completely forget about the IFoo
adaption capability.
Which means I always just write getAdapter as well as it seems more
consistent to
from an api
Martijn Faassen wrote:
Multi-adaptation:
IFoo(one, two)
Please note that this will break an incredible amount of code in the
wild. A good number of my packages do something like this:
foo = IFoo(context, None)
if foo is None:
...
There is a lot of documentation out there
Chris McDonough wrote:
Except at this point we've lost all the other ZCA stuff. You can't
override with a local utility, for example.
I see. I didn't understand that this was a use case, because I don't use any
persistent registries. If you say this is a use case, I believe it.
Note
Martin Aspeli wrote:
I *do* actually like the named IAnonymousUtility thing as a
convenience, because it retains some consistency. Maybe it's slower,
which would be a negative. But it also allows all the other ZCA stuff
(overriding, introspection, global/local variants, etc) and API: we're
Chris McDonough wrote:
I think we have to divorce the requirement from the ZCA.
The requirement:
- an attribute of an instance of the class
zope.component.registry.Components which is dictionarylike
(accepts any key type, any value type).
If I can get that, I'd be happy,
Chris McDonough wrote:
I fear it was for naught, sorry.
Adding an attribute is unsightly and turning this into a component problem
doesn't have enough immediate gain. The BFG registry will just continue to
be
a dict subclass.
If Zope folks later want to use libraries that come from
Hi Chris,
In repoze.bfg, we've actually decided to use a subclass of the component
registry which also inherits from dict. This makes it possible to
spell
common unnamed utility registrations and lookups as:
utility = SomeUtilityImplementation()
registry['someutility'] = utility
I
Matthew Wilkes wrote:
Right, but I think mixing the two is just going to be confusing. Your
alternative spelling may well be useful, but only if it works within
the confines of the ZCA itself, otherwise you're just hijacking the
component root for your own (nefarious) purposes.
The
Chris McDonough wrote:
A lookup keyed entirely on strings and not interfaces is perfectly
possible using the ZCA, just register your utility to provide
z.i.Interface and name it. Your semantics are the same as the simple
dictionary use-case, but it doesn't force people to choose one means
Hi Chris,
Chris McDonough wrote:
Martin Aspeli wrote:
We need to make sure that we're not inventing a different way to achieve
something which is already possible. This will lead to confusion,
because people will have to know which way is applicable in a given
situation
101 - 200 of 482 matches
Mail list logo
