Hi Shane, Toby ..
Set Tardis for
http://mail.zope.org/pipermail/zope-dev/2003-February/018837.html
All I can think is that that object 'basic' lacks context for
some reason (i.e. lacks an acquisition wrapper?). I can't think
why it lacks context .. we use that idiom all over the app, and
don't
In case it's relevant, the Folder at the bottom of the aq_chain
for license is a ZUnit temporary folder:
(116)doRemindersForLicense()
(Pdb) license.aq_chain
[License instance at 9cca368, Specialist instance at 9aef630,
Specialist instance at 98313c8, Folder instance at 9cb9468, ***
Craeg K Strong wrote:
I hate it when I surf to a less-highly-used portion of a website and
have to wait 30 seconds for the page to render.
Sure, we all do.
One possibility is to add the ability to *declare* dependencies.
[snip]
Such an object could have an explicit listing of the objects
John Ziniti wrote:
Any ZODB developers read this article at /. and the accompanying
one at developerWorks? Would anyone care to comment about
the relevance/comparisons of prevalence to the concepts of
persistence used in ZODB and/or ZEO?
Jean Jordaan wrote:
Hi Shane, Toby ..
Set Tardis for
http://mail.zope.org/pipermail/zope-dev/2003-February/018837.html
All I can think is that that object 'basic' lacks context for
some reason (i.e. lacks an acquisition wrapper?). I can't think
why it lacks context .. we use that idiom all over
Notice that the closing square bracket is not
present, and something printed three asterisks.
Myeah, 'grep -r \*\*\* *' in the Zope 2.5.1 source and
instance Products directories doesn't turn up any AttributeError
line ..
I don't know what code would do that... perhaps Python 1.5.2?
It's
Anyway, after talking this over with my colleague, I realize that
the problem of *deriving* dependencies is fundamentally undecidable.
We might be able to figure it out in the case of simple acquisition,
like
span tal:replace=here/aObject/aMethod/
But it is hopeless for pure python:
span
Andy McKay wrote:
Anyway, after talking this over with my colleague, I realize that
the problem of *deriving* dependencies is fundamentally undecidable.
We might be able to figure it out in the case of simple acquisition,
like
span tal:replace=here/aObject/aMethod/
But it is hopeless for pure
On Tue, Feb 25, 2003 at 06:33:16PM +, Florent Guillaume wrote:
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:
So I think you need dynamically calculated local roles. This can be
achieved by a user folder that returns a user object that overrides
.getRolesInContext(object) to take
On Tue, Mar 04, 2003 at 02:32:31PM -0500, Shane Hathaway wrote:
Ah, but you might have something there. What if there were a cache
manager that simply dropped its contents whenever anything changes in
ZODB? You could associate nearly all scripts and templates with that
cache manager
Attention: cross post
PEP308 is concerned with the introduction of a ternary conditional
operator (something like an if cond: val_true else: val_false)
into Zope.
In my view, such an operator would make TALES expressions
easier because we could get rid of the and/or hack to
represent
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
--Guido van Rossum (home page:
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not even hard. Here's a
On Tue, Mar 04, 2003 at 03:21:57PM -0600, Evan Simpson wrote:
Is this worth a robust implementation, ZPT folks?
maybe, but i'd rather first wait and see how the PEP goes.
it would suck to have to constantly deal with two totally
different flavors of ternary.
--
Paul Winkler
Attention: cross post
PEP308 is concerned with the introduction of a ternary conditional
operator (something like an if cond: val_true else: val_false)
into Zope.
In my view, such an operator would make TALES expressions
easier because we could get rid of the and/or hack to
represent
15 matches
Mail list logo
