I have finally realized that the way tests are run in 2.7 is different
from earlier version of Zope, and I'm trying to get them to run.
It's Zope 2.7.2 on Debian. Python 2.3.4 and 2.3.2, so I guess 2.3.3
would give the same error. Could it be a side effect of the compiling or
something?
Here
Hi,
Andreas Ames wrote:
next trial. I hope I've got it straight now.
Not quite so (although this may only be nitpicking ;-).
fs_env = environ
should have read
fs_env = environ.copy()
obviously. See attachment.
cheers,
andreas
--- lib.orig/python/ZPublisher/HTTPRequest.py 2004-08-18
Lennart Regebro wrote:
I have finally realized that the way tests are run in 2.7 is different
from earlier version of Zope, and I'm trying to get them to run.
It's Zope 2.7.2 on Debian. Python 2.3.4 and 2.3.2, so I guess 2.3.3
would give the same error. Could it be a side effect of the
OK, I got test.py running. But if I run
bin/python test.py Products
it will happily try to run the tests in all products. But if I type
bin/python test.py Products/Productname
It will find no tests at all.
bin/python test.py Products/Productname/tests
is no better.
BUT!
If I type
Ames Andreas (MPA/DF) wrote at 2004-8-18 17:22 +0200:
I had a thinko in my previous patch
(http://mail.zope.org/pipermail/zope-dev/2004-August/023630.html)
which is corrected in the attached version of the patch. Sorry for
any inconvenience, I might have caused.
I do not think that your patch
Why dont you try:
'myobject' in Object3.objectIds('meta_type_name')
HTH, Suresh
Kai Hoppert [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi all,
i actually have a Problem with restrictedTraverse and hasattr.
Object1
Object2
Object3
I want to test if there exists a Object in
Lennart Regebro wrote at 2004-8-20 17:39 +0200:
OK, I got test.py running. But if I run
bin/python test.py Products
This should probably be:
... test.py --libdir Products
Note also, that test.py treats symbolic links in an unexpected
way (it resolves the path and may then no longer
Lennart Regebro wrote at 2004-8-20 12:12 +0200:
...
line 42, in ?
from cDocumentTemplate import InstanceDict, TemplateDict, \
ImportError:
/home/regebro/Zopes/Zope-2.7.2-0/lib/python/DocumentTemplate/cDocumentTemplate.so:
undefined symbol: PyUnicodeUCS4_DecodeLatin1
This means:
Hi Dieter, *,
Dieter Maurer wrote:
The FieldStorage must be rebuilt, because it can contain
file objects. These file objects must be reset as they may
have been (partially) read in the previous request.
This prevent reusing the previous FieldStorage.
As you may have seen in my first
Hi Thaddeus,
Thaddeus H. Black wrote:
Please let me know if it doesn't show up
there...
I see your message there
[http://bugs.debian.org/251038] presently.
Cool, the bug's going to look a bit bloated due to the way the Zope
Collector sends mails, but at least everyone will know where things are
IIRC this is caused by having a Python compiled without UCS4 support.
Some pre-built pythons that come with certain Linux distros (RedHat is
one I think) are built with different unicode support then the default.
I would suggest building your own python from source and trying it with
that
Lennart Regebro wrote:
OK, I got test.py running. But if I run
bin/python test.py Products
it will happily try to run the tests in all products. But if I type
bin/python test.py Products/Productname
It will find no tests at all.
bin/python test.py Products/Productname/tests
is no better.
Ames Andreas (MPA/DF) wrote at 2004-8-19 18:04 +0200:
...
Cause of your hint I looked again and realised that I was wrong.
HTTPRquest's 'BODYFILE' field fails to reset the file before accessing
it (as in OFS/Image.py the File class does). That could be easily
fixed. What's worse is that
13 matches
Mail list logo
