Re: [Zope-dev] ZTK 2.0: Deprecate zope.sequencesort
On Thursday, February 28, 2013, Stephan Richter wrote: I would like to deprecate zope.sequencesort in ZTK 2.0, since it cannot properly ported to Python 3, since it depends heavily on the cmp() way of sorting. I am also not a user of the package and I only tried to port the package for completeness sake. You can always fall back to functools.cmp_to_key() to use cmp-based sorting in python 3: http://docs.python.org/3/library/functools.html#functools.cmp_to_key -- Martijn Pieters -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZODB-Dev] [announce] NEO 1.0 - scalable and redundant storage for ZODB
On Mon, Aug 27, 2012 at 2:37 PM, Vincent Pelletier vinc...@nexedi.com wrote: NEO aims at being a replacement for use-cases where ZEO is used, but with better scalability (by allowing data of a single database to be distributed over several machines, and by removing database-level locking), with failure resilience (by mirroring database content among machines). Under the hood, it relies on simple features of SQL databases (safe on-disk data structure, efficient memory usage, efficient indexes). How does NEO compare to RelStorage? NEO appears to implement the storage roughly in the same way; store pickles in tables in a SQL database. Some differences that I can see from reading your email: * NEO takes care of replication itself; RelStorage pushes that responsibility to the database used. * NEO supports MySQL and sqlite, RelStorage MySQL, PostgreSQL and Oracle. * RelStorage can act as a BlobStorage, NEO can not. Anything else different? Did you make any performance comparisons between RelStorage and NEO? -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: Zope/trunk/ `setHeader('Set-Cookie', ...)` special-casing can die
On Mon, Oct 17, 2011 at 11:57, Stefan H. Holek ste...@epy.co.at wrote: There are test failures on Zope trunk which look to be connected to your changes. https://mail.zope.org/pipermail/zope-tests/2011-October/051224.html Please investigate, Ugh. Those tests can go, and someone already dealt with them before I got to them. Mea Culpa! -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting ha...@hannosch.eu wrote: Ok, seems 4.0 is the more popular choice. I don't agree. Let's go with Fibonacci and call the next release Zope 8, as the logical extension of the series 1, 2, 3, and 5! :-P -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope] Security announcement update
On Tue, Jun 28, 2011 at 15:30, Sascha Welter zopel...@betabug.ch wrote: It says Zope 2.10 and 2.11 users who have not installed PloneHotfix20110720 are not affected - can I conclude from that, that Zope 2.9 would not be affected either? Indeed, Zope 2.9 is not affected, with or without the previous hotfix. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope] Security announcement update
On Tue, Jun 28, 2011 at 15:40, Norbert Marrale norbertmarr...@yahoo.com wrote: Why must PluggableAuthService (+ its dependencies) even be installed? It is a dependency of Plone itself. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - OK: 77
On Wed, Jun 22, 2011 at 10:01, Lennart Regebro rege...@gmail.com wrote: Whohoo! Amesome work all bugfixers! Wohoo disabling the windows bots! -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form: Default form content type
On Sun, Apr 10, 2011 at 15:54, Markus Kemmerling markus.kemmerl...@meduniwien.ac.at wrote: By default z3c.form sets the form content type to 'multipart/form-data' (the default value of IInputForm['enctype']). According to http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 this MIME type should be used for submitting forms that contain files, non-ASCII data, and binary data. Shouldn't the default value rather be set to the default content type of HTML forms, i.e. 'application/x-www-form-urlencoded'? The majority of forms use Unicode widgets, so this falls under the heading of non-ASCII data. Also, it'd be almost impossible to auto-detect when binary data will be handled by the form, unless you start introspecting widget output, so the default looks entirely sane to me. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Distutils] [buildout] private releases
On Wed, Mar 30, 2011 at 15:08, Jim Fulton j...@zope.com wrote: We do something similar with sftp (zc.buildoutsftp). To publish eggs, we just use scp. The advantage of this is that it leverages ssh infrastructure, so *no* additional password management is needed. This is wildly better, IMO, than keeping passwords in clear text in your buildout configuration or in a dot file. That depends on your deployment scenarios. We generate separate passwords per customer, and give them a dedicated URL to load their private eggs from, then put the password in the buildout.cfg. To load the buildout.cfg in the first place, the exact same password is used. Managing SSH accounts and keys for those customers would cost us much more overhead, and would complicate our instructions for deployment to them. On the other hand, for deployments of a buildout from a SVN repository already served over SSH would make the sftp route the logical choice. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [buildout] private releases
On Tue, Mar 29, 2011 at 14:16, Adam GROSZER agroszer...@gmail.com wrote: Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PAS, AuthEncoding and zope.password
On Fri, Feb 18, 2011 at 22:19, Martijn Pieters m...@zopatista.com wrote:
We should at the very least convert PAS to use zope.password instead
of AccessControl.AuthEncoding.
There is a snag. The zope.password API doesn't provide any way to
detect what scheme was used for a given hash.
Say you have a SSHA hash, it'll start with the string {SSHA}, while
a bcrypt encryption starts with $2a$. Unfortunately, the
zope.password IPasswordManager only provides methods to encode the
password and check if a given password is correct. The only consumer
of the interface, zope.app.authentication.principalfolder only
supports one password manager at a time so never had a need to detect
schemes.
I'll just go ahead and expand then IPasswordManager interface to
provide a match method that returns a boolean if a given hash uses the
specific encoding scheme. Presumably this'll be zope.password 4.0.0.
What does this mean for the versioning of AccessControl however? Will
that'll be a 2.14 release? What version of Zope2 can start using the
new AccessControl package with a zope.password = 4.0.0 dependency?
Zope2 primarily uses the ZTK, so a version pin would be needed there
until the new zope.password release makes it into the ZTK.
--
Martijn Pieters
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PAS, AuthEncoding and zope.password
On Sun, Feb 20, 2011 at 11:56, Hanno Schlichting ha...@hannosch.eu wrote:
Yes, changing the existing interface would require a 4.0. If you'd add
a new interface extending the IPasswordManager one, we could do it in
a 3.x release.
A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a
backwards incompatible 4.0 would have to wait for ZTK 1.2.
Right. What would be a suitable name for the extended interface?
IMatchingPasswordManager?
I've committed a revision that implements this as an extension to the
existing interface:
http://zope3.pov.lt/trac/changeset/120458/zope.password/trunk
but that's easy enough to change.
I've also found that the SHA1 scheme in zope.password uses the {SHA1}
prefix, which is incompatible with LDAP and
AccessControl.AuthEncoding, which both use {SHA} instead. I'll change
zope.password to support {SHA} as well, defaulting to that prefix.
What version of Zope2 can start using the
new AccessControl package with a zope.password = 4.0.0 dependency?
This depends on the changes in AccessControl and how backwards
compatible they are.
If backwards compatibility is preserved, this can go into Zope 2.13
and trunk, since we allow minor feature additions in the stable
series. Zope 2.12 is at a 2.12.15 release now and at the end of its
lifecycle - it'll only see bugfixes.
It'll be backwards compatible. I'm planning to keep supporting legacy
schemes registered with registerScheme, with listSchemes listing
zope.password managers as well.
The only thing that could perhaps be removed are the SSHADigestScheme
and SHADigestSCheme classes, as these will be completely redundant
with zope.password support.
--
Martijn Pieters
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PAS, AuthEncoding and zope.password
On Sun, Feb 20, 2011 at 12:39, Martijn Pieters m...@zopatista.com wrote:
Yes, changing the existing interface would require a 4.0. If you'd add
a new interface extending the IPasswordManager one, we could do it in
a 3.x release.
A new zope.password 3.x release could go into both ZTK 1.1 and 1.0, a
backwards incompatible 4.0 would have to wait for ZTK 1.2.
Right. What would be a suitable name for the extended interface?
IMatchingPasswordManager?
I've committed a revision that implements this as an extension to the
existing interface:
http://zope3.pov.lt/trac/changeset/120458/zope.password/trunk
but that's easy enough to change.
I've also found that the SHA1 scheme in zope.password uses the {SHA1}
prefix, which is incompatible with LDAP and
AccessControl.AuthEncoding, which both use {SHA} instead. I'll change
zope.password to support {SHA} as well, defaulting to that prefix.
I've implemented the {SHA} prefix change, as well as implement {CRYPT}
support, making zope.password useful for all schemes explicitly named
in RFC 2307, except the MD5 scheme.
The latter uses a salt by default, making it incompatible with LDAP
{MD5}. Open LDAP implements a salted MD5 scheme ({SMD5}) but places
the salt at the end of the hash, not at the beginning as the
zope.password manager implements it.
I think I can keep that one backwards compatible but disable support
for generating hashes with a salt, and add a SMD5 manager to implement
a compatible scheme.
With all the new password managers, this will be at least a 3.7
release, with a separate extended interface.
--
Martijn Pieters
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 72 OK, 15 Failed
On Fri, Feb 18, 2011 at 10:39, Adam GROSZER agroszer...@gmail.com wrote: Windowze... We also have such a failure 1 in 50 buildbot runs. Tho very misterious how it could happen 3x in a row. If the failure is random, with a chance of 1 in 50, 3 times in a row is no mystery. It shows the failure is truly random! :-) -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] PAS, AuthEncoding and zope.password
I was looking into bcrypt[1] support for PAS I found z3c.bcrypt, which implements zope.password compontents (named utilities). PAS, however, uses Zope2's AccessControl.AuthEncoding module to handle password encryption / hashing schemes. Now, while AuthEncoding certainly supports extending the available schemes, it does need additional glue-code to be able to reuse zope.password components. Moreover, we now have two places to maintain the various hashing and encryption schemes. We should at the very least convert PAS to use zope.password instead of AccessControl.AuthEncoding. With that change it is then at least trivial to support bcrypt as well, you simply install the additional z3c.bcrypt egg and be done with it. But would it make sense to convert Zope2 itself as well? We could make the AuthEncodings module simply a proxy (with deprecation warnings if need be) for zope.password components. Any objections to reworking both AuthEncoding and PAS? -- Martijn Pieters [1] see http://codahale.com/how-to-safely-store-a-password/ and http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New release of z3c.form
On Thu, Jul 1, 2010 at 3:10 PM, Godefroid Chapelle got...@bubblenet.be wrote: http://packages.python.org/z3c.form The index is empty and module index appears to be missing altogether: http://packages.python.org/z3c.form/index.html#indices-and-tables -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: Zope/branches/2.12/src/Products/Five/browser/absoluteurl.py Fix _getContextName; does anyone test this stuff?
2010/2/26 Tres Seaver tsea...@palladion.com: Kettle to pot: Did you add a test? I ran out of time; the current tests weren't easily molded to add a case for this. I felt that at least the simple 'return' statement fix should go in. I'll get the test case in this weekend, hopefully. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 6 OK, 2 Failed
2009/10/31 Tres Seaver tsea...@palladion.com: I can't reproduce this failure when running the Acquisition 2.12.4 tests with Python 2.4 on my machine. This is python 2.4 on 64-bit linux. I bet it's because of: typedef int Py_ssize_t; and sys.maxint overflows to -1 with that definition. I suspect that all open-ended slicing ops in Python C extensions are borken in python 2.4, because it doesn't have Py_ssize_t. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Sat, Aug 8, 2009 at 13:19, Hanno Schlichting ha...@hannosch.eu wrote: One thing to note here is that the above change is indeed only of of probably many that need to be made to support 64-bit platforms properly. The other thing to note is that the change now introduces a hard requirement on Python 2.5 or later. Neither Martijn nor me could figure out a way to make the function calls to Build have different format identifier arguments dependent on the Python version. On Python 2.4 there is only i for integer and 2.5 introduces n for Py_ssize_t. Since this is an argument to a function showing up in various combinations of nn, nO and others, there seems to be no easy way to make this work. Someone with more knowledge about pre-processor tricks might come up with a solution to this, otherwise we will have to choose between dropping 64-bit support or dropping the unofficial Python 2.4 support. It turned out to be really simple as consecutive string literals are concatenated into one after macros are expanded. The following changeset should make Acquisition python 2.4 compatible again and also properly 64-bit capable: http://svn.zope.org/Acquisition/trunk/src/Acquisition/_Acquisition.c?rev=102577view=rev To summarize: when passing Py_BuildValue a Py_ssize_t value to build a python int, you need to use the 'n' format string instead of 'i'. But because 'n' and Py_ssize_t are both defined as of python 2.5, for C code to work in python 2.4 you need to redefine these two back to 'i' and int. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Mon, Aug 3, 2009 at 08:04, Martijn Pieters m...@zopatista.com wrote: AssertionError: Incorrect Content-Length is set! Expected 20425, got 20426. I don't grok the range support code at all: probably Martijn Pieters is the only person in the world who does. The tests are quite obscure to me, so I can't diagnose even whether the failure is a testing artifact or a real bug. Here's my response to Tres; for some reason my mail reader didn't include zope-dev. I can add now that I'll be at a sprint this weekend where I'll probably have time to take a look myself: I have found the problem, but do not understand where exactly the error occurs. The problem is caused by an acquisition wrapped object with a __getslice__ method get the wrong indices passed in when the end parameter is ommitted: data[start:] Image.Pdata classes have a __getslice__ method, and when data is acquisition wrapped, that method gets (start, -1) passed in on 64-bit platforms, while on my Macbook (start, sys.maxint) is passed in instead. Obviously this means that the slice returns not everything from 'start' to the end, but from 'start' until the one-but-last byte. However, as far as I can tell cAcquisition.c doesn't touch the start and end values. Anyone want to investigate why this goes wrong? Here is the simple test case: from Acquisition import Implicit class Root(Implicit): pass class Slicer(Implicit): def __getslice__(self, start, end): return [start, end] root = Root() slicer = Slicer().__of__(root) print slicer[1:] Run this as bin/zopepy acquisition.py and verify that [1, -1] is printed on 64-bit platforms as opposed to [1, 2147483647] on 32-bit platforms. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Fri, Aug 7, 2009 at 14:55, Martijn Pieters m...@zopatista.com wrote: Here is the simple test case: from Acquisition import Implicit class Root(Implicit): pass class Slicer(Implicit): def __getslice__(self, start, end): return [start, end] root = Root() slicer = Slicer().__of__(root) print slicer[1:] Run this as bin/zopepy acquisition.py and verify that [1, -1] is printed on 64-bit platforms as opposed to [1, 2147483647] on 32-bit platforms. Further datapoints, the following extra lines for the above script give more context to compare: import sys print slicer[sys.maxint:] print slicer[sys.maxint-1:] print Slicer()[1:] So we pass in sys.maxint and sys.maxint-1 as start values, and also run the Slicer without acquisition wrapping to demonstrate that the wrapper is the culprit, not python itself. Python passes in sys.maxint for the end value for the slice if you omit it, and these high values overflow somewhere in the wraper. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Fri, Aug 7, 2009 at 14:55, Martijn Pieters m...@zopatista.com wrote: The problem is caused by an acquisition wrapped object with a __getslice__ method get the wrong indices passed in when the end parameter is ommitted: data[start:] Image.Pdata classes have a __getslice__ method, and when data is acquisition wrapped, that method gets (start, -1) passed in on 64-bit platforms, while on my Macbook (start, sys.maxint) is passed in instead. Obviously this means that the slice returns not everything from 'start' to the end, but from 'start' until the one-but-last byte. However, as far as I can tell cAcquisition.c doesn't touch the start and end values. Anyone want to investigate why this goes wrong? The following checkin fixed this particular problem: http://svn.zope.org/Acquisition/trunk/src/Acquisition/_Acquisition.c?rev=102564view=rev The acquisition slice wrapper accepted Py_ssize_t arguments, but then passed these of as C ints (format string 'i'). Changing the format string to 'n' (Py_ssize_t) fixed *this particular case*. Likely more such fixes must be made. In any case, the HTTP range test no longer fails with this fix. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Linux x86_64 [Was: Zope Tests: 3 OK, 5 Failed]
On Tue, Jul 21, 2009 at 18:40, Tres Seaver tsea...@palladion.com wrote:
File /home/tseaver/projects/Zope-trunk/src/OFS/tests/testRanges.py,
line 332, in testMultipleRangesBigFileOutOfOrder
(7, 80001)])
File /home/tseaver/projects/Zope-trunk/src/OFS/tests/testRanges.py,
line 209, in expectMultipleRanges
str(len(body)), rsp.getHeader('content-length')))
File /opt/Python-2.6.2/lib/python2.6/unittest.py, line 321, in
failIf
if expr: raise self.failureException, msg
AssertionError: Incorrect Content-Length is set! Expected 20425,
got 20426.
I don't grok the range support code at all: probably Martijn Pieters is
the only person in the world who does. The tests are quite obscure to
me, so I can't diagnose even whether the failure is a testing artifact
or a real bug.
Here's my response to Tres; for some reason my mail reader didn't
include zope-dev. I can add now that I'll be at a sprint this weekend
where I'll probably have time to take a look myself:
8--
Sorry you find them obscure; I followed unit test expectations as best
as I could.
The test that fails does the following:
1) Create a big file (uploadBigFile, enough random data to be more
than one pdata chunk)
2) Request for multiple HTTP ranges (slices) of the file to be sent.
These slices should be returned a) in the same order, b) of the
correct length, and of course c) the correct slice of the big file
created in 1.
In this case line 330 specifies that bytes 10-15 (inclusive), the last
1 bytes, and bytes 7-8 (inclusive) are are to be returned.
The call to expectMultipleRanges includes the expected slices (python
syntax, so end value is exclusive).
3) On line 209 of expectMultipleRanges it then tests if the resulting
response has the correct content length header for the whole response
set. The failure reported is that the Content-Length header reports 1
byte more than what was actually sent, so the body was 20425 bytes
long, while the content-header claims it would be 20426 bytes.
Because this is a multi-part range request, Image.py line 277 and
onwards handle this request. The response ends up looking something
like this:
Content-length: size we pre-calculate
Content-type: multipart/byteranges; boundary=boundarystring
More headers
--boundarystring
Content-type: image/whatever
Content-range: bytes start-end/total-file-size
data ...
--boundarystring
... Another section
... etc.
--boundarystring--
There are 2 ways the failure could be caused.
Something could go wrong with the size calculation on lines 280-287;
the total body length is the length of the range data plus the length
of the headers per multi-part plus the length of the MIME boundaries
between them. There is thus a length per part plus the length of the
last boundary.
Or something goes wrong when writing the range data in lines 309-358.
Because there is only one byte difference between what was calculated
on lines 280-287 and what is produced here this is probably a newline
somewhere.
I do find it puzzling this only fails on 64 bit platforms. It could be
that the pdata chunk handling is borken and has a off-by-one error
when running on 64-bit platforms.
Hope this clarifies things a little. I have little time right now to
chase this myself right now, sorry!
8--
--
Martijn Pieters
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] HA storage for zope
On Wed, Jun 3, 2009 at 01:04, Miles Waller mi...@jamkit.com wrote: 1. RelStorage Using this, I think I can then take care of replication/mirroring as I have access to a database that is already clustered in a HA environment. My questions are: + Are the connections opened only when zope is started? Say I unplugged a network cable and then plugged it back in again (breaking the database connection) - will it be re-opened? + How does RelStorage take care of the blob storage? Hanno answered these 2 already. + Are there any details of big sites out there that use RelStorage (particularly on Oracle)? The Elkjøp intranet cluster currently runs on 4 machines with 4 clients each, plus a maintenance client on a 5th machine. Varnish and fail-over rigged load balancers complete the cluster. Currently there are 100k+ content objects and 7k active users using this intranet (plus another 3k inactive). -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Align Zope 2 and Zope 3 permissions
On Sun, Apr 12, 2009 at 12:31, Martin Aspeli optilude+li...@gmail.com wrote: 1) Use an event handler to ensure that any permission / declared in ZCML actually creates a valid, Zope 2 permission. I have working code for this here which we could put in Products.Five with ease. http://dev.plone.org/collective/browser/collective.autopermission/trunk/collective/autopermission/permissions.py Benefits: Creating new permissions becomes more predictable. Risks: None obvious. The event handler will not override permissions that already exist. 2) Emit a warning instead of an error in Five's handler for the class / directive when set_attributes or set_schema are used. Benefits: Easier to re-use existing packages Risks: The attributes won't actually be protected. However, since Zope 2 doesn't have the concept of protecting 'set' (or security proxies) then I'm not sure there's a problem of expectation. I like, +1. 3) Change the Permission class in AccessControl so that it tries to look up an IPermission utility and use the title of that utility as the permission name, falling back on the current behaviour of using the passed permission name directly. Benefits: Should transparently allow any invocation of the Zope 2 API to use Zope 3 permission names, allowing us to document that the dotted permission name is the canonical name everywhere. Risks: Performance overhead of doing utility lookups. May result in name clashes, but since the permission name is a dotted name and the Zope 2 permission name isn't, I think it's extremely unlikely that this would actually happen in practice. I'm sure we can do some performance comparisons on this one. I'd say it's worth the cost, but hard numbers would help. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Mon, Apr 6, 2009 at 10:32, Chris Withers ch...@simplistix.co.uk wrote: Just beware, 1.5 sucks: http://subversion.tigris.org/issues/show_bug.cgi?id=3242 http://thread.gmane.org/gmane.comp.version-control.subversion.user/84308/focus=84019 http://thread.gmane.org/gmane.comp.version-control.subversion.user/87346/focus=87525 It sucks for very specific cases, namely tight access control on sub-paths. I don't see such cases, and I see speed improvements instead. Note that we are now up to svn 1.6. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Mon, Apr 6, 2009 at 10:39, Chris Withers ch...@simplistix.co.uk wrote: I'm more worried about the lack of merging working and random errors when adding files. Those are pretty serious failures from where I'm sitting... The merging is due to lack of merging info when branching, the 'random errors' are not random but due to svn info being out-of-date after a commit. svn up has always solved that for me. Yes, the latter is a bug, but I suspect it is already solved in 1.6 (didn't test that yet though). -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman wich...@wiggy.net wrote: Note that we are now up to svn 1.6. Which still does not fix this, and is preventing people from upgrading to the 1.5 client, and thus from using checkouts using relative paths. Bugger, that is indeed correct. I may not have any problems (and a workaround for svn bug 3119) but that doesn't mean we can ask other people that need access to more tightly ACL-ed repositories to put up with subversion 1.5 and 1.6. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Fri, Apr 3, 2009 at 14:41, Jim Fulton j...@zope.com wrote: Should we all just use that? It's running trac 0.10. I'd love to see trac 0.11, which has additional features that I miss every time I use a 0.10 trac instance, such as the annotate view. Also, I'd include the subversion location plugin, which includes a link to the http:// or svn+ssh:// url for the currently viewed location, for easy checking out. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZF] Zope Source Code Repository
On Thu, Apr 2, 2009 at 20:31, Chris Withers ch...@simplistix.co.uk wrote: For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I volunteer to help with any/all of the above. My offer to set up Trac as a buildout still stands too. Jens, have your concerns about dependencies been answered? -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [ZF] Zope Source Code Repository
On Thu, Apr 2, 2009 at 20:39, Jim Fulton j...@zope.com wrote: On Apr 2, 2009, at 2:31 PM, Chris Withers wrote: For me, the ideal would be simply https for everything and using http basic auth for access with more people having access to update the passwd file and maybe Trac or WebSVN for a nice web interface. I absolutely *hate* using https to access subversion. This involves storing a key in plane text in my home directory, which is terrible. I far prefer using ssh-based infrastructure for this sort of thing. This is no longer the case for subversion 1.6 and up, the password is now stored encrypted, and subversion now supports KWallet, GNOME Keyring, Mac OS Keychain, and Windows CryptoAPI for storage. See: http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvements -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev nad...@gmail.com wrote:
I don't think they are, according to PEP 3107 they are stored in the
func_annotations attribute of the function.
No, they are stored in __annotations__. Look here:
http://docs.python.org/3.0/whatsnew/3.0.html#new-syntax
Also:
n...@seasaw:~$ python3
Python 3.0.1+ (r301:69556, Feb 24 2009, 13:51:44)
[GCC 4.3.3] on linux2
Type help, copyright, credits or license for more information.
def hello(who:'name') - None:
... print('Hello, {0}!'.format(who))
...
hello.__annotations__
{'who': 'name', 'return': None}
Interesting! Perhaps we should file a bug to have the PEP updated with
reality then. ;-)
Note that even if the name *where* the same, attribute annotations
only work on classes and instances, while function annotations only
apply to functions, not?
Good point. Looks like it is added automatically only for functions/methods.
:)
However, we can't be sure there won't be annotations for any callable
object, because even PEP says that ``we say function, we mean callable
object``, so one day we certainly will conflict with something. Also,
as Gary pointed out, we mis-use the __*__ name pattern that is now
intended for defining special names that have special meaning for
python interpreter. And we'll certainly will mis-use the
__annotations__ name as it's clearly defined in python 3k.
So, after Gary reminded about __*__ names, I think we shoud use
something like _z_annotations.
Semi-agreed. Tools that access ZODB objects and expect __annotations__
to follow the PEP 3107 conventions will be quite surprised. I doubt
that there will be many tools to do so though.
Then again, if Python is now explicitly claiming the __*__ naming
convention, Zope better avoid it's usage. This means we'll have to fix
__parent__ and __name__ usage as well. This will be painful, me
thinks..
--
Martijn Pieters
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 22:20, Dan Korostelev nad...@gmail.com wrote: As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things. But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict. I don't think they are, according to PEP 3107 they are stored in the func_annotations attribute of the function. Note that even if the name *where* the same, attribute annotations only work on classes and instances, while function annotations only apply to functions, not? -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
I find this thread quite ironic. Martijn Faassen recognizes a problem, namely that there is no direction in Zope development. Instead, when ideas are put forth lots of people put in their oar with +1s and -1s and stop energy and cheer leading one direction or another. In the end the ideas either get pushed through by determined contributors or (more often) they die. The irony is that the proposed solution, organized leadership, is going to suffer the same fate as the aforementioned ideas. Everyone is putting in their oar, +1s and -1s are flying right, left and centre, and this idea is either going to die, or Martijn will have to push it through and implement it. No one else seems enthusiastic enough to make this happen outright, there is no clear direction. So to me, the least this thread does is to prove that the flagged problem does exist. And so far I haven't heard any better ideas than what Martijn is proposing (no, leaving the status quo, deny there is a problem and steer by majority is not a counter proposal in my view). It may be that the idea needs some tweaking, but that's just details. Would it be possible to focus this discussion around clearer lines? Create counter proposals if you have to, discuss things on their merits, but if you cannot add more than a vague +1 and -1, please refrain. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Plans for Zope 2.12
On Sun, Jan 25, 2009 at 12:56, Dieter Maurer die...@handshake.de wrote: I plan to provide such a package as dm.ZClasses or (maybe) Zope2.ZClasses -- of course with some complaints against the Zope release management in the documentation: * cutting away useful features without any serious need * lacking commitment wrt backward compatibility * enforcing philosophical opinions (applications should be created programmatically not via configuration only (such as with ZClasses)) Oh, please come off it. You have checkin rights and could have stepped up to maintain the code. This is not about enforcing philosophical choices, this is about being pragmatic. If the feature was truely useful, more developers would be maintaining and fixing it. Obviously the complexity of keeping it working is outweighing it's usefulness. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 11:28, Malthe Borch mbo...@gmail.com wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. The C extension is required to make messageids immutable. Because they are immutable, the security machinery can treat them as rocks, e.g. safe to pass around. Removing the C-extension undoes this, as you cannot make truely immutable. See the original proposal: http://wiki.zope.org/zope3/TurningMessageIDsIntoRocks I'm sure Phillip and Jim can clarify the security implications of undoing this work. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 17:01, Jim Fulton j...@zope.com wrote: On Dec 12, 2008, at 6:28 AM, Malthe Borch wrote: I've branched out this package and removed the C-extension. It's not documented in the package why a C-extension is needed or alternatively, what it benefits. If there are no objections, I will merge this into trunk shortly. I object. Please drop it. I object as well, and have asked for Malthe to provide his reasoning here at the Plone Performance Sprint in Bristol, but so far his only motivation is that he wants to see if he can get this to work without a C-extension. I am sceptical he'll be able to, and am not convinced it'll be worth introducing risks. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] C-extension in zope.i18nmessageid
On Fri, Dec 12, 2008 at 18:51, Martijn Faassen faas...@startifact.com wrote: Unless it can be clearly demonstrated that the new method is equivalent in both performance and security, talk of dropping the C extension seems somewhat premature. A pure Python fallback for this module would however be interesting to everybody, I think. There is one already. However, it isn't immutable and thus a security risk. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Mon, Dec 8, 2008 at 18:37, Zvezdan Petkovic [EMAIL PROTECTED] wrote: On Mon, Dec 8, 2008 at 2:22 AM, Michael Howitz [EMAIL PROTECTED] wrote: Log message for revision 93766: color by default This setting apparently causes problems for people who use Emacs, so for zope. and zc. packages at least, we don't use --auto-color. That argument is really lame. Should we now go back to VT100 terminals because _some_ Emacs users are annoyed that ANSI colors break their shell window display? Is there no way auto-color can set as be a local default in a configuration file in your $HOME or something? Then everyone can make their own choices instead of having them made for them. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Failing Zope 2.8 / Python 2.3 tests on your box
On Fri, Aug 29, 2008 at 14:05, Stefan H. Holek [EMAIL PROTECTED] wrote: What I have found out now is that in my Python 2.3.6 encodings/ __init__.py does not contain 'import aliases' at module level, whereas the Python 2.4 lib has this import. The patch does this: import encodings encodings._aliases = encoding.aliases.aliases which does therefore not work in 2.3. So, now I am curious how your Python 2.3 differs, and why you don't see the error locally :-) The 1.1 version of the hotfix corrected this. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On Tue, May 20, 2008 at 3:39 PM, Christian Zagrodnick [EMAIL PROTECTED] wrote: If you determine beforehand which strings are translatable (end up as msgid objects) it should be trivial to extract these. You will have to update i18ndude to add new zcml tags though. What's translatable and what not is defined by the schema of the configuration which can be extended by any package. So adding this information to the extractor would duplicate it. Not good. But extracting that information may be prohibitively difficult and expensive to do. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On Sat, May 10, 2008 at 3:40 PM, Hanno Schlichting [EMAIL PROTECTED] wrote: Currently i18ndude doesn't extract any messages from ZCML. It is used for extraction of all messages for the Plone project which happens to use lots of ZCML. But none of the messages defined in ZCML are actually used in any user visible part of the whole application. So even if you are a Zope project, I think there's very good reasons not to require ZCML extraction. Although the ZMI may not count as a 'user visible' part, Generic Setup profile titles do show up there, which are defined in ZCML and should be translatable. Also, these days it is possible to register content views (such as the default view for a folder) through ZCML, using a menu directive for the title. Again these titles should be translatable. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept
On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: zcml is a pretty simple format though: xml with only human readable text in title and description attributes (and perhaps a few others) and the translation domain specified in a i18n_domain attribute. It should be quite trivial to extract that data without having to pull all of zope in. If you determine beforehand which strings are translatable (end up as msgid objects) it should be trivial to extract these. You will have to update i18ndude to add new zcml tags though. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Merge philikon-aq branch into Zope trunk
On Thu, Apr 17, 2008 at 12:27 PM, Hanno Schlichting [EMAIL PROTECTED] wrote: I would like to do the merge as soon as possible, so people can easily test it against all their applications and report back problems. Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. Opinions, votes? +sys.maxint! Thanks, Hanno, for carrying this to it's completion! -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] straighting out the SQLAlchemy integration mess
On Tue, Apr 8, 2008 at 11:54 PM, Martijn Faassen [EMAIL PROTECTED] wrote: All of these are in various states of brokenness. z3c.zalchemy doesn't work with SQLAlchemy trunk. collective.lead works with it, but only if you check out a particular branch, and not with sqlite. Quite possibly z3c.sqlalchemy has a release that actually works. One out of three is not bad... :) We are going into production with collective.lead and are committed to releasing the 1.0 branch as 1.0. sqlite works just great for us, we use it to run unit tests and for developers that just need to adjust the styling and such. The production environment will run against Oracle. There must be a reason for this proliferation of approaches. What is it? We all get along, don't we? I know that the various packages are taking code and approaches from each other too. Different use-cases and philosophies of development. In the end, I hope we will end up with just *one* integration layer, that is released, that works with Zope 2 and Zope 3 and a recent release of SQLAlchemy, that is documented, and that people know about. We can then offer packages on top of this that offer extra features. Sounds like a good idea. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Non-ASCII characters in URLs
On Mon, Apr 7, 2008 at 1:37 AM, Alexander Limi [EMAIL PROTECTED] wrote: Is there a good technical explanation for why Zope doesn't allow non-ASCII characters in URLs? Because URLs don't allow non-ASCII characters? I'd like to be able to let URLs work like this example from Wikipedia: http://ja.wikipedia.org/wiki/メインページ Your browser translates that into http://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 Is there a fundamental reason (ie. Python objects can only be ASCII) or is it simply bugs that need to be fixed? RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) doesn't allow non-ascii characters in URLs. No corresponding graphic US-ASCII: URLs are written only with the graphic printable characters of the US-ASCII coded character set. The octets 80-FF hexadecimal are not used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent control characters; these must be encoded. Now, Zope could well support UTF-8 ids, and translate URLs appropriately, but in the meantime you could use the same scheme? -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sendmail Retry fixes and new state machine.
On Mon, Mar 10, 2008 at 6:09 PM, Wichert Akkerman [EMAIL PROTECTED] wrote: The fact that something is popular does not necessarily mean it is the right thing :) Lack of isolation is a very convincing argument to me. Perhaps more personal taste but I also find python unittests to be much more readable. You don't suffer from mixing lots of test setup/teardown being repeated through the file. As Tres mentioned this is especially true when testing corner cases. Being able to debug tests by stepping over them with pdb is incredibly useful. With doctests that doesn't work. Being able to run a single test easily allows for quick testing and debugging. I can't tell the testrunner 'start running at line 52 but also include all the test setup magic from before, but skip the rest'. With unittests I can simple run zopectl test -s module -t test function. doctests hurt my productivity badly. I completely agree with Tres' and Wichert's statements on this. I only use doctests where they actually would make sense as documentation, the corner cases I always write as unit tests. The tools for dealing with pure Python code are so much more powerful than for python-embedded-in-text-with-prefixes, as well. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Additional locales for zope.i18n.locales.data?
On Nov 28, 2007 12:29 AM, Nathan Yergler [EMAIL PROTECTED] wrote: If you follow the wink, http://www.unicode.org/cldr/repository_access.html has the details to the files. Currently the latest is at http://unicode.org/Public/cldr/1.5.0/core.zip. Zope at this point still uses LDML 1.0 whereas the latest version is LDML 1.5. Upon casual inspection of the files it seems their basic structure is still the same, though more careful inspection is required. I've been avoiding even less interesting work this afternoon, taking a look at this. I started by dumping the new files into the data directory and just running the tests. As expected, things blew up in a really spectacular manner. After some wrangling I've discovered that in the newer versions of the CLDR dataset some of the information previously contained in the locale files (such as weekend start/end, etc), is now in located in a supplemental file. While this makes a certain amount of sense (it's tied to territories, not really languages), it does mean that the information needed for a Locale is no longer self-contained in a single XML file. So unfortunately it's going to require some more work to fix up the loader; I'll probably create a branch to work on this some... Has anyone looked at Babel (http://babel.edgewall.org/)? It includes a python interface to CLDR, which if usable would let us off the hook of maintaining such an interface ourselves. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher returns 200 Ok instead of 200 OK
On Nov 13, 2007 9:33 PM, Martijn Faassen [EMAIL PROTECTED] wrote: In zope.publisher.http, the status string for 200 is defined to be 'Ok', instead of 'OK', which is in the HTTP spec. Now status messages may, according to the spec, be replaced by 'local equivalents' without affecting the protocol, and the status messages in the spec are just examples. Still, it's a difference without a good reason. Changing this to 'OK' has some impact: particularly tests which verify the status string (which I'm currently writing) will break. Then again, thats' an easy fix. What do people think? Should this be fixed? This came up before in a bug report on Launchpad, and it was decided that to change this would break too much code relying on the spelling of the response. Such code would be wrong, but there was not enough reason to break things. See https://bugs.launchpad.net/zope3/+bug/112109 -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Interface.__identifier__
zope.inferface.interface.InterfaceClass.__init__ defines a nice attribute self.__identifier__ that stores self.__module__ + '.' + self.__name__, which is very handy when indexing and searching interfaces in Plone. However, unlike __module__, __identifier__ is not part of the IInterface declaration. Should it be added there to lift this attribute above implementation detail status? It can then also be used in zope.component.interface where it could replace the various usages of __module__ + '.' + __name__. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Moving the Zope 2 bugtracker to Launchpad
On 8/12/07, Andreas Jung [EMAIL PROTECTED] wrote: to make it short: I propose to move the Zope 2 bugtracker to Launchpad. Since the Zope 3 bugtracker works already with success on LP we should follow with the Zope 2 bugtracker. Objections? +1 I do wish LP gave a bit more context in their emails though; today Christian Thuene cleaned up the Z3 bugtracker and I couldn't tell from any of the many bug emails if any related to bugs I cared about. I'll have to file a LP feature-request, I guess. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Views on catalog results
On 3/12/07, Martijn Pieters [EMAIL PROTECTED] wrote: - Create an ICatalogResult interface and use a five:implements directive to configure ZCatalog.CatalogBrains.AbstractCatalogBrain as implementing it. [...] I'd like to add this to Zope trunk, with Traversable a base class for AbstractCatalogBrain and a implements(ICatalogResult) on that same class. Checked in on the trunk. Of course, Five.Traversable is no longer needed on the trunk (*slaps forehead*). -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Retracting Zope 2.9.7, Zope 2.10.3 releases because of a zopectl start problem
On 3/26/07, Damien Baty [EMAIL PROTECTED] wrote: manage_restart(self, URL1, REQUEST=None): makes Zope start. 'REQUEST' is not used in this method, though. However, it is also not used in 'manage_shutdown()' but appears in its signature. I guess that adding it to 'manager_restart()' should not have any side-effect. @postonly uses the REQUEST parameter, that's why it demands the parameter being present. Tres Seaver added the decorators to the Control_Panel and must've missed the REQUEST parameter on manage_restart, which only comes into effect when running the zope process with zopectl start. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Retracting Zope 2.9.7, Zope 2.10.3 releases because of a zopectl start problem
On 3/26/07, Martijn Pieters [EMAIL PROTECTED] wrote: Tres Seaver added the decorators to the Control_Panel and must've missed the REQUEST parameter on manage_restart, which only comes into effect when running the zope process with zopectl start. Fixed on the trunk, and the 2.8, 2.9 and 2.10 branches, my servers start fine with zopectl start. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Retracting Zope 2.9.7, Zope 2.10.3 releases because of a zopectl start problem
On 3/26/07, Andreas Jung [EMAIL PROTECTED] wrote: The penalty for this bug: two bottles of wine. You know where to send the bill. ;) The workaround is to add REQUEST as optional parameter to manage_restart()? No, it's 'svn up' now, as I fixed it already. :) -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: Zope/branches/Zope-2_8-branch/ - Backport a postonly decorator from Zope trunk's requestmethod decorator factory.
On 3/21/07, Stefan H. Holek [EMAIL PROTECTED] wrote: Python 2.3 does not support the @decorator syntax. My bad, I'll fix. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Checkins] SVN: Zope/branches/Zope-2_8-branch/ - Backport a postonly decorator from Zope trunk's requestmethod decorator factory.
On 3/21/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Done. I hadn't even properly run the tests on the 2.8 branch, which would would also have shown that doctest on py 2.3 doesn't have any unittest integration. But there's zope.testing.doctest which fixes that. It's a drop-in replacement for the doctest module (in fact, it's the one from Python 2.4). You probably want to use that instead of deleting the test case ;). W00t! Didn't know about that one, thanks! Test re-instated. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Cannot run zopectl fg on Zope trunk
currently after a make clean; make inplace; make instance -d $INSTANCE_HOME; cd $INSTANCE_HOME, zopectl fg fails with: $ bin/zopectl fg Traceback (most recent call last): File /Users/mj/Development/SVN/Zope/lib/python/Zope2/Startup/zopectl.py, line 322, in ? main() File /Users/mj/Development/SVN/Zope/lib/python/Zope2/Startup/zopectl.py, line 281, in main c = ZopeCmd(options) File /Users/mj/Development/SVN/Zope/lib/python/zdaemon/zdctl.py, line 141, in __init__ for k, v in options.configroot.environment.mapping.items(): AttributeError: 'dict' object has no attribute 'mapping' -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Cannot run zopectl fg on Zope trunk
On 3/17/07, Andreas Jung [EMAIL PROTECTED] wrote: currently after a make clean; make inplace; make instance -d $INSTANCE_HOME; cd $INSTANCE_HOME, zopectl fg fails with: works for me. Looks like make clean is not complete; after a fresh checkout and build, Zope now starts just fine. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Google Summer of Code
On 3/14/07, Baiju M [EMAIL PROTECTED] wrote: I think you added (by mistake?) this link instead: http://pyre.third-bit.com/blog/archives/863.html Whoops, indeed, that's not the right one. Blame late night inattention, brought on by a better half asking when I was going to be done. ;) I found this one also useful: http://primates.ximian.com/~federico/docs/summer-of-code-mentoring-howto/index.html That's the correct link! Corrected on the Wiki. :) Thanks! -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Google Summer of Code
On 3/5/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Great. I've added you to http://wiki.zope.org/zope3/SummerOfCode2007. If you happen to have any project suggestions, feel free to add them to the list. Not a project suggestion, but relevant nonetheless: an excellent GSoC mentoring How-To: http://plone.org/products/plone/releases/SoC-2007 I added it to the Wiki page. It should be mandatory reading for any potential mentor! -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Views on catalog results
Hi all, This weekend I had fun with creating views for catalog results. In order to do this, I had to: - Create an ICatalogResult interface and use a five:implements directive to configure ZCatalog.CatalogBrains.AbstractCatalogBrain as implementing it. - Set Five.traversable.Traversable as a mixin brain for catalog results (Catalog.useBrains). With these changes, I could a) define views for catalog result objects, and b) traverse over them in a template to obtain the view. I'd like to add this to Zope trunk, with Traversable a base class for AbstractCatalogBrain and a implements(ICatalogResult) on that same class. The obvious advantage of the latter is that one doesn't need to use Catalog.useBrains any more to add functionality to result objects (just use adapters). The first change is a necessity if you want to be able to look up views on results through traversal (in a template for example). I'd like to have some feedback on this idea before I do this however, just to make sure that using Traversable here is a good idea or not. For the curious, my usecase involved creating workflow menus (a lá Plone) for a page showing up to 100s of content objects, all AJAX driven. This enables you to quickly workflow several related objects without waking up all the content objects just to see their available workflow transitions. The workflow actions menu is a view defined for both content objects and catalog results, with the view also supporting invoking the transition. There are different view classes for content objects and catalog results, but the template for the view is the same for both cases. The catalog result view looks up transitions by hacking up action information objects, and the only limitation is that transition guards can not use permission or roles guards (no meaningful context to look up on) and guard expressions need to be written taking into account that the context is either a real content object or a catalog result. These limitations were not a problem for the workflows involved. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Google Summer of Code
On 3/5/07, Martijn Pieters [EMAIL PROTECTED] wrote: On 3/5/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Great. I've added you to http://wiki.zope.org/zope3/SummerOfCode2007. If you happen to have any project suggestions, feel free to add them to the list. I've added myself to the mentors list as well. Google will need your Google account, so I've added mine to the Wiki. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Google Summer of Code
On 3/5/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Great. I've added you to http://wiki.zope.org/zope3/SummerOfCode2007. If you happen to have any project suggestions, feel free to add them to the list. I've added myself to the mentors list as well. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] version.txt magic
On 11/25/06, Christian Steinhauer [EMAIL PROTECTED] wrote: As i see you fixed it. Can you give me a description how to fix it or have you done a thread into an bugtracker? http://svn.zope.org/Zope/branches/2.10/inst/Makefile.win.in?rev=71283view=rev -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] App.Product - distribution related code?
On 3/14/06, Andreas Jung [EMAIL PROTECTED] wrote: lib/python/App/Product.py contains code that deals *somehow* with distributions (whatever this means). Does any one know what this code is doing?...anyway this code uses the Python rotor module which was removed in Python 2.4. This code is a clear candidate to be kicked... objections? No objections. With it you could package ZClass-based Products up for redistribution; the redstributed version could then be installed like a regular product, complete with locked code... -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: http access to svn repos?
On 3/8/06, Jim Fulton [EMAIL PROTECTED] wrote: OK, for those not familiar with svn/HTTP authentication, as I understand it you have to authenticate for each session and your credentials are cached in clear text in your home directory. The storage of clear-text credentials is obviously lame, as is the necessity to provide then for each svn session. Client certificates are the SSL equivalent of ssh keys and can, like keys, be protected by a passphrase. Without some form of passphrase-caching agent, you'd have to re-enter your passphrase every time too though, or (*shudder*) put your passphrase into the .subversion/servers config file, and you are back to square one. -- Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Z SQL Caching
Dale Hirt wrote: I have a Z SQL method that is currently returning around 25000 rows. Is there a way to see if it is pulling that data from the cache or is doing a refresh? Alternatively, and maybe this will answer the first question, the Z SQL method is run essentially twice, each time with different parameters. Does it cache each instance, or does it cache the first, then when it's run again with different parameters, kill the cache and re-run everything? A ZSQLMethod cache (if configured with a cache duration greater than 0) is keyed on the rendered SQL. So, if different parameters lead to a different SQL query to be sent to the database, then a different key is used. Caches are kept for the duration of the configured cache duration, and a given cache key will not influence earlier caches of different keys. The SQL is taken quite literally here. If you use the following template: SELECT * FROM foo WHERE dtml-sqltest bar type=nb Then different values for 'bar' will result in different SQL queries and thus different cache keys. If the same method is called with the same value for 'bar' within the cache duration, an earlier cached result will be returned instead of querying the database. Another value for 'bar' in between those calls will not kill the cache. Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Speed win in Python's urllib.quote
Lennart Regebro wrote: How about: http://public-bertha.in.nuxeo.com/~ben/funkload/ Is this site ment to be public? The name doesn't resolve for me. Is the head from http://svn.nuxeo.org/trac/pub/browser/funkload/ sufficient? Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Speed win in Python's urllib.quote
Martijn Pieters wrote: Is this site ment to be public? The name doesn't resolve for me. Is the head from http://svn.nuxeo.org/trac/pub/browser/funkload/ sufficient? Reply to self: in the zope3 list the answer to the above question has been found; it was Yes. Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: indexing multiple strings with ZCTextIndex broken in Zope 2.7.7
Martijn Faassen wrote: Can you reopen the issue? I've tried to log in to see whether I can, but it don't seem to log in properly into the tracker or something. Zope.org appears to cache collector issues very aggressively; use the 'View' action on the top right to get to a fresher version. A bug I responded to this afternoon still shows up in it's originally filed state on the default URL (ending in the issue number) Martijn Pieters ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] BTrees.Length conflict resolution
Did the conflict resolution code for BTrees.Length ever work? Because as it stands now the code will fail as it assumes that integers are passed in, instead of state dictionaries: def _p_resolveConflict(self, old, s1, s2): return s1 + s2 - old As there are no tests for this that I can see (the BTrees tests are kinda very dense), I am not too keen to go touch this, but I think this should read: def _p_resolveConflict(self, old, s1, s2): s1['value'] += s2['value'] - old['value'] return s1 Martijn Pieters, up to his armpits in conflict resolution code. signature.asc Description: OpenPGP digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: BTrees.Length conflict resolution
Tim Peters wrote: You haven't seen this fail, you're _deducing_ that it must fail, right? Deducing indeed... Don't overlook this other Length method: def __getstate__(self): return self.value That is, when a Length instance is asked for its state, it returns an integer. Similarly setting its state expects an integer: def __setstate__(self, v): self.value = v Dang. I knew I was missing something here. Thanks for putting me straight, Tim. Martijn, who has managed to extract himself from conflict resolution code today. signature.asc Description: OpenPGP digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] xmlrpc to zope change?
On Tue, Aug 05, 2003 at 01:52:21PM -0500, Christopher N. Deckard wrote: After doing some testing with Zope 2.6.2b5, we discovered that a number of our scripts that do xmlrpc to Zope were not working. It turns out that the URI to use to connect to Zope will not work if you have /RPC2/ as was required before. Should I file a collector item on this? /RPC2/ was never requered before; that URI is a convention used by Frontier (the first server to implement XML-RPC) and possibly other XML-RPC implementations, but never by Zope. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Mailinglists
On Mon, Aug 04, 2003 at 09:17:37AM +0200, Christian Theune wrote: something went wrong on all zope.org mailinglists recently. I discovered that the sender adresses aren't zope.org anymoure but python.org. This crashes my mailinglist filters as they are using the List-Id field that isn't supposed to change. Is this temporarily due to zope.org update or will it remain in this state? A temproary glitch. Barry Warsaw switched the majority of lists at python.org and zope.org over to a new version of Mailman and the sender domain name for the Zope.org lists got reset to python.org. I fixed all lists this morning. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.python.org/mailman/listinfo/zope-announce http://mail.python.org/mailman/listinfo/zope )
Re: [Zope-dev] Mailinglists
On Mon, Aug 04, 2003 at 02:22:26AM -0700, Jamie Heilman wrote: dunno anything about it, but I just thought I'd note that whatever happened it seems to have disappeared a good number of the list archives formerly hosted at http://mail.zope.org/ as well irritating The web listing of mailing lists still uses the old mailman version (see my reply to the original message). This will be switched over in due time showing the full list again. Sorry about the inconvenience. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.python.org/mailman/listinfo/zope-announce http://mail.python.org/mailman/listinfo/zope )
Re: [Zope-dev] Mailinglists
On Mon, Aug 04, 2003 at 04:28:29PM +0200, Jean Jordaan wrote: I fixed all lists this morning. Dunno if this is related, but they're still AWOL from http://mail.zope.org/mailman/listinfo .. (only shows 6 lists now). That is indeed related. The page only shows lists still running on the old mailman version. These lists will be migrated as well, and the page will be switched to show the new mailman version lists list (try saying that 20 times fast). -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.python.org/mailman/listinfo/zope-announce http://mail.python.org/mailman/listinfo/zope )
Re: [Zope-dev] weak examples, weak exploits
On Mon, Jun 23, 2003 at 10:33:42AM -0400, Casey Duncan wrote: I would be in favor of making the Examples opt-in like the Zope tutorial. It seems silly to have it in evey ZODB by default. Make people add it if they want it. Moreover, the examples installed everywhere attract spam to [EMAIL PROTECTED] (forwarded to [EMAIL PROTECTED]). I have seen numerous 'increase website traffic' spams explicitly mentioning /Examples URLs around the net. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How (in)secure is Zope?
On Thu, Mar 13, 2003 at 06:11:32PM +0100, Florent Guillaume wrote: In article [EMAIL PROTECTED] you write: - Cross-scripting issues: I guess that some of those are still in the Zope Management Interface (which is not meant to be used by untrusted users in most cases), but Zope offers a lot of tools to make sure that it is hard to post malicious code in forums, attack Zope via URLs etc. I've worked had to remove all those in the DTML code. I've not audited the rest of the python code that generates HTML directly (code that should be taken out and shot), but I think there are patches for those in the collector. And Florent's patches came on top of my DTML pro-active anti-HTML-from- REQUEST-sourced-data changes that cause all outside strings to be HTML quoted if they could *possibly* be used to construct HTML tags. Some of my changes included taking out some of the directly-HTML-generating python code to be shot without trial. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope anonymous CVS temporarily offline
Hi all, Due to the CVS vulnerabilities disclosed today, we have temporarily shut down anonymous CVS access to cvs.zope.org through pserver. We'll reenable this when we have upgraded CVS on the server. People with write access through SSH and the web interface at http://cvs.zope.org are still available. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] cvs.zope.org broken
On Wed, Dec 18, 2002 at 11:57:33AM +0100, Godefroid Chapelle wrote: Does someone knows what happens with cvs.zope.org which is currently broken My bad, typical Murphy's Law where a last-minute cosmetic change breaks everything and a browser cache prevented me from seeing my mistake. All late at night of course. Mea Culpa! -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] cvs.zope.org upgraded
cvs.zope.org now runs on ViewCVS 0.9.2, and I enabled CVSGraph (watch out, big images!) and database query support. Head on over and play around with the new look and features! -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: online ordering without a prescription
Sorry for the spam that snuck through; we had memory problems on the mail server and the spam handling facilities were temporarily off-line. -- Martijn Pieters | Software Engineer mailto:mj;zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Unsecure design of ExternalFile
On Thu, Nov 07, 2002 at 11:24:35AM -0500, Craeg K Strong wrote: What would you recommend? Perhaps there should be a predefined list of forbidden directories for ExternalFiles? The problem is that-- in the development scenario-- the very things you mention below might be what you legitimately *want* to do as a developer. 'Jail' the base directory. Files can only be referenced within the jail. Relative paths outside the jail are forbidden. This is what FTP and web servers do, and so should ExternalFiles. A full path (starting with a '/') then starts at the base directory. The base directory should not be configurable through the web. Rather, use an environment variable. Only one directory is needed, as files that need to be accessible can be copied or symlinked. -- Martijn Pieters | Software Engineer mailto:mj;zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: pdf - Files not viewable
On Mon, Aug 19, 2002 at 10:17:00AM +0200, Markus Stoll wrote: The acrobat plugin is definitely unhappy with these sorted ranges that Zope uses for creating the response. Acrobat expects the ranges in the very same order it has requested them. Sorry, further reading on my part. What Acrobat reader version, Browser version and Zope version? *Not* sorting the ranges causes considerable performance loss on the Zope server. I have tested Acrobat reader version 5 on Mozilla (0.9 and up), Netscape 4.7 and Internet Explorer 5.5 and up with this and all combinations work with the current code. There was a bug in the way ranges that touch upon each other (no overlap, just no seam) were optimized away, and the way Netscape 4.7 uses a draft version of the spec instead of the released version. These have been fixed. As the spec does not prohibit sorting, and perfomance loss is fenomenal on large files, I would need considerable justification for not using sorted ranges. If you use Zope 2.4, then you are probably experiencing one of the above mentioned bugs. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Wed, Aug 14, 2002 at 04:25:09PM -0400, Brian Lloyd wrote: So here's what we'll do. Zope 2.6 will include the string tainting changes, enabled by default. The tainting can be turned off by providing an environment variable. The next Zope 2.5.x release will contain the tainting code, but it will be *disabled* by default. If you are worried about the issues it addresses, you will be able to enable it explicitly using an environment variable (without having to upgrade to 2.6). I checked in the changes for 2.5; auto quoating now has to be enabled with an environment variable. Higly recommended! -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Mon, Aug 12, 2002 at 03:51:24PM +0100, Toby Dickenson wrote:
On Friday 09 Aug 2002 4:33 pm, Tres Seaver wrote:
Whithout the fix, virtually every Zope site in the world is vulnerable
to URL-based cross-site scripting exploits. For instance, any URL which
contains invalid form variable marshalling can generate an error page
which includes the erroneous value, unquoted. E.g.:
URL:http://somezopesite.com/looks/like/legitimate?foo:int=%3Cscript%3Ealer
t('Owned')%3C/script%3E
Do you plan to fix this bug?
Or, with the autoquoting changes, is this to be reclassified as 'not a bug'?
Together with the autoquoting changes, I tightened Exception messages; data
from REQUEST is quoted where I could reasonably suspect REQUEST data was
used.
--
Martijn Pieters
| Software Engineer mailto:[EMAIL PROTECTED]
| Zope Corporation http://www.zope.com/
| Creators of Zope http://www.zope.org/
-
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Fri, Aug 09, 2002 at 09:56:45AM +0100, Toby Dickenson wrote: The risk for breakage is very small really Your choice of '' and html_quote suggests that my dtml code which generates javascript and vbscript carries a higher risk than dtml which generates html. Only if you generated that script using data from the REQUEST, implicitly. Which was bad in the first place. , and breakage will generally only occur when someone is trying to exploit the weakness, not in normal operation of the site. The fact that your change uses html_quote to 'fix' the problem rather than sounding 'hacker alert' alarm bells suggests to me that you dont really believe that ;-) Again, the wide scope of DTML use would make such bells warble prematurely all too often. The normal, recommended fix for the general weakness is to always use HTML quote. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Thu, Aug 08, 2002 at 08:19:12PM +0100, Toby Dickenson wrote: I am about to land some big changes in the way DTML deals with data taken from the REQUEST object when accessed implicitly, in both the Zope Trunk and the Zope 2.5 branch. In my opinion this change is completely unacceptable at this late stage of the release cycle. As you said: These changes could potentially break existing Zope sites. The existing behavior might be flawed, but it is a flaw we have all lived with for a long time. In my opinion this needs: 1. To be deferred until the 2.7 cycle. 2. A detailed fishbowl proposal. Note that the problems fixed are potential security problems. Although we cannot fix every site out there for sure, the fixes certainly dramatically reduce the risks. The risk for breakage is very small really, and breakage will generally only occur when someone is trying to exploit the weakness, not in normal operation of the site. I'll leave any decisions on wether or not this stays in the current release cycles or moves to 2.7 to Jim Fulton. He is unfortunately on cvacation until next week. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checked in
On Fri, Aug 02, 2002 at 08:55:13AM -0700, Andy McKay wrote: Likewise Im trying to digest all that and Im a little suprised. More magic in DTML? Not something I'd vote for normally. Im a little confused why this is suddenly an issue, yeah so we pull a string out of the REQUEST and thanks to DTML stack we may not know where it came from. Well thats always been there. And yeah the string may contain nasty HTML. Again that's always been there. In the past (and I cant find posts to show it) the party line was Zope is an application server and its up to the person developing the application to worry about it. Thats why ChrisW wrote stripogram and I use it in quite a few apps. Yup. And that is still the case. However, the combination of implict REQUEST form interpolation and no HTML quoting turns out to especially dangerous, because of those situations where you *want* no HTML quoting for optional information that normally should *not* come from the REQUEST. An example is the Zope help system; there are API help pages that have optional information, which when present is already HTML. But when not present in the object hierarchy, but it *is* available in the REQUEST, the REQUEST data is used instead. The way standard_error_message deals with exceptions is another such a situation. The DTML author didn't expect the particular template slot to be filled with REQUEST data, the slot is optional, and the author has no way of preventing REQUEST data from being used. The solution we choose fixes that problem, for all existing DTML as well as future DTML. Note that ZPT does not have this problem, as it quotes by default and doesn't use implict namespaces. One other question? Why does it matter that the string is implicitly called, why dont you taint explicitly called to? It makes me think of Perl where taint mode taints anything coming from the user? Because, as explained above, its the implicit case that is dangerous. In the explicit case you are supposed to know you are working with unsafe data and thus the old rules apply. If we explicitly quoted, we hurt everyone that either did the right thing from the start and/or already knows they are playing with fire. This still doesnt solve the party line and means I would like to suggest again (and this time I have the time to work on it) that we add something like stripogram or similar to the core, so that is easy for an application developer to have access to strip html and other functions from products, DTML, Python Scripts etc to easily alter, manage and make HTML safer. The CMF now includes a basic HTML stripper. In future iterations, Tres Seaver expects this to evolve into a CMF Tool that is more generaly configurable and useable. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] DTML and REQUEST data changes about to be checked in
Hi folks,
I am about to land some big changes in the way DTML deals with data taken
from the REQUEST object when accessed implicitly, in both the Zope Trunk
and the Zope 2.5 branch. These changes could potentially break existing
Zope sites.
Without these changes, Zope is somewhat vulnerable to cross-scripting
attacks, where a well-crafted URL can cause a Zope server to serve out
arbitrary HTML. Because DTML does not automatically html quote any data,
and can implicitly get information out of the REQUEST even when it was not
the intention of the template author, it is easy to cause REQUEST data to
be rendered as HTML on a page.
My changes cause the REQUEST to keep track of suspected strings, where
suspect is defined as any string with a ''. These are marked as tainted.
Any normal, explicit access to the REQUEST will still give you normal
values. However, as soon as a DTML template requests a variable from the
general namespace, and this variable is then satisfied from the REQUEST,
the value of this variable could potentially be a TaintedString object
instead of the original string. When rendering such a value, DTML will
automatically HTML quote it if not already done so explicitly. All DTML
string operations dealing with TaintedString objects are careful to retain
the TaintedString status.
I also fixed all exceptions raised in Zope that I could find, where
untrusted REQUEST data was used in the exception message; these exceptions
now html quote the data. I also made sure that the REQUEST calculated
variables URLx and BASEx and such were not shadowed by untrusted form
variables of the same name.
These changes can break existing sites in the following ways:
- If you relied on getting HTML-like data from the REQUEST in DTML and
want to render this as HTML, and you got this data implicitly, this data
will now be HTML quoted. Note that you were vulnerable to a
cross-scripting attack here already.
You can retrieve your information from the REQUEST directly (with
dtml-with REQUEST for example), at your own risk. ;)
- HTML quoting will also take place in templates that do not otherwise
generate HTML to be sent back to the browser, such as email forms and Z
SQL Methods. For Z SQL Methods, dtml-sqlvar does not quote
TaintedStrings and is otherwise ignorant of them. For emails, use
explicit access to REQUEST instead.
- If you relied on being able to override URLx or BASEx variables through
a form variable, this no longer works. Use explicit access to
REQUEST.form instead.
- Using the string method .join (''join(items)) cannot handle
TaintedString objects. You can use _.string.join instead.
- Passing a TaintedString value from a DTML template to other objects such
as Python code, External Methods, Python Scripts, etc, may cause them to
break because they did not anticipate a TaintedString object.
What doesn't break (among others):
- Accessing REQUEST data from Python code, Python scripts, or ZPT. Only
DocumentTemplate.DT_String derivatives (DTML Document, DTML Method, etc)
and DTMLFile objects are affected.
- If you already HTML quoted, nothing gets double quoted.
- Using the _.string module in DTML retains taints.
- Zope 2.6 unicode marshalling (var:ustring:utf8) works with
TaintedStrings as well.
TaintedString objects try to mimic strings as best as they can, but until
we move to python 2.2 definitely and we can inherit from str directly,
certain python code will not accept TaintedString objects as substitutes.
I found that the normal string module, and the string ''.join module don't
accept TaintedString objects for example.
Also, using the string interpolation operator % will cause TaintedString
objects to be unwrapped. When TaintedString becomes a subclass of str,
more operations will unwrap them, such as unicode() and ''.join; or just
about any operation that manipulates strings through other ways than
string methods.
Because of size of the change and the impact on existing DTML code, well
release betas of Zope 2.5 and 2.6 soon to facilitate wider testing. For
those following CVS, please test the changes rigorously and let me know what
you find.
--
Martijn Pieters
| Software Engineer mailto:[EMAIL PROTECTED]
| Zope Corporation http://www.zope.com/
| Creators of Zope http://www.zope.org/
-
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: DTML and REQUEST data changes about to be checked in
On Thu, Aug 01, 2002 at 10:46:44AM -0400, Martijn Pieters wrote: I am about to land some big changes in the way DTML deals with data taken from the REQUEST object when accessed implicitly, in both the Zope Trunk and the Zope 2.5 branch. These changes could potentially break existing Zope sites. It's in. Let the testing begin! -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: DTML and REQUEST data changes about to be checked in
On Thu, Aug 01, 2002 at 10:29:36AM -0600, Jeffrey P Shell wrote: Hopefully I'll get a chance to test it with some of our 2.5 sites - I have a small worry that old code on small sites that we don't have much worry about will break if this is put into a 2.5.2 or later release. Could there be a way to disable this feature in 2.5 via a z2/environment variable or some other configuration setting, but have it be automatic in 2.6? Potential code breakage and point point release leave me a little worried about maintaining 2.5 sites. It may not be an issue - I have to digest the changes in more depth that I've had (or currently have) time for, but that's the thought that crossed my mind earlier. From a technical standpoint I can indeed add a switch that would disable the occurence of tainted strings, yes. I'll discuss this with Brian, it shouldn't be hard to add. But note that breakage only occurs when REQUEST data actually contains possibly dangerous markup, and your site was vulnerable in those areas that now break. Disabeling the tainting will leave you vulnerable. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ?determine if x is a string or array in PythonScript
On Thu, Jul 11, 2002 at 05:22:48PM +0800, Tim Hoffman wrote: I must be stupid or something, but I can't for the life of me work out a simple way of determining if a variable contains a string or array, in a PythonScript in Zope. I can't import type and or use type() function. isinstance doesn't work because I can't give a type as the second arg. I obviously just can't see the wood for the trees, can anyone help out this silly individual ? Testing for string methods works :) if hasattr(item, 'startswith'): # A String else: # Something else On a similar note you can test for a specific list method. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ?determine if x is a string or array in PythonScript
On Thu, Jul 11, 2002 at 04:10:33PM -0400, Shane Hathaway wrote: Python scripts provide a special function, same_type(), for this purpose. Example: if same_type(s, ''): s = [s] Much better than my hacked-up solution. :p -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [OT] digital signature
On Thu, Apr 25, 2002 at 06:02:19PM +0200, Lennart Regebro wrote: I want a *good* mail program. :-/ I can recommend Mutt. ;) -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope] isecure XML-RPC handling.
On Tue, Apr 02, 2002 at 04:01:41PM -0500, Eron Lloyd wrote: On that thought, I'd like to see Zope.org become much more modern, and reflect the *latest* and *greatest* functionality of Zope. Deprecation of the hybrid PTK that's used, as well as updating and polishing of the site regularly. In fact, I'd like to see more of a portal feel to it, that's both personalized and customized to my needs. For instance, log into my account, download 2.5.1b1, come back a week later and here's a big notice that beta2 is available for *my* setup. Also, can we see some Web services? Imagine, in the management interface, and visiting the Control Panel. There is an Update tab, which when loaded queries zope.org with the XML-RPC method zope.webservices.getUpdates(my_install), which passes in my server's version, installed products, etc. and lists updates, hotfixes, and other notices. With the flexibility and dynamic runtime nature of Python, i wonder how hard it would be to update a running server. Head over to [EMAIL PROTECTED] and help out then; the effort to build a new zope.org is already well under way. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Interfaces
On Tue, Jan 29, 2002 at 07:47:46PM +, Florent Guillaume wrote: When I define an Interface, are the methods of the interface supposed to have self as the first argument? No. But this does preclude automatic validation of the contract using python inheritance from the Interface, doesn't it ? Or will there be another way ? No, the validation methods take into account that class members of an implementation will have a self-referential first argument. Detecting if an implementation is a class is trivial. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [BUG] Python 2.1.2 Zope 2.4.1
On Mon, Jan 28, 2002 at 10:32:11AM -0500, Paul Everitt wrote: All in all, only a few days separate the two releases, and obviously CVS people have been able to get at changes all along. Thus, I don't think this is an extreme case. Also note that downloading a source release from CVS is very very very easy. Just use the following link: http://cvs.zope.org/Zope/Zope.tar.gz?tarball=1only_with_tag=Zope-2_4-branch This will get you a tarball with a CVS export of the current 2.4.x branch, which will contain *exactly* the same contents as the Ssource release we'll make as soon as the windows problem is resolved. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PDF-specific Bug in the ZServer implementation??? Or just strange behavoiur of IE?
On Mon, Jan 07, 2002 at 09:56:40PM +0100, Joachim Werner wrote: This was a really quick response! Thanks a lot. Just one additional question: What is the best approach to upgrading to the new code? Replacing the ZServer code by the CVS one? Is the patch in the latest 2.5 beta, too? Yes, the changes are in 2.5.0b3 as well (check the CHANGES.txt file when in doubt :)). -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
