Stefan H. Holek wrote:
This is an old ZODB, right?
Yup, from Zope 2.7.6
ZGlobals is used by ZClasses. There used to be a time when ZGlobals was
still a BTree when it should have been a BTrees.BTree. Then some
migration code was added.
It obviously never kicked in ;-)
I suppose the error
Dieter Maurer wrote:
Looks as if your Python were compiled without debugging symbols.
You will get much better tracebacks (easier to understand),
when you rebuild your Python with debugging symbols.
But of course, it's a production system :( - temporarily installing
python-debuginfo ...
On Sat, Apr 01, 2006 at 01:07:35PM +0200, Stefan H. Holek wrote:
I don't think makerequest is intended for wrapping anything but the
root application object. Putting the RequestContainer on arbitrary
objects doesn't feel right and certainly isn't how Zope does it, i.e.
you get a test
Stefan, do you have any insight into my first question?
I wrote:
1) there is a makerequest function in both Testing/makerequest.py
and Testing/ZopeTestCase/utils.py. They are subtly different.
Is there a deliberate reason for this? I notice that ... (snip)
the one in makerequest.py lacks an
Hi All,
I'm currently plagued by the following annoying:
ZODB Could not import class 'BTree' from module 'BTree'
What's the recommended way of tracking these down?
Is there anything we can do to make the logged message give more info
about where the object is?
I eventually
On 4. Apr 2006, at 16:53, Paul Winkler wrote:
Hmmm, but unit tests very often don't reflect reality -
deliberately!
Because reality is Too Much Stuff.
True enough.
Any other opinions on this? Do we really need to require an App at
the root any time we want to acquire REQUEST? That seems
The one in ZopeTestCase.utils is also meant to play with startZServer
(same module). I agree that the one in Testing.makerequest could
probably gain ACTUAL_URL, and maybe even the request._steps hack to
make URL1 and friends available...
However, I have not seen these URL vars used
Alan Milligan wrote at 2006-4-4 21:19 +1000:
Dieter Maurer wrote:
Looks as if your Python were compiled without debugging symbols.
You will get much better tracebacks (easier to understand),
when you rebuild your Python with debugging symbols.
But of course, it's a production system :( -
On Tue, Apr 04, 2006 at 08:09:05PM +0200, Stefan H. Holek wrote:
This looks fine to me because the world ends at parent. Your earlier
example wrapped an object that was in the middle of an acquisition
chain (IIRC),
no, I think you invented that :)
which I am not sure I like. You are
