supporting WebDAV?
Any suggestions welcome!
Phil
--
Philipp von Weitershausen
[ *pronounce: "fun Viters-houzen" ]
http://www.philikon.de/
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No c
Hi there,
how do I turn off this annoying traceback that is always printed out when an
error occurrs?
--
Philipp von Weitershausen
[ *pronounce: "fun Viters-houzen" ]
Web http://www.philikon.de/
___
Zope-Dev maillist - [EMAIL
Hi,
def addExternalMethod(self, id, title, module, function, REQUEST=None):
Add an external method to a folder
id=str(id)
title=str(title)
module=str(module)
function=str(function)
i=ExternalMethod(id,title,module,function)
#self._setObject(id,i)
I don't get
Clemens Robbenhaar wrote:
The actual work is the transformation of instances of class A.Foo to
class B.Foo; to be on the safe side one would have to copy over all
attributes manually. If You want to try a fast and dirty solution, You
could try to write the new class into the '__class__' attribute
Richard Jones wrote:
During the Melbourne Zope3 Sprint, someone ran up against a situation where
they'd have liked to have TALES perform a tuple unpacking like Python can.
I've just run into a similar situation :)
Say a method listFilesByUser returns a list of (user, [files]) it'd be nice to
Shane Hathaway wrote:
Here's the way I'd like to spell it:
div tal:repeat=user_files here/listFilesByUser
User: span tal:replace=user_files/int:0 /
File: span tal:replace=user_files/int:1 /
/div
+1
We've come up with a number of generally useful prefixes, BTW. Off the
top of my
Evan Simpson wrote:
Hmmm. I hadn't thought of that before, but I've certainly wanted to
tell the path traverser whether to use attribute, index, or key access
on several occasions (using 'items' as a dictionary key bites me
regularly).
I can imagine the pain. Explicit is better than implicit.
Jean Baltus wrote:
Hi all,
The problem I describe here does NOT appear with Zope 2.6.1, nor Zope
2.6.2b4, only with Zope 2.7.
I installed Zope 2.7 with CMF 1.4, Plone 1.1alpha2 and
TranslationService 0.4. When I create a Plone site (called dice here)
Ive got the following error:
...
*
Chris McDonough wrote:
Update of /cvs-repository/Zope/lib/python/TAL
In directory cvs.zope.org:/tmp/cvs-serv15492/lib/python/TAL
Modified Files:
TALGenerator.py
Log Message:
Merge TAL i18n fixes which break CMF to HEAD from 2.7 branch.
The agreement Jim was basically that this backward
Gintautas Miliauskas wrote:
Update of /cvs-repository/Zope3/src/zope/tal
In directory cvs.zope.org:/tmp/cvs-serv27951/src/zope/tal
Modified Files:
talparser.py
Log Message:
Removed an assertion which disallows usage of Zope3 i18n in XML markup.
Added a few test cases which run the new code
Jim Fulton wrote:
The first question is:
Is it a problem to have two packages with names differing only in case?
I don't see a problem at all; IIRC, we agreed that the backports from
Zope3 would live in a 'src' directory, while Zope 2 stuff continues to
live in 'lib/python'. No case problem
Jim,
let's make this telegraph style :)
OK, here's another.
What about renaming the Zope 3 zope package to z.
+1
- It fits with the expansion of Zope:
Z Object Publishing Environment.
- It's short :)
- *At this time* (but after the move to svn), it's not too hard to make
a change like
Martin, Maik, Andreas, and others,
I see two issues being raised in this thread:
1. Maik disagrees with the design philosophy behind Zope3 (the Component
Architecture) and the place Zope3 wants to position itself at in the
future. As a Zope developer who has spent the last two years both
Jim Fulton wrote:
2. Especially Andreas expressed his worries about the current release
policy in Zope 2 and its future regarding maintainance and support. I
have to say that I share some of his skepticism regarding Zope 2. I
personally have never fully understood ZC's reasons for the release
Jim Fulton wrote:
Philipp von Weitershausen wrote:
Why would they switch to Zope 2.8 if not for the component architecture?
To stay current? To get MVCC? To get new-style extension classes, and
thus access to many modern Python features. Later releases will provide
benefits beyond just the Z3
Andreas Kostyrka wrote:
On Sun, Apr 25, 2004 at 12:48:30PM -0400, Fred Drake wrote:
On Sunday 25 April 2004 12:29 pm, Jim Fulton wrote:
cvs co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
That should be:
svn co svn+ssh://svn.zope.org/repos/Zope3/trunk Zope3
cvs co
Jim Fulton wrote:
Historically, we've had Packages, Products, Packages3 and Products3
directories in the CBS repository. I wonder of we need these going
forward. Perhaps we should just have top-level projct directories
in the new subversion repository.
+1
Philipp
Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
I chose alternative 4 from:
http://dev.zope.org/Zope3/RenameTheZopePackage
As that seemed to be the most popular, although I personnally prefer
3.
Resolving this peacefully is becoming more urgent for me as I'd
like to be able to use
Stephan Richter wrote:
Hello everyone,
I just wanted to let you all know that the first book covering Zope 3 hit the
shelves yesterday. It is called the Zope 3 Developer's Handbook and was
published by Sams' Developer's Library.
Link to Sams Web-Site:
Sorry for the flooding, it seemed that GMane rejected my messages
because my computer clock was set month ahead (no idea why) while in
fact the messages were posted. Philipp.
___
Zope-Dev maillist - Zope-Dev@zope.org
interfaces
were created by Philipp von Weitershausen before Tres implemented the
bridging functionality.
Correct.
2.) Could we move the interfaces that are currently not available as
Zope 2 interfaces to the corresponding packages in Zope 2.8, using
Five/interfaces.py just as an fallback for Zope
yuppie wrote:
Philipp von Weitershausen wrote:
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to
OFS.interfaces, I guess) where they are added as Zope 2 interfaces
I would prefer to reserve the name 'interfaces' for Zope 3 interfaces.
So far
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
[snip]
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to
OFS.interfaces, I guess) where they are added as Zope 2 interfaces
2. Keep Five's (redudant) interface definitions. They can
yuppie wrote:
Proposed Solution
=
1.) Adding ZCML that bridges existing z2 interfaces into the
'interfaces' module of their package. [Zope 2.8.0]
+1
2.) Copying z3 interfaces from Five.interfaces to the 'interfaces'
module of the corresponding package. Marking those in Five as
yuppie wrote:
Current State
=
Five (now part of Zope 2.8) ships with one big interfaces.py file
that contains z3 interfaces for Zope 2 core classes. (There are also
some five specific interfaces in that file, but they are not subject
of this proposal.)
interfaces.zcml states that
Martijn Faassen wrote:
yuppie wrote:
[snip]
This way, all the work that remains for me is to merge in Five 1.0
into Zope 2.8.
My point is:
Doing that in a backward compatible way is impossible. So we have to
do it now or never.
That's true, but it's not that difficult to ask people to change
yuppie wrote:
I don't think we need to break backward compatability. We would just
need to deprecate the Five.interfaces location.
Basically, the goals are:
* The solution needs to work with Zope 2.7
* Preferrably, the interface import spelling should be equal on both
systems (which means a
yuppie wrote:
4.) Making interfaces.zcml point to the new locations. [Five 1.0+]
5.) Adding unit tests that verify interfaces and implementations.
[Zope 2.8.0]
IMHO that's yagni. We actually don't use interfaces that much for
verifying implementations anymore. I think their most common use in
yuppie wrote:
Yes. I still don't see where the need for incompatability is. Maybe
I'm just blind. Can someone explain?
I no longer see a problem. If we make sure the Five interfaces and those
in the Zope tree are the same, there are no incompatibilities.
By the way, I've just merged in Five 1.0
Tres Seaver wrote:
Your unit test should exercise the whole API promised by an
implementation anyway, so often an explicit interface check is redudant
(of course, it can't hurt). verifyClass() per se isn't bad, it's in fact
a useful indicator, but having that it as a *sole* measure whether a
class
Martijn Faassen wrote:
yuppie wrote:
By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a
significant amount of work, due to all kinds of copyright headers
being different).
Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases
are ZPL 2.1, aren't they? Are there
Jean-Marc Orliaguet wrote:
This is really great news!
I am going to start working at getting Chalmers to be one of the key
players in the foundation which would make the foundation even more
vendor-neutral. I am confident that this will go through.
This almost sounds as if the Foundation
Jean-Marc Orliaguet wrote:
Philipp von Weitershausen wrote:
Jean-Marc Orliaguet wrote:
This is really great news!
I am going to start working at getting Chalmers to be one of the key
players in the foundation which would make the foundation even more
vendor-neutral. I am confident
Andreas Jung wrote:
--On 17. Juni 2005 13:04:17 +0200 Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
Jean-Marc Orliaguet wrote:
This is really great news!
I am going to start working at getting Chalmers to be one of the key
players in the foundation which would make the foundation even
Chris McDonough wrote:
On Fri, 2005-06-17 at 07:52 -0400, Stephan Richter wrote:
Also, I agree with Andreas and Philipp that developers should be members, not
companies. Otherwise, how could I, as an independent developer, have a say?
BTW, this is also positive for companies, since they can
kit blake wrote:
Wow, what a difference two days makes. I heard about the ZF
announcement by telephone two mornings ago, and I breathed a huge sigh
of relief. It solves a problem we've been worrying about for years. It
means we can sit across from a nervous IT director, and when he asks
dubious
yuppie wrote:
If there are no objections, I'd like to merge two changes into the
Zope-2_8-branch before 2.8.1 is released:
1.) Backports from zope.tal to TAL and a small modification of ustr:
http://svn.zope.org/?rev=37613view=rev
http://svn.zope.org/?rev=37614view=rev
This is a fix
Hello all,
[Sorry for the cross-post, please CC replies to zope3-i18n@zope.org only.]
two months ago, I started an initiative [1] to translate Zope 3.1 using
Ubuntu's Launchpad system [2]. Since then, I've received a lot of emails
from numerous volunteers around the world and many of them made
yuppie wrote:
* Moved to a zpkgutils-based build system, as the Zope 3.2 extension
modules
require to be built with it. If everything goes ahead as planned,
the release
tarball will also be built with zpkgutils (some work has also been
done in
that direction).
That part
Philipp von Weitershausen wrote:
That worked for me (though I usually don't do the configure; make dance,
but just do an in-place build with python setup.py build -i; see also
below).
Sorry, I meant
$ python setup.py build_ext -i
That's what make all does on Zope 3 and now on Zope 2
Jim Fulton wrote:
What changes are those? A fresh Zope trunk checkout works for me. Here's
what I did:
$ svn co svn+ssh://[EMAIL PROTECTED]/repos/main/Zope/trunk
Zope-trunk
$ cd Zope-trunk
$ ./configure
$ make
That worked for me (though I usually don't do the configure; make
Jim Fulton wrote:
We need to stitch zope.app into Zope 2 more carefully than we
are now. Much of what we are stitching is unreleased in Zope3
and depends on things not stitched nto Zope 2.
Among other things, this means that we can't use
python2.4 test.py -m.
to run all tests
Yvo Schubbe wrote:
Log message for revision 39903:
- converted interface to z3 interface.
Changed:
D Zope/trunk/lib/python/AccessControl/IUserFolder.py
I think we should maybe leave the Zope 2 interfaces around for at least
one release. People with custom user folder implementations
yuppie wrote:
Philipp von Weitershausen wrote:
Log message for revision 39903:
- converted interface to z3 interface.
Changed:
D Zope/trunk/lib/python/AccessControl/IUserFolder.py
I think we should maybe leave the Zope 2 interfaces around for at least
one release. People
Tres Seaver wrote:
Log message for revision 40092:
Don't hard-wire forward-slash into sys.path (redux).
Please don't forget to merge this and the previous rev to the Zope 2.9
branch. From now on, both the trunk and the 2.9 branch need to be taken
care of.
Philipp
Florent Guillaume wrote:
BTW I'm for removing the 2.9 branch for now.
You didn't, so I presume 2.9 branch stays? It's important to clear the
status of this branch because bugfixes need to be merged to it (see my
email about Tres' bugfix, for example).
By the way, in the future, just to avoid
Andreas Jung wrote:
--On 15. November 2005 00:20:00 +0800 Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
Florent Guillaume wrote:
BTW I'm for removing the 2.9 branch for now.
You didn't, so I presume 2.9 branch stays? It's important to clear the
status of this branch because
Andreas Jung wrote:
--On 16. November 2005 14:03:05 -0500 Jim Fulton [EMAIL PROTECTED] wrote:
Does this mean that the existing 2.9 branch needs to be removed and that
the trunk remains frozen?
Didn't Florent delete the branch? Obviously he did not as I assumed.
So in this case Philipp
Hi there,
Zope/doc/LICENSE.txt still is ZPL 2.0 and so are most of the file
headers in the Zope 2 source code. Newer files, especially those from
Five, are ZPL 2.1, though. I think it's a good time to switch the rest
of Zope 2 to ZPL 2.1. That way we only have to supply one license text.
Philipp
Hi there,
quick reminder for all of you who have Zope 2.9 branch checkouts: There
has been a change (finally!) in the release branch naming scheme. The
2.9 branch was renamed to Zope/branches/2.9 as a result. This will be
the naming scheme for all release branches in Zope 2 and 3 from now on.
Martijn Faassen wrote:
Stephan Richter wrote:
On Wednesday 23 November 2005 10:16, Philipp von Weitershausen wrote:
Sounds crazy, I know. But I'm serious. Looking for your comments at:
http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository
I am -1. If I could I would
Gary Poster wrote:
Sounds crazy, I know. But I'm serious. Looking for your comments at:
http://dev.zope.org/Zope3/
ReuniteZope2AndZope3InTheSourceCodeRepository
I already spoke with Philipp on IRC about this, but for the record,
and speaking personally, and very arguably selfishly: -1.
Roger Ineichen wrote:
Reading the response to this mail, I guess developer
working on existing Zope2 projects agree on this proposal.
And developer where build projects only based on Zope3
will not.
As somebody how don't know Zope2 I'm -1 on this.
I could repeat here what Martijn and I
Dominik Huber [EMAIL PROTECTED]:
Stephan Richter wrote:
This may raise the contribution bar too high.
IMO that 's the most important point.
It raises the bar for Zope 3 developers a bit while lower the bar for Zope 2
developers
tremendously. I'm looking at the bigger picture and see it all
Julien Anguenot wrote:
Some Zope3 developers don't care about Zope2 and this is fair enough in
my point of view. Zope2 starts to get old and appears to be really a
mess compared to Zope3 in *2005*, plus it's not such an attractive
platform as it used to be couple of years ago. (Don't get me
Julien Anguenot wrote:
And what about the acceptance of Zope3 *outside* the Zope community ?
Zope3 will look like more complicated and confusing doing a merge.
Why? The 'zope' namespace package is what Zope 3 is known as to outsiders and
this will
not be affected.
I understand your
Stephan Richter wrote:
I totally disagree. I, as a Zope 3 developer, have to learn Zope 2 and Five.
What makes you think so? I, for one, have not the slightest clue of how
zope.wfmc works.
Still I'm able to contribute to Zope 3, am I not? If I refactor something, I
might even
have to touch
Stephan Richter wrote:
On Wednesday 23 November 2005 22:01, Philipp von Weitershausen wrote:
Messing up Zope 3 is specifically not the intention of this proposal. It
says so explicitly in the Your questions answered section.
Though it is not your intend, the merge would in fact mess up
Quoting Stephan Richter [EMAIL PROTECTED]:
On Wednesday 23 November 2005 21:43, Philipp von Weitershausen wrote:
I know that you, Roger, have been contributing a lot to new exciting
features in Zope 3. In doing so, you would never have to worry about Zope 2
because Zope 2 will only
Stephan Richter wrote:
On Wednesday 23 November 2005 21:48, Philipp von Weitershausen wrote:
Note that I also understand your motivation on voting -1 quite well.
Leaving everything as it is is simply the easier thing to do. For the
moment...
I will always vote -1 on such a move. I just
Stephan Richter wrote:
On Thursday 24 November 2005 00:05, Philipp von Weitershausen wrote:
Stephan Richter wrote:
I totally disagree. I, as a Zope 3 developer, have to learn Zope 2 and
Five.
What makes you think so? I, for one, have not the slightest clue of how
zope.wfmc works
Stephan Richter wrote:
On Thursday 24 November 2005 00:25, Philipp von Weitershausen wrote:
Quoting Stephan Richter [EMAIL PROTECTED]:
This would be Zope 3's death blow
as we know it, because it would stall Zope 3 for several months.
Why would it stall Zope 3 development?
Because
Benji York wrote:
Philipp von Weitershausen wrote:
Really, *how* does it mess up the trunk? Half of the packages of Zope
2 are also in Zope 3 because they're either ZODB or Zope3-related
anyway. Another quarter of the packages will go away within one year
Perhaps that would be a more
Roger Ineichen wrote:
What makes you think so? I, for one, have not the slightest
clue of how zope.wfmc works.
Still I'm able to contribute to Zope 3, am I not? If I
refactor something, I might even
have to touch zope.wfmc, but for the most part this could be
very superficial.
That's
Chris McDonough wrote:
I really, really appreciate Phil taking the time to propose this no
matter what happens.
Chris, I won't bother you with a detailed answer (esp. to some points that were
not quite
correct about Zope 3 not caring about backward compat). I just wanted to say
that I also
Roger Ineichen wrote:
Btw, do we really count developer where are voting but never
contributed to the z3 trunk? I think normaly yes. But this is a
proposal where I think should be up to the Zope3 developer
to decide.
Uh, why only Zope3 developers? This affects the whole Zope community!
Jim Fulton wrote:
Philipp von Weitershausen wrote:
Sounds crazy, I know. But I'm serious. Looking for your comments at:
http://dev.zope.org/Zope3/ReuniteZope2AndZope3InTheSourceCodeRepository
I love this idea!
Ok.
But I think it's still a bit too early to pursue it.
Perhaps so. Other
Hi,
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone, as you can see, is GMT+0800 (Beijing time).
[EMAIL
Jens Vagelpohl wrote:
Hi,
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone, as you can see, is GMT+0800
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone, as you can see, is GMT+0800
Jens Vagelpohl wrote:
On 26 Nov 2005, at 15:07, Philipp von Weitershausen wrote:
However, I am noticing that on the current Zope 2.9 branch, trying to
build the software fails completely. The configure script works
fine,
but the make step does not seem to do anything at all.
Yes
Alexander Limi wrote:
Philipp von Weitershausen wrote:
I've recently been seeing weird DateTime test failures on all Zope 2
branches since 2.7 (see below). Any idea what I'm doing wrong? My system
is OSX 10.3 with a self-compiled Python 2.4.1 (through darwinports). My
system timezone
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Andrew Milton wrote:
-1 for any scheme that involves diddling the ZODB to 'fix' pickles, because
you just know you're going to corrupt someone's ZODB, and that's just
noone's idea of fun.
There are sensible ways of upgrading
Tres Seaver wrote:
Frankly, anything which attempts to fix pickles in-place smells bad to
me. Dump and reload is how the RDBMS world handles this kind of
problem, and it isn't because they don't have smart folks working on them.
You're right, as nice as generations might be, they can't
I'm happy to announce that I've finally managed to document the
internationalization (i18n) features that Five has brought to the Zope 2
world since version 1.1:
http://worldcookery.com/files/fivei18n
This short tutorial compares current Zope-2-based solutions to the i18n
problem with the Zope 3
Chris Withers wrote:
Is zLOG deprecated?
If not, it should be...
+10
zLOG/__init__.py says:
Note:
This module exists only for backward compatibility. Any new code
for Zope 2.8 and newer should use the logging module from Python's
standard library directly. zLOG is only an
Rocky Burt wrote:
Anyone know if there is any plan to add a toplevel products folder in
the zope svn repo like there currently is in zope's cvs repo? I know
this has held up a few products from going from zope CVS to SVN.
I don't think a separate Products folder is is necessary. Just make
Chris Withers wrote:
Philipp von Weitershausen wrote:
If not, it should be...
+10
Yeah, me too! Hence why I was asking ;-)
That means we could deprecate it even in Zope 2.9, using zLOG has
already been discouraged in Zope 2.8.
Cool, Andreas, can you make it start emitting
Andreas Jung wrote:
make sdist:
[EMAIL PROTECTED]:~/sandboxes/Zope-2.9/2.9.0b1: make sdist
zpkg -C /develop/sandboxes/Zope-2.9/2.9.0b1/releases/Zope2.cfg
'version.txt' doesn't match any files in collection
(in /develop/sandboxes/Zope-2.9/2.9.0b1/lib/python/zope/app/PACKAGE.cfg)
Andreas Jung wrote:
Log message for revision 40469:
deprecated FastCGI
Changed:
U Zope/branches/2.9/doc/CHANGES.txt
U Zope/branches/2.9/doc/WEBSERVER.txt
U Zope/branches/2.9/lib/python/ZServer/datatypes.py
[snip]
Modified:
Philipp von Weitershausen wrote:
this checkin made the tests fail for the build-bot
(http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html).
Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard
to see where FCGIServerFactory() is called from. Maybe tests?
I
Philipp von Weitershausen wrote:
Philipp von Weitershausen wrote:
this checkin made the tests fail for the build-bot
(http://mail.zope.org/pipermail/zope-tests/2005-December/003728.html).
Since you didn't use stacklevel=2 in the warnings.warn() call, it's hard
to see where FCGIServerFactory
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent
handling of the version.txt matter yesterday.
http://dev.zope.org/Zope3/MakingARelease says that
zope.app/version.txt should be created on a tag and
zope.app/PACKAGE.cfg should also be modified to include
Jim Fulton wrote:
This is a very recent problem and a result of Jim's inconsistent
handling of the version.txt matter yesterday.
http://dev.zope.org/Zope3/MakingARelease says that
zope.app/version.txt should be created on a tag and
zope.app/PACKAGE.cfg should also be modified to include
Chris Withers wrote:
Philipp von Weitershausen wrote:
This would probably best be handled by one person, so if you are willing to
do all
the grepping and updating, making zLOG deprecated would just be a minor
operation :).
...but one i don't know how to perform. What code would I
Jim Fulton wrote:
When presenting users with ordered text (e.g. sorted lists of options),
simply sorting Unicode strings doesn't provide an ordering that
users in a given locale will find useful. Various languages have
text sorting conventions that don't agree with the ordering of
Unicode
Andreas Jung wrote:
The build process changed in 2.9.
Perhaps make inplace; make test should work.
He explicity said in a tarball. make inplace only exists in SVN. As a
reminder:
SVN repo != release tarball
I know it's always been '==' for every other Zope 2 version, but 2.9 is
different
Paul Winkler wrote:
On Mon, Dec 12, 2005 at 05:40:27AM +0100, Andreas Jung wrote:
The build process changed in 2.9.
Perhaps make inplace; make test should work.
-aj
Good thought, but there is no inplace target anymore.
Yup, Andreas was referring to the SVN checkout.
What is now the
Tino Wildenhain wrote:
Am Sonntag, den 11.12.2005, 23:19 -0500 schrieb Paul Winkler:
Another quickie problem report - no time to investigate further right
now, but can anybody else reproduce? If so, I'll try to fix tomorrow...
In a fresh 2.9.0-b1 instance, made via bin/mkzopeinstance, I get
Florent Guillaume wrote:
I have a strange thing in Zope 2.8 and Zope 2.9 I never noticed.
{'-C': ''} is present in REQUEST.form for a GET request without arguments.
A simple script showrequest with return repr (context.REQUEST.form)
shows it.
A bit of digging shows this is due to cgi.py
Jim Fulton wrote:
This is really just a matter of knowing how to write the test.
Generally, when you want to show a dict sample, the way to do it
is with:
from zope.testing/doctestunit import pprint
pprint(thisdict)
This formats the dictionary nicely and, most importantly,
sorts the
Tim Peters wrote:
I'm not sure what it is testing, either; CC'ing Phillip, whose
fingerprints are on it, according the 'svn blame', for clarification.
These tests have always failed, and Phillip doesn't know why.
Because they were failing, he changed them to run at level 2. That's
not
[resending this from the right address, the original posting got
swallowed by Mailman]
Tres Seaver wrote:
Benji York wrote:
The Zope2 unit tests have been failing for some time on
buildbot.zope.com. Looks like a Five-related problem:
Tres Seaver wrote:
Well, if you look closer you find that it uses pprint.pformat which always
outputs
the same on all machines (because it provides output sorted by the
dictionary key).
I see that in the implementation; it isn't documented as part of
pprint's contract, however.
Yes
Tim Peters wrote:
I wouldn't know where to start (having tried to debug this problem in the
past).
Anyone got an idea?
For a start, disabuse yourself of the illusion that it acts
differently on Windows than on Linux ;-)
Yup, sorry, misread the issue. Speed kills... :)
Philipp
Jim Fulton wrote:
Obviously, some other test isn't cleaning up after itself.
Yes, that was obvious to me too. It was confusing that the same test would pass
on Five
1.2, though, and I couldn't find any obvious differences. As trial and error
usually
takes time, I left the issue to be resolved
Tres Seaver wrote:
Well, if you look closer you find that it uses pprint.pformat which always
outputs
the same on all machines (because it provides output sorted by the
dictionary key).
I see that in the implementation; it isn't documented as part of
pprint's contract, however.
Tim Peters wrote:
... a good lecture on pprint vs. dicts
Thanks, I'll be more careful about using pprint for dicts then.
Philipp
This message was sent using IMP, the Internet Messaging Program.
Philipp von Weitershausen wrote:
Jim Fulton wrote:
Obviously, some other test isn't cleaning up after itself.
Yes, that was obvious to me too. It was confusing that the same test would
pass on Five
1.2, though, and I couldn't find any obvious differences. As trial and error
usually
Lennart Regebro wrote:
On the actual problem, this is a big red flag for me:
'isinstance(zapi.getSiteManager(), FiveSiteManager)': True,
Fails. So, it's not a FivesiteManager. What is it? None, or something else?
It's the global site manager if not the FiveSiteManager.
Since this seems
1 - 100 of 436 matches
Mail list logo
