September 2008 - Zope-Dev

Zope Tests: 2 OK, 3 Failed
by Zope Tests Summarizer 25 Sep '08

25 Sep '08

Summary of messages to the zope-tests list. Period Wed Sep 24 11:00:00 2008 UTC to Thu Sep 25 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 24 20:54:45 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010217.html Subject: FAILED (failures=1) : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 24 20:56:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010218.html Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 24 20:57:45 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010219.html Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Sep 24 20:51:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010215.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Sep 24 20:53:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010216.html

1 0

SimpleComponentTraverser flaw
by Dan Korostelev 24 Sep '08

24 Sep '08

I think that topic was raised before, but I can't find any information about what's going to be done on that :) The zope.app.publication.traversers.SimpleComponent (that's used by default for most of objects) in its publishTraverse method uses the adapter lookup without asking for some specific view interface (like IBrowserView), like this: view = queryMultiAdapter((ob, request), name=name) This causes problems when we have any non-view context/request adapters registered. One real-life example of that kind of adapter is ILayoutTemplate adapter registered with z3c:layout directive from z3c.template package. So the publisher that looks for views should look them up like this: view = queryMultiAdapter((ob, request), IBrowserView, name=name) One issue is that SimpleComponentTraverser also provides IXMLRPCPublisher and (as far as I understood) should be able to look up IXMLRPCView adapters. I'm asking about how to fix this without breaking much backward-compatibility. Should we just write split the traverser in two (one for IBrowserViews and one for IXMLRPCViews) or should we look up the view depending on request by using if/then condition (if IBrowserRequest is provided - lookup IBrowserView, if IXMLRPCRequest provided - lookup IXMLRPCView). Or probably some other way? Also, is there any things to note when fixing that issue? Thanks in advance for any comments on this. -- WBR, Dan Korostelev

1 0

delete feature to z3c.extfile
by Jayarajan Jn 24 Sep '08

24 Sep '08

Hi, i am now doing some prototypes for my projects which will be dealing with tones of files. After a little scouting i decided to try z3c.extfile. Every thing works fine. But i found it strange that there is no delete feature in z3c.extfile. ie, even if i can delete a ExtFile object, the file in the hash directory is not getting deleted! and it keeps on accumulating... So i thought i 'll add a delete feature... but my __del__() approach doesn't work for me. but i added an additional delete() function too which can be invoked explicitly to delete the file before trying to delete ExtFile object. i made following changes to the source... inside z3c.extfile.file.file.ExtFile, ---------------------------------------------------------------------------------------------- class ExtFile(Persistent): """A zope file implementation based on z3c.extfile""" interface.implements(IExtFile) data = ExtBytesProperty('data') def __init__(self, data='', contentType=''): self.data = data self.contentType = contentType # added the following lines# * def __del__(self): # <- this is not being invoked when i try to delete an extfile object del self.data #print "deleted data via destructor" def delete(self): # <- added this to be able to manually able to delete files del self.data #print "deleted data via delete()" # # # # # # # # # # # # # # # * def getSize(self): return len(self.data) ---------------------------------------------------------------------------------------------- and the 'data' is a 'property' (ExtBytesProperty) so i made following changes to z3c.extfile.property.ExtBytesProperty ---------------------------------------------------------------------------------------------- class ExtBytesProperty(object): """a property which's values are stored as external files""" def __init__(self, name): self.__name = name # added the following lines# * def __delete__(self,inst): digest = inst.__dict__[self.__name] self.hd.delete(digest) * *# # # # # # # # # # # # # # # * @property def hd(self): return component.getUtility(interfaces.IHashDir) def __get__(self, inst, klass): if inst is None: return self digest = inst.__dict__.get(self.__name, _marker) if digest is _marker: return None return getFile(digest) def __set__(self, inst, value): # ignore if value is None if value is None: if inst.__dict__.has_key(self.__name): del inst.__dict__[self.__name] return # Handle case when value is a string if isinstance(value, unicode): value = value.encode('UTF-8') if isinstance(value, str): value = StringIO(value) value.seek(0) f = self.hd.new() while True: chunk = value.read(BLOCK_SIZE) if not chunk: newDigest = f.commit() oldDigest = inst.__dict__.get(self.__name, _marker) if newDigest == oldDigest: # we have no change, so we have to seek to zero # because this is normal behaviour when setting a # new value if hasattr(_storage, 'dataManager'): if newDigest in _storage.dataManager.files: f = _storage.dataManager.files[newDigest] f.seek(0) else: inst.__dict__[self.__name] = newDigest break f.write(chunk) ---------------------------------------------------------------------------------------------------- and at last added the real code which delete the file in hash directory too i added following codes inside z3c.extfile.hashdir.HashDir class --------------------------------------------------- def delete(self,digest): """delete the file""" path=self.getPath(digest) if os.path.exists(path): os.remove(path) return ---------------------------------------------------- Now, everything works fine when i try to delete an ExtFile object in ZODB, __del__() is not being invoked!!!!! can anyone tell me how can i fix this??? thanks in advance jayaraj

2 3

RFC: adding support for testing from bare setuptools
by Tres Seaver 24 Sep '08

24 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Asbestos - -------- First, note that I am not proposing to replace the current testing machinery used by Zope developers working on a given package (typically, buildout plus recipes which configure zope.testing.testrunner as a standalone script). Nor am I proposing that we modify that machinery to take advantage of setuptools' test-oriented metadata (that would be a separate proposal). Proposal - -------- Instead, what I *am* proposing is adding metadata which allows consumers of such packages to verify that the package is downloaded / installed correctly. In particular, I want for the following scenario to work seamlessly:: $ /path/to/virtualenv --no-site-packges sandbox ... $ cd sandbox $ tar xzf zope.foo.bar-3.5.6.tar.gz $ cd zope.foo.bar-3.5.6 # [1] $ ../bin/python setup.py test # [2] # Runs egg_info, installs regular and testing dependencies, and # runs all unit (non-layer) tests $ ../bin/python setup.py test # [3] # Runs egg_info, installs regular and t # runs *all* tests Theory of Operation - ------------------- [1] Ideally, this would be some variation on 'easy_install' which got the package into the environment in such a way that its 'setup.py' could be run. Fetching and unpacking the tarball manually works today, however ;) [2] 'python setup.py test' is the "standard" way to test a setuptools-based package, and would be expected to work by most egg-savvy Python developers. setuptools provides the 'test' command, using a built-in testrunner which mostly Just Works(TM). However, it doesn't support the 'layer' feature provided by 'zope.testrunner', and therefore many Zopeish packages emit failures when run this way. Without monkeypatching setuptools, we can't replace the testrunner it uses, but we *can* supply a different test loader using an option in setup.py[4]. The attached module provides such a loader, which filters out the doomed tests, leaving only those which can run cleanly without layers (e.g., the unit tests). [3] In the second method, we use the setuptools entry point mechanism to register a custom 'test' command[5]. This is a wee bit fragile, as running 'setup.py test' without first generating the egg_info will use the "standard" testrunner (but only the first time). If such fragility is an issue, we can register a separate command, e.g. 'ftest'; in either case, we have to document that you need to run 'setup.py egg_info' one time before running the custom command. If the ideal installation outlined in [1] above worked, that would solve the problem, too, because the egg-info would be generated by easy_install. This techniquie drives the zope.testing.testrunner via an entry point, which is cool, but it cannot expose all of testrunner's features. In particular, the configuration knobs which the testrunner expects to get on the command-line clash with distutils' own command-line syntax (yes, I've tried to make it work). The command I have provided just runs all the tests, unit and functional, which seems to be reasonable assurance for the package conumer that the package installed cleanly. Implementation - -------------- The intent is to add the attached module as 'zope.testing.testrunner.eggsupport', and then to modify our packages (opportunistically, or through a 'geddon) as follows: - Add 'setup_requires = ["eggtestinfo"]', so that the testing metadata is captured in EGG-INFO. Note that this information is not needed when running the tests from a source distribution, but should ease a TBD mode for testing binary distributions. - Add 'tests_require = ["zope.testing >= 3.7"]' (or whatever the next released version including this feature would be), to make the loader available. - Add 'test_loader = "zope.testing.testrunner.eggsupport:SkipLayers"' which enables 'setup.py test' to use the custom loader. Once the new 'zope.testing' package is present, then the 'ftest' command will also be available, but still needs to be called out via an entry point:: entry_points=""" [distutils.commands] ftest = zope.testing.testrunner.eggsupport:ftest """ The second attachment is a diff showing the changes to a typical Zope2 product's setup.py to support this proposal. References - ---------- [4] http://peak.telecommunity.com/DevCenter/setuptools#test-loader [5] http://peak.telecommunity.com/DevCenter/setuptools#adding-commands Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI0TXh+gerLs4ltQ4RAuEGAJ411zdUI+GjQZEkPtf2uB1zgX3KeQCgvjlA rHFCcXsSaPpY9AklWGqlmqk= =PbVE -----END PGP SIGNATURE-----

4 9

Zope Tests: 1 OK, 4 Failed
by Zope Tests Summarizer 24 Sep '08

24 Sep '08

Summary of messages to the zope-tests list. Period Tue Sep 23 11:00:00 2008 UTC to Wed Sep 24 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Test failures ------------- Subject: FAILED (errors=1) : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Sep 23 20:52:59 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010210.html Subject: FAILED (failures=1) : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 23 20:55:59 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010212.html Subject: FAILED (failures=1) : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 23 20:57:29 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010213.html Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 23 20:58:59 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010214.html Tests passed OK --------------- Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 23 20:54:29 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010211.html

1 0

z3c.form: Customer errors for Converter errors
by Hermann Himmelbauer 23 Sep '08

23 Sep '08

Hi, I'm currently trying to modify the error message for converter errors in z3c.form. For instance, if I have an Int() field and input characters there, the message is: The entered value is not a valid integer literal. So, I'd like to write a message such as "Please enter numbers only". I tried now to register a custom error class like this: ------------------------ IntErrorMsg = error.ErrorViewMessage( u'Please enter numbers only.', error=zope.schema.ValidationError, field=IPerson['personnumber']) zope.component.provideAdapter(IntErrorMsg, name='message') ------------------------ The problem with this is, that the error I need to create the error class for, seems to be a zope.schema.ValidationError. This way, all errors are reported with the error class above, which is bad. So, is there a more specific error class for converter errors (I could not find one)? Or is there a better way to solve my problem? Best Regards, Hermann -- hermann(a)qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7

1 0

zc.dict.OrderedDict efficiency
by Thomas Lotze 23 Sep '08

23 Sep '08

The documentation of OrderedDict from zc.dict 1.2.1 states that the current implementation is inefficient for large collections because it uses a PersistentList to store the order. It also says that a BList which would be preferrable is not used as it is not yet released. - What's the state of those BLists? Are they just around the corner or would it be worthwhile to consider some interim solution to the efficiency issue? - If the latter, what about storing the order by * introducing internal integer keys incremented for each newly added item and * mapping from integers to keys and values in one BTree and from keys to integers and values in a second (or using more BTrees to avoid storing those pairs)? This introduces somewhat more overhead in general but prevents the bad behaviour for large collections. Would that be an acceptable trade-off? -- Thomas

3 5

zope.i18n/z3c.form: Date localizing problems
by Hermann Himmelbauer 23 Sep '08

23 Sep '08

Hi, I'm currently implementing a simple date widget/field (birth date) in my z3c.form - based form. My two main languages are Englisch and German. In German, I'd like to write the date such as dd.mm.yyyy And in English, something suitable would be something like mm/dd/yyyy. However, that does not seem to be possible. By default, the german format is "short", which is "dd.mm.yy" (inappropriate for a birth date). If I override the format to "medium" with something like this: ----------------- class BSPDateDataConverter(DateDataConverter): """Better representation""" length = 'medium' ------------------ <adapter factory="zbsp.main.BSPDateDataConverter" /> ---------------- then the german date is fine, but the "medium" english date is in a format such as "MMM d, yyyy", which is e.g. "Sep 21, 1980". This is probably a date format nobody will be able to enter, I assume? Is there a way to make this work for both languages? Best Regards, Hermann -- hermann(a)qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7

1 0

Zope Tests: 2 OK, 3 Failed
by Zope Tests Summarizer 23 Sep '08

23 Sep '08

Summary of messages to the zope-tests list. Period Mon Sep 22 11:00:00 2008 UTC to Tue Sep 23 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Test failures ------------- Subject: FAILED (failures=1) : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 22 20:54:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010207.html Subject: FAILED (failures=1) : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 22 20:56:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010208.html Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 22 20:57:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010209.html Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Mon Sep 22 20:51:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010205.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 22 20:53:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010206.html

2 1

Python 2.6
by Tim Cook 23 Sep '08

23 Sep '08

Now that ZCA is working with Python 2.5 on 32 and 64 bit platforms (thanks guys!) Is there a plan being formulated to address all the deprecation warnings about 'with' becoming a reserved word in Python2.6? Thanks, --Tim

1 0