Re: [Zope-dev] IRC discussion about testing
* Jim Fulton j...@zope.com [2009-08-12 01:36]: On Tue, Aug 11, 2009 at 5:22 PM, Jim Fultonj...@zope.com wrote: - The versions specified in the controlled-packages.cfg don't seem to be honored except for the package being tested. For example, ZODB3-3.9.0b2 is used for test-kgs-ZODB3, but 3.9.0b5 is used for everything else. Fortunately, it appears I can work around this using a buildout versions section. In playing with this today, I'm inclined to think that it would be simpler to use a list of packages in an option to specify the packages to be tested and used a versions section to specify versions, rather than using a controlled-packages configuration file. This doesn't strike me as simpler to *use* (as I said earlier, I'd much prefer a *single* gesture of use this KGS to set up both the versions and the list of packages to run tests for, and I think it's worth spending effort to get there), but I'm not sure that's what you meant. What makes you prefer two files instead of one? I'm quite willing to either merge the z3c.recipe.kgs into compattest or abandon the latter (or whatever) and to write a buildout extension to pin the versions using a controlled-packages file, but I only want to do that kind of work if we're reasonably certain that this is what we want. Wolfgang ___ 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] Move implementation of getParent to zope.location?
Martijn Faassen wrote: One question to ask is whether getParent and getParents are used all over the place or just by zope.traversing. If they're only used by zope.traversing we might not want to move them to a more general place, but perhaps we can even see about removing them. getParent is used by a number of zope.app.* packages (apidoc, container, dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its only other occurrence is in zope.traversing where it is defined, but not used. getParents is used by zope.app.* packages as well (rotterdam, tree, workflow) and definitions of it occur in zope.location and zope.traversing, where it isn't used either, though. Seeing this now, I agree to removing the functions provided nobody objects against removing parts of the API that might be depended on by client code out there. (Both functions are actually exported by zope.traversing.api.) -- Thomas ___ 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] Move implementation of getParent to zope.location?
On Wed, Aug 12, 2009 at 3:26 AM, Thomas Lotzetho...@thomas-lotze.de wrote: ... getParent is used by a number of zope.app.* packages (apidoc, container, dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its only other occurrence is in zope.traversing where it is defined, but not used. getParents is used by zope.app.* packages as well (rotterdam, tree, workflow) and definitions of it occur in zope.location and zope.traversing, where it isn't used either, though. Seeing this now, I agree to removing the functions provided nobody objects against removing parts of the API that might be depended on by client code out there. (Both functions are actually exported by zope.traversing.api.) I object to removing API functions that client code might use. (Was that a trick questions?) What is the point of this exercise? Jim -- Jim Fulton ___ 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] IRC discussion about testing
On Wed, Aug 12, 2009 at 2:31 AM, Wolfgang Schnerringw...@gocept.com wrote: * Jim Fulton j...@zope.com [2009-08-12 01:36]: On Tue, Aug 11, 2009 at 5:22 PM, Jim Fultonj...@zope.com wrote: - The versions specified in the controlled-packages.cfg don't seem to be honored except for the package being tested. For example, ZODB3-3.9.0b2 is used for test-kgs-ZODB3, but 3.9.0b5 is used for everything else. Fortunately, it appears I can work around this using a buildout versions section. In playing with this today, I'm inclined to think that it would be simpler to use a list of packages in an option to specify the packages to be tested and used a versions section to specify versions, rather than using a controlled-packages configuration file. This doesn't strike me as simpler to *use* (as I said earlier, I'd much prefer a *single* gesture of use this KGS to set up both the versions and the list of packages to run tests for, and I think it's worth spending effort to get there), but I'm not sure that's what you meant. What makes you prefer two files instead of one? I didn't say anything about 2 files. I said I prefered a parts list in a single option in combination with a standard buildout versions section. There are a number of reasons for this: - We'll need the versions section to consume the KGS. That is, given a KGS, you'll often want to use the versions in other buildouts to limit them to the known good configuration. - I think a parts list in an option will be easier to control. For example, you will be able to use the standard buildout option incrementing and decrementating machinery to modify it. - After using it for a day, I find the controlled-packages syntax to be a bit heavy. Of course, it didn't help that I still had to create a versions list. - The parts section and versions section could be specified in a single file, so the gesture for using them could be pretty simple. Jim -- Jim Fulton ___ 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] Move implementation of getParent to zope.location?
On Wed, Aug 12, 2009 at 5:56 AM, Thomas Lotzetho...@thomas-lotze.de wrote: Jim Fulton j...@zope.com schrieb: I object to removing API functions that client code might use. (Was that a trick questions?) What is the point of this exercise? Sorry, this message shouldn't have been sent in the state it was. The original point of the exercise was to clean up the situation where the two closely related functions aren't part of the same APIs. Then I responded to the suggestion of removing the functions, noticing two things as I wrote: the functions are used by zope.app packages, and they are part of zope.traversing.api but not used by anything non-zope.app. As api-style modules have been questioned in the past, I wanted to raise the issue whether the functions are meant to remain part of that module or live in the ILocationInfo interface alone, but I got distracted at that point and for some reason sent the message, which I shouldn't have done. If the functions remain in the api module, the remaining issue would be whether to move the implementation of getParent to zope.location and thus treat it like getParents. Right. I understood this in the original proposal. Given that it doesn't break the existing API, I have no major problem with it, which is why I didn't bother to respond in the first place. I have a small problem that it fattens an existing API. I have a larger problem that we are wasting time on this. The cleanup doesn't seem worth it to me. I especially don't like that *I'm* spending time on this rather than, say, working on the kgs or our buildout discussions. Jim -- Jim Fulton ___ 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] IRC discussion about testing
* Jim Fulton j...@zope.com [2009-08-12 11:52]: On Wed, Aug 12, 2009 at 2:31 AM, Wolfgang Schnerringw...@gocept.com wrote: * Jim Fulton j...@zope.com [2009-08-12 01:36]: In playing with this today, I'm inclined to think that it would be simpler to use a list of packages in an option to specify the packages to be tested and used a versions section to specify versions, rather than using a controlled-packages configuration file. This doesn't strike me as simpler to *use* (as I said earlier, I'd much prefer a *single* gesture of use this KGS to set up both the versions and the list of packages to run tests for, and I think it's worth spending effort to get there), but I'm not sure that's what you meant. What makes you prefer two files instead of one? I didn't say anything about 2 files. I said I prefered a parts list in a single option in combination with a standard buildout versions section. Sorry for my misunderstanding. In fact, I'm not hung up about the number of files all that much, but rather I'm searching for a way not to duplicate information. And that seems rather diffcult, since you assert... - We'll need the versions section to consume the KGS. That is, given a KGS, you'll often want to use the versions in other buildouts to limit them to the known good configuration. ...while Martijn said here http://article.gmane.org/gmane.comp.web.zope.devel/21328 that the KGS will need to store more information about each package than a versions section can handle. - The parts section and versions section could be specified in a single file, so the gesture for using them could be pretty simple. This seems to be the best we can do, given the above requirements. If I understand you correctly, that file would then look something like this: [versions] zope.foo = 1.2.3 grok.bar = 1.1.0 thirdparty.dependency = 4.4 [zope.foo] tested = true kgs = ztk develop = http://svn.zope.org/repos/main/zope.foo/branches/1.2 [grok.bar] tested = true develop = http://svn.zope.org/repos/main/grok.bar/trunk [thirdparty.dependency] tested = no z3c.recipe.compattest/kgs would learn to extract all sections from the above where tested=true. And zope.kgs/zope.release could then probably be retired (or am I missing something?). - I think a parts list in an option will be easier to control. For example, you will be able to use the standard buildout option incrementing and decrementating machinery to modify it. I don't understand how a parts list could help here. Wolfgang ___ 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] Zope Tests: 7 OK
Summary of messages to the zope-tests list. Period Tue Aug 11 12:00:00 2009 UTC to Wed Aug 12 12:00:00 2009 UTC. There were 7 messages: 7 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 12 04:33:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012274.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 12 04:37:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012275.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 04:39:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012276.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Aug 12 04:41:49 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012277.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 04:43:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012278.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 04:45:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012279.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Aug 12 04:47:50 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012280.html ___ 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.testing 3.8 fails in mysterious ways
Marius Gedminas wrote: On Mon, Aug 03, 2009 at 01:17:41PM +0200, Andreas Zeidler wrote: just fyi: the bug is also present in zope.testing 3.7.7 (showing up when testing plone.z3cform). would it perhaps be possible to release a fixed 3.7.8 soon, so that our buildout stops complaining again? :) I looked at the bug and Godefroid's checkin today. Things seem to be complicated. Short summary: collective.recipe.z2testrunner doesn't support running tests in a subprocess. Long summary: https://launchpad.net/bugs/407916 As a quick workaround, instead of a single 'run tests' step that does bin/test do separate 'run unit tests' and 'run functional tests' steps bin/test -u bin/test -f in your buildbot config. Marius Gedminas I did fix zope.testing and plone.recipe.zope2instance : http://mail.zope.org/pipermail/checkins/2009-August/036807.html https://dev.plone.org/collective/changeset/94328/buildout/plone.recipe.zope2instance/trunk/src Fixes released in zope.testing 0.8.1 and plone.recipe.zope2instance 3.4 -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ 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] IRC discussion about testing
On Wed, Aug 12, 2009 at 7:07 AM, Wolfgang Schnerringw...@gocept.com wrote:
* Jim Fulton j...@zope.com [2009-08-12 11:52]:
On Wed, Aug 12, 2009 at 2:31 AM, Wolfgang Schnerringw...@gocept.com wrote:
* Jim Fulton j...@zope.com [2009-08-12 01:36]:
In playing with this today, I'm inclined to think that it would be
simpler to use a list of packages in an option to specify the packages
to be tested and used a versions section to specify versions, rather
than using a controlled-packages configuration file.
This doesn't strike me as simpler to *use* (as I said earlier, I'd much
prefer a *single* gesture of use this KGS to set up both the versions
and the list of packages to run tests for, and I think it's worth
spending effort to get there), but I'm not sure that's what you meant.
What makes you prefer two files instead of one?
I didn't say anything about 2 files. I said I prefered a parts list
in a single option in combination with a standard buildout versions
section.
Sorry for my misunderstanding. In fact, I'm not hung up about the number
of files all that much, but rather I'm searching for a way not to
duplicate information. And that seems rather diffcult, since you
assert...
- We'll need the versions section to consume the KGS. That is, given
a KGS, you'll often want to use the versions in other buildouts to
limit them to the known good configuration.
...while Martijn said here
http://article.gmane.org/gmane.comp.web.zope.devel/21328
that the KGS will need to store more information about each package than
a versions section can handle.
So there he said:
I do think we need a computer readable system that includes information
like this:
* whether a project is in a KGS (such as for the ZTK)
* whether a project is used to test a KGS (a package not in the ZTK but
used to test whether changes don't induce breakage, let's say,
grokcore.component)
* the locked down version of the package.
* where the *next* version of the locked down version is being
developed. Generally this is the SVN trunk, but could be a stable branch.
I'm not sure why this all has to be computer readable. What is the
use case for computer readable knowledge of whether a package is in
the kgs or just used to test it? What is the need for computer
readable information about where the package is being developed.
- The parts section and versions section could be specified in a
single file, so the gesture for using them could be pretty simple.
This seems to be the best we can do, given the above requirements.
If I understand you correctly, that file would then look something like this:
[versions]
zope.foo = 1.2.3
grok.bar = 1.1.0
thirdparty.dependency = 4.4
[zope.foo]
tested = true
kgs = ztk
develop = http://svn.zope.org/repos/main/zope.foo/branches/1.2
[grok.bar]
tested = true
develop = http://svn.zope.org/repos/main/grok.bar/trunk
[thirdparty.dependency]
tested = no
z3c.recipe.compattest/kgs would learn to extract all sections from the
above where tested=true. And zope.kgs/zope.release could then probably
be retired (or am I missing something?).
This seems heavier than needed. Also, if someone extends this,
they're going to get an awful lot of sections that might have names
that conflict with names in their buildout. I do like the fact that
the versions section is reusable. :)
Here's an alternative:
[versions]
zope.foo = 1.2.3
zope.bar = 1.2.3
zope.app.baz = 1.2.3
grok.bar = 1.1.0
thirdparty.dependency = 4.4
[ztk]
projects = zope.foo zope.bar zope.app.baz
also-tested = grok.bar
Now, if I want to test using this, I do something like:
[buildout]
parts = ztk-tests
extends = the-file-above
[ztk-tests]
recipe = our.kgs.testing.recipe
projects = ${ztk:projects} ${ztk:also-tested}
I think this is much cleaner and gives us:
- Easily reusable information, including versions information that can
be used by any buildout.
- Information about the projects in the ztk
- Information about additional projects to be tested.
It doesn't give us machine-readable information about where the next
version of the project is being developed. Why do we need that?
Also, with this, the recipe doesn't have to parse anything.
- I think a parts list in an option will be easier to control. For
example, you will be able to use the standard buildout option
incrementing and decrementating machinery to modify it.
I don't understand how a parts list could help here.
Now suppose we want to add another project to be tested, 'our.app':
[buildout]
parts = ztk-tests
extends = the-file-above
[ztk-tests]
recipe = our.kgs.testing.recipe
projects = ${ztk:projects} ${ztk:also-tested} our.app
But we don't want to bother testing zope.app.baz. We don't use it and
the tests take too long:
[buildout]
parts = ztk-tests
extends = the-file-above
[ztk-tests]
recipe = our.kgs.testing.recipe
projects = ${ztk:projects} ${ztk:also-tested} our.app
[Zope-dev] MailHost Improvements
Hello, I've been working on making Plone use the standard Zope MailHost in place of the custom Products.SecureMailHost we've been using since Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this process I've run into a couple bugs in the MailHost implementation and I believe it is missing some essential functionality. The most significant issue is that if you call send() with a messageText containing just the message body, and that body has a ':' in it (e.g. a url) the body will be treated as a header and you'll send a nonsense message. The current implementation of send() also puts a fairly large burden on developers who want to generate simple, correctly encoded messages. Finally, send() relies heavily on the long deprecated 'rfc822' and 'mimetools' modules which have been removed from Python 3.0. I've attached a patch that updates MailHost to use the 'email' module for parsing and generating messages. In addition to fixing the issues that I ran across, and maintaining compatibility, it provides a number of new features: * send and sendTemplate accept an optional charset argument. Using this will set the content-type charset, as well as trigger appropriate encoding if needed. * send and sendTemplate accept an optional msg_type argument which will set the content type header for the message. * The messageText, mfrom, mto, and subject arguments may now be unicode or encoded non-ascii strings, provided a charset is given. Any unicode input will be automatically encoded to the provided charset (or the default charset). Headers will be further encoded in compliance with rfc2822. The message body will be further encoded using a transfer encoding determined by the email.Charset registry (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, base64 for most other encodings). * The messageText argument now accepts email.Message.Message objects directly. I'm attaching a patch that includes these changes as well as tests for all new functionality. I hope to integrate these changes into Zope 2.12 before final release, but would like to hear the opinions of Zope developers before committing. Though these are fairly significant changes, I believe they provide very useful functionality as well as at least one critical fix, while maintaining 100% compatibility. Thanks, Alec mailhost.patch Description: Binary data ___ 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] IRC discussion about testing
On Tue, Aug 11, 2009 at 7:36 PM, Jim Fultonj...@zope.com wrote: On Tue, Aug 11, 2009 at 5:22 PM, Jim Fultonj...@zope.com wrote: ... - The versions specified in the controlled-packages.cfg don't seem to be honored except for the package being tested. For example, ZODB3-3.9.0b2 is used for test-kgs-ZODB3, but 3.9.0b5 is used for everything else. Fortunately, it appears I can work around this using a buildout versions section. Except that there's a bug in buildout that causes extras to be dropped when versions are specified via a versions section. This causes the extras to be omitted from the test scripts. :( Hopefully, I'll get a fixed buildout release out tomorrow. Done The good news is that with a hacked buildout and a versions section, I can run tests for all of the packages in http://docs.zope.org/zopetoolkit/about/packages.html except for zope.ucol. I'm getting test failures in 5 packages. I suspect that these are due to missing dependencies. So, I created a KGS based on the ZTK and Fabio's recipe. If you want to try it, check out svn://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs. (I still think we want a simpler way to configure this, as proposed in an earlier message today.) Jim -- Jim Fulton ___ 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] MailHost Improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Mitchell wrote: Hello, I've been working on making Plone use the standard Zope MailHost in place of the custom Products.SecureMailHost we've been using since Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this process I've run into a couple bugs in the MailHost implementation and I believe it is missing some essential functionality. The most significant issue is that if you call send() with a messageText containing just the message body, and that body has a ':' in it (e.g. a url) the body will be treated as a header and you'll send a nonsense message. The current implementation of send() also puts a fairly large burden on developers who want to generate simple, correctly encoded messages. Finally, send() relies heavily on the long deprecated 'rfc822' and 'mimetools' modules which have been removed from Python 3.0. I've attached a patch that updates MailHost to use the 'email' module for parsing and generating messages. In addition to fixing the issues that I ran across, and maintaining compatibility, it provides a number of new features: * send and sendTemplate accept an optional charset argument. Using this will set the content-type charset, as well as trigger appropriate encoding if needed. * send and sendTemplate accept an optional msg_type argument which will set the content type header for the message. * The messageText, mfrom, mto, and subject arguments may now be unicode or encoded non-ascii strings, provided a charset is given. Any unicode input will be automatically encoded to the provided charset (or the default charset). Headers will be further encoded in compliance with rfc2822. The message body will be further encoded using a transfer encoding determined by the email.Charset registry (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, base64 for most other encodings). * The messageText argument now accepts email.Message.Message objects directly. I'm attaching a patch that includes these changes as well as tests for all new functionality. I hope to integrate these changes into Zope 2.12 before final release, but would like to hear the opinions of Zope developers before committing. Though these are fairly significant changes, I believe they provide very useful functionality as well as at least one critical fix, while maintaining 100% compatibility. +1 for the approach in general (I haven't looked at the patch in detail). Assuming all tests pass, and that you have a test exercising the ':' bug you describe, I would just commit it on the trunk (I think such a change should be in the upcoming 2.12 beta). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKg4SS+gerLs4ltQ4RAgOuAJ0W2CNRCDQglY75s0HVKFnChOwbnwCfSEmu ph+wxAWDwjG3J8xZV1Cr6+U= =tZEF -END PGP 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] For the record - a minimum changes to zope.proxy to support zope.deferredimport under google app engine
Hi Folks This is a quick and dirty change and to be honest the main reason I am posting it here is so there is a searchable record for anyone else who wants to use zope.deferredimport under google app engine. (With some content models zope.deferredimport is a great way of dealing with cyclic dependancies and possibly improving startup times - see bottom of this email.) Below is a minimal set of changes to zope.proxy.__init__ that is required so that zope.deferredimport can be used. It does mean you need peak.utils to implement a basic proxy. try: from zope.proxy._zope_proxy_proxy import * from zope.proxy._zope_proxy_proxy import _CAPI except NotImplementedError: from peak.util.proxies import ObjectProxy class ProxyBase(ObjectProxy): pass def getProxiedObject(obj): if hasattr(obj,'__subject__'): return obj.__subject__ else: return obj def removeAllProxies(obj): return getProxiedObject(obj) def sameProxiedObjects(obj1,obj2): if getProxiedObject(obj1) == getProxiedObject(obj2): return True else: return False There are a couple of other zope.proxy functions from the 'c' api that I haven't looked at yet as they aren't used by zope.deferredimport. Suggestions on improving it and/or followups on the other functions would also be welcome. I have also found that deferred import can help with app engine startup times as it means you can import a module you depend on but not really import the code until it gets touched which can allow you to stagger you startup costs. (For instance edit functionality of a site could be deferred until someone actually edits something). Hope this helps someone Regards Tim Hoffman ___ 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] MailHost Improvements
On 13.08.09 01:03, Alec Mitchell wrote: Hello, I've been working on making Plone use the standard Zope MailHost in place of the custom Products.SecureMailHost we've been using since Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this process I've run into a couple bugs in the MailHost implementation and I believe it is missing some essential functionality. The most significant issue is that if you call send() with a messageText containing just the message body, and that body has a ':' in it (e.g. a url) the body will be treated as a header and you'll send a nonsense message. The current implementation of send() also puts a fairly large burden on developers who want to generate simple, correctly encoded messages. Finally, send() relies heavily on the long deprecated 'rfc822' and 'mimetools' modules which have been removed from Python 3.0. I've attached a patch that updates MailHost to use the 'email' module for parsing and generating messages. In addition to fixing the issues that I ran across, and maintaining compatibility, it provides a number of new features: * send and sendTemplate accept an optional charset argument. Using this will set the content-type charset, as well as trigger appropriate encoding if needed. * send and sendTemplate accept an optional msg_type argument which will set the content type header for the message. * The messageText, mfrom, mto, and subject arguments may now be unicode or encoded non-ascii strings, provided a charset is given. Any unicode input will be automatically encoded to the provided charset (or the default charset). Headers will be further encoded in compliance with rfc2822. The message body will be further encoded using a transfer encoding determined by the email.Charset registry (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, base64 for most other encodings). * The messageText argument now accepts email.Message.Message objects directly. I'm attaching a patch that includes these changes as well as tests for all new functionality. I hope to integrate these changes into Zope 2.12 before final release, but would like to hear the opinions of Zope developers before committing. Though these are fairly significant changes, I believe they provide very useful functionality as well as at least one critical fix, while maintaining 100% compatibility. This comes very, very late. We are pretty close to a release. Please put the changes on the trunk only. We will check after my vacation if we can move it into the 2.12 beta. Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
