Baiju M wrote:
I have pasted the relevant code here:
def resolve(self, dottedname):
Resolve a dotted name to an object.
I wonder why zope.dottedname isn't being used here either?
Chris
--
Simplistix - Content Management, Zope Python Consulting
-
Martijn Faassen wrote:
I think we can only make the correct determination if we get an idea of
the performance implications. If it turns out the C code brings
significant speedups in real-world applications, we should create a
zope.hookable with a Python + C implementation.
Even if it
Hey Tres,
Tres Seaver wrote:
2. Move the persistent registry stuff out into another package,
including whatever support is needed to allow for people to migrate
existing persistent references. Effectively, this moves one extra
out to a package, *including* its testing dependencies.
Am Mittwoch 04 März 2009 18:03:17 schrieb Lennart Regebro:
On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com
wrote:
Note that the Zope Steering group is not about
packages that are not in the framework, so if lovely.remotetask isn't
there, it can say little.
Which is
Am Mittwoch 04 März 2009 17:48:37 schrieb Martijn Faassen:
Hi there,
Lennart Regebro wrote:
[snip]
And it is in any case in no way even remotely connected to the group
Martijn proposed and has been discussed in this thread.
- Attracting newbies to web development is not a task of the
Am Mittwoch 04 März 2009 19:00:12 schrieb Baiju M:
On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com
wrote:
[snip]
The steering group isn't intended to take a responsibility for the
entirety of the Zope software. Zope 2, Grok and the Zope 3 app server
(which would
Summary of messages to the zope-tests list.
Period Wed Mar 4 12:00:00 2009 UTC to Thu Mar 5 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Wed Mar 4 20:25:30 EST 2009
URL:
Pour rappel il existait nss3-{1,2,3] pour tester les corrections de
bugs en 3.4 et 3.5. Comme nous développons plus la 3.4 (et que j'ai
besoin de machines), j'ai récupéré les deux premières.
--
Sebastien Douche sdou...@gmail.com
___
Zope-Dev maillist
On Thu, Mar 5, 2009 at 13:53, Sebastien Douche sdou...@gmail.com wrote:
Sorry, wrong ml :(
--
Sebastien Douche sdou...@gmail.com
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
On Mar 1, 2009, at 1:00 PM, Jim Fulton wrote:
There's been some discussion recently about separating the interfaces
in zope.publisher from the implementations to facilitate other
implementations.
I think it would be great to standardize request and response APIs.
I'd love to see this
On Mar 5, 2009, at 6:38 AM, Hermann Himmelbauer wrote:
And I am personally interested if the Zope 3 app server is something
that's
dying in favour for other projects (Plone/Grok) or is actively used.
Not clear on what you mean by the app server.
If you mean zope.publisher, no, I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Baiju M wrote:
On Thu, Mar 5, 2009 at 11:26 AM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Baiju M wrote:
Hi,
zope.deprecation is used in zope.configuration *only* to turn
off deprecation warning
On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Baiju M wrote:
On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote:
2009/3/2 Tres Seaver tsea...@palladion.com:
-include
On Thu, Mar 5, 2009 at 14:15, Gary Poster gary.pos...@gmail.com wrote:
On Mar 5, 2009, at 6:38 AM, Hermann Himmelbauer wrote:
And I am personally interested if the Zope 3 app server is something
that's
dying in favour for other projects (Plone/Grok) or is actively used.
Not clear on what
Hi there,
Thanks for the clarifications concerning registries. Does the multiple
registry situation mean any changes to the implementation of the ZCML
directives at all or will they just work as soon the underlying registry
situation is adjusted?
Another point is that we need to make sure we
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2009, at 08:24 , Christian Theune wrote:
As Dan pointed out, some of those documents are a bit more general
than
Zope Framework, but, then again, they're also more general than Zope
3.
So even for that
Martijn Faassen wrote at 2009-3-3 00:36 +0100:
...
* how will the community make hard decisions where lots of people
disagree?
You try to achieve consensus. When you do not, you get the chance
that people turn away.
...
* who reminds us of necessary tasks and directions we're going into?
Martin Aspeli wrote at 2009-3-3 17:21 +0900:
...
How many times have we gotten bogged down in semantics or
naming discussions and killed off the momentum behind something?
A clear notion of semantics and well chosen names are important
for any project.
I would not want momentum resulting in
Shane Hathaway wrote:
Roger Ineichen wrote:
Shane,
Can you review and merge this changes into your
zope.pipeline branch?
I'm going to put zope.pipeline on hold until the PyCon sprints. Jim and
I need to discuss it in person; hopefully then I can understand his
opposition and the group
Hi there,
Baiju, much thanks for looking into this. I hope we can indeed get rid
of this code.
I myself have the suspicion that the deprecation system is perhaps a
'false optimum' in most cases. Putting in deprecations tends to be quite
a bit of work (as it's a code change), the warnings
Hi there,
Perhaps it's time to deprecate the deprecation system.
Why?
* I've had good experience in the Grok project with just noting changes
that might break code in the upgrade notes for Grok and telling people
how to fix it. Using documentation more background can be provided and
it can
Hi there,
I've moved over the documentation zope3docs over into the
zopeframework/trunk package.
I left the documentation in zope3docs too for now so as not to break the
automated web build system.
Jens, could you pick up zopeframework/trunk now for
http://docs.zope.org/zopeframework? And
On Thu, 2009-03-05 at 16:53 +0100, Martijn Faassen wrote:
Hi there,
I'm happy to announce that the Zope Framework Steering Group is now
bigger than Just Me.
Stephan Richter and Christian Theune have now joined the Steering Group,
bringing it up to 3 members. I think both don't need much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2009, at 16:32 , Martijn Faassen wrote:
Thanks for pointing that out. If we moved it could you put a
redirect in
place that just pointed .../zope3docs to .../zopeframework?
I think to get started on the move we could copy the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2009, at 18:24 , Jens Vagelpohl wrote:
Let's do this:
- svn copy zope3docs to zopeframework
- once you think zopeframework is ready for public viewing, let me
know and I'll set up a self-updating sandbox and a redirect
- after
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2009, at 17:55 , Martijn Faassen wrote:
Jens, could you pick up zopeframework/trunk now for
http://docs.zope.org/zopeframework? And put a redirect in place for
http://docs.zope.org/zope3docs to the new location?
We can then retire
I'd like to continue moving code to saner places, so here's two more
little ideas on next refactorings:
- Move password managers from zope.app.authentication to a new
package, like zope.password. They are really useful in any
authentication system, even not related to zope3 the app server or
zodb
Hey,
Jens Vagelpohl wrote:
On Mar 5, 2009, at 17:55 , Martijn Faassen wrote:
Jens, could you pick up zopeframework/trunk now for
http://docs.zope.org/zopeframework? And put a redirect in place for
http://docs.zope.org/zope3docs to the new location?
We can then retire zope3docs.
All
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2009, at 17:55 , Martijn Faassen wrote:
Jens, could you pick up zopeframework/trunk now for
http://docs.zope.org/zopeframework? And put a redirect in place for
http://docs.zope.org/zope3docs to the new
2009/3/5 Dan Korostelev nad...@gmail.com:
The zope.schema is also needed for the password
manager vocabulary, but I'm not sure if the vocabulary should go to
the new package, because it adds a dependency on zope.schema. What do
people think?
Ah, I forgot that the password managers are
Martijn Faassen wrote at 2009-3-3 22:11 +0100:
...
backwards compatibility at all costs,
I agree that have erred on the side of too much backwards compatibility.
That increased the overhead of changes tremendously and blocked innovation.
Large applications are built upon the framework.
If
Hey Dan,
Thanks for taking the initiative to propose more refactorings!
Dan Korostelev wrote:
I'd like to continue moving code to saner places, so here's two more
little ideas on next refactorings:
- Move password managers from zope.app.authentication to a new
package, like zope.password.
Dan Korostelev wrote:
2009/3/5 Dan Korostelev nad...@gmail.com:
The zope.schema is also needed for the password
manager vocabulary, but I'm not sure if the vocabulary should go to
the new package, because it adds a dependency on zope.schema. What do
people think?
Ah, I forgot that the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 5, 2009, at 19:08 , Martijn Faassen wrote:
Hey,
Jens Vagelpohl wrote:
On Mar 5, 2009, at 17:55 , Martijn Faassen wrote:
Jens, could you pick up zopeframework/trunk now for
http://docs.zope.org/zopeframework? And put a redirect in place
Hi there,
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of virtual packages that
each can have a separate list of dependencies. Such a virtual package
that
Martijn Faassen wrote:
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of virtual packages that
each can have a separate list of dependencies. Such a virtual
2009/3/5 Martijn Faassen faas...@startifact.com:
Hi there,
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of virtual packages that
each can have a separate
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen faas...@startifact.com wrote:
* we shouldn't create any new extra dependencies from now on.
+1
* we should investigate ways to remove the need for 'extra' dependencies.
+1
I therefore think zope.app.testing is one package we should be looking
Martijn Faassen wrote at 2009-3-5 17:35 +0100:
Perhaps it's time to deprecate the deprecation system.
...
Thoughts?
+1
--
Dieter
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen faas...@startifact.com wrote:
[snip proposal to stop using extras]
Opinions?
+1
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
On Thu, Mar 5, 2009 at 17:35, Martijn Faassen faas...@startifact.com wrote:
* I've had good experience in the Grok project with just noting changes
that might break code in the upgrade notes for Grok and telling people
how to fix it. Using documentation more background can be provided and
it
Previously Martijn Faassen wrote:
I therefore think zope.app.testing is one package we should be looking
to get rid of eventually by splitting it up among a lot of 'testing'
modules in individual packages. This way we won't have zope.app.testing
sitting at an edge against our whole
On Thu, Mar 5, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote:
I would like to see a move away from zope testing frameworks to a more
standard testing infrastructure: setup.py test, possibly combined with
using nose.
Wichert.
Be aware of nose issue #102:
Previously Sidnei da Silva wrote:
On Thu, Mar 5, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote:
I would like to see a move away from zope testing frameworks to a more
standard testing infrastructure: setup.py test, possibly combined with
using nose.
Wichert.
Be aware of
On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote:
Hi there,
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of virtual packages that
each can have a separate
Hi there,
Wichert Akkerman wrote:
[snip]
I would like to see a move away from zope testing frameworks to a more
standard testing infrastructure: setup.py test, possibly combined with
using nose.
This is another discussion that has little to do with testing
dependencies such as
Martijn Faassen wrote:
Perhaps it's time to deprecate the deprecation system.
From my personal view, I think the deprecation system works in certain
cases in its current form. It does not work as the only means of
documenting API changes for the evolution of software.
I tend to think of
Dan Korostelev wrote at 2009-3-5 22:14 +0300:
...
-0.75 for removing functionality extras. I still don't get how extras
are different from additional packages.
I agree with Dan -- and add -1.
The extras are equivalent to almost identical additional packages.
If this makes reasoning more
Gary Poster wrote:
On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote:
Hi there,
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of virtual packages that
each
Hi there!
While looking at the zope.app.principalannotation package, I
discovered that both zope.annotation and zope.app.principalannotation
register their IAnnotations adapters twice: fisrt, as a simple adapter
and second, as a multi adapter for some additional context object.
The
2009/3/5 Gary Poster gary.pos...@gmail.com:
On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote:
Hi there,
I know opinions are divergent about 'extra' dependencies in setup.py.
These ar dependencies that effectively make a single project with a
single dependency structure into a number of
On Mar 5, 2009, at 5:02 PM, Laurence Rowe wrote:
Gary Poster wrote:
I disagree with the blanket statement.
I do lean towards not having the extras for the test package only.
I'm fine with the policy If you want zope.testing for your tests,
then keep it as a dependency for the package.
But
Hi Martijn
Betreff: [Zope-dev] deprecating the deprecation system?
Hi there,
Perhaps it's time to deprecate the deprecation system.
Why?
* I've had good experience in the Grok project with just
noting changes that might break code in the upgrade notes for
Grok and telling people
Hi Dan
Dan Korostelev wrote:
Hi there!
While looking at the zope.app.principalannotation package, I
discovered that both zope.annotation and zope.app.principalannotation
register their IAnnotations adapters twice: fisrt, as a simple adapter
and second, as a multi adapter for some additional
Hi Martijn
Betreff: Re: [Zope-dev] zope.publisher
Roger Ineichen wrote:
Does grok need to register this new adapter somewhere?
If the adapter configuration is missing the default skin
apply pattern
will break.
As long as zope.publisher's configure.zcml does it, Grok will
load
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Maurer wrote:
Martijn Faassen wrote at 2009-3-3 22:11 +0100:
...
backwards compatibility at all costs,
I agree that have erred on the side of too much backwards compatibility.
That increased the overhead of changes tremendously and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Thanks for the clarifications concerning registries. Does the multiple
registry situation mean any changes to the implementation of the ZCML
directives at all or will they just work as soon the underlying registry
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
Hey Tres,
Tres Seaver wrote:
2. Move the persistent registry stuff out into another package,
including whatever support is needed to allow for people to migrate
existing persistent references. Effectively, this moves
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hi there,
Perhaps it's time to deprecate the deprecation system.
Why?
* I've had good experience in the Grok project with just noting changes
that might break code in the upgrade notes for Grok and telling people
Jim Fulton wrote:
- It's not well enough documented. While I think there's merit in doing
some things at the WSGI level, I remain pretty happy with the
publication interface for separatating generic publisher functions from
application policies. I which the use of this API was better
60 matches
Mail list logo
