Re: [Zope3-dev] Re: using utilities/sites from threads in zope3
Thanks Tres, I've ended up with a threadHelper.py module that seems to
be working well, I'll post it as its small and might be useful for
people googling in the future.
"""Helper utilities for working with threads."""
from ZODB.interfaces import IDatabase
from zope.app import zapi
from zope.app.traversing.api import traverseName
from zope.app.component.hooks import setSite
from zope.app.component.interfaces import ISite
from transaction import manager
def setupWorkerThread(path):
"""sets up the regular contexts for your worker thread, takes a path which
can be found with zope.app.traversing.api.getPath(obj), the site context of
your thread will be configured based on this path and the object at the
path returned."""
db = zapi.getUtility(IDatabase) #XXX assumes we have only one db
conn = db.open()
root = conn.root()
manager.begin()
ctx = root['Application']
for seg in path.split('/')[1:]:
ctx = traverseName(ctx, seg.encode("ASCII"))
if ISite.providedBy(ctx):
setSite(ISite(ctx))
return ctx
def closeWorkerThread():
manager.commit()
On 7/3/07, Jim Fulton <[EMAIL PROTECTED]> wrote:
What Tres said. :)
Jim
On Jun 29, 2007, at 8:54 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tim Stebbing wrote:
>> G'day,
>>
>> I've recently ran into a bit of a problem attempting to use
>> threads in
>> zope 3.2.1, hooks.getSite() returns None, and any attempt to get a
>> utility results in a component lookup error within my threads.
>>
>> I've attempted to pass a site into a thread and set it with
>> hooks.setSite() but this is apparently not the way to go, I get the
>> feeling that a thread that needs access to things form the database
>> probably needs its own connection, context etc.
>
> Your worker thread almost certainly needs its own database
> connection(s): applicaiton code typically relies on the isolation
> provided by connection-per-thread, which means that it is not
> "safe" in
> general to share persistent objects between threads.
>
> Assuming that you do grab a connection and get its root object, you
> should then be able to traverse to your friendly local site manager,
> calling 'setSite' at *each* parent site manager you pass along the
> way.
>
>> I'm aware of ITask's but unsure if developers are supposed to use
>> them
>> for their own purposes? Do these handle setting up of contexts like
>> db, site, global utils etc? I've googled around a fair bit and been
>> over all the z3 doco, it would be great if there was a simple
>> howto on
>> setting up a thread that would have the usual access to various
>> components.
>
>
> Tres.
> - --
> ===
> Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
> 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
>
> iD8DBQFGhQEG+gerLs4ltQ4RAh6EAJ9DzBW20NPz4tAE3BydJ789Vokx0wCg2qMp
> yBB8XemrjD7dXPwwwz4y9Yo=
> =+iwh
> -END PGP SIGNATURE-
> ___
> Zope3-dev mailing list
> Zope3-dev@zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
>
--
Jim Fulton mailto:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporationhttp://www.zope.com http://www.zope.org
--
Timothy J Stebbing
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On Jul 2, 2007, at 3:07 PM, Gary Poster wrote: ... Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B. Unless I misunderstand, this is what I did, actually, and Bernd (and probably others) didn't like it. That is, I have a zope.org/ distributions release of zope.app.keyreference 3.5 dev and ZODB 3.9 dev, and I said that keyreference 3.5 depended on ZODB 3.9 dev. Cool. I guess I missed that. ... I like the proposal you and Benji came up with. In that case, would what I released (except that I used "-dev" rather than "dev") be correct? Yes ... one new feature (more informative PersisntentReferences) that supports an arguable zope.app.keyreference bugfix (conflict resolution breaks with persistent key references; Can you remind me or point me at something that describes in more detail? ZODB/ConflictResolution.txt line 226 ff. I think the __cmp__ method is a bug fix. Would that be enough for zope.app.keyreference? ... Does zope.app.keyreference work as well as it does now without this? I haven't tested it, but yes, I believe it should. Then if we back-ported the bug fixes, as I think we should, then zope.app.keyreference could depend on 3.8, or perhaps even 3.7. ... Then I'd argue that the zope.app.keyreference change could go into 3.4. Are we really talking about 3.4? Yes, zope.app.keyreference. "Not breaking BTree conflict resolution" could be cast pretty easily as a bugfix. I'm still not sure what this has to do with 3.4. :) ... - Also for this particular problem, I suppose I could remove the dependency on ZODB 3.9 and add a test to show that it should still "work" (as well as it did before at least) with ZODB 3.8 persistent references. I'd really rather not, of course, but I can do it in the next week and a half. I guess it would still be "3.5" but it wouldn't depend on 3.9 (...except to actually have any improvements over 3.4!) I think you should do this or make your version of zope.app.keyreference a dev version. OK, I'll see what I can do It sounds like it already is a dev version. ... I just brainstormed this with Benji and we both think that it would be enough to have an option that says: "I prefer final versions" meaning that we always want the latest final version that satisfies our requirements, if there is one. Ideally, this would be a setuptools option, however, this would be a new feature and I don't think we'll see new setuptools features any time soon. I could add this as an option to buildout. sounds good to me. Being able to override it for individual packages would be important for me. You'd override it by specifying a needed dev version in a requirement. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to debug zope3 if it completely hangs?
On Jul 1, 2007, at 4:01 PM, Benji York wrote: Fabio Tranchitella wrote: My question is easy: I don't know how to investigate the problem when my Zope instance is not responsive anymore. I tried to use PDB, GDB and friends but without success. One of GDB's friends is strace. It can be very helpful in situations like yours. Use the -p option to attach to the running process to see what's going on. See also http://www.upfrontsystems.co.za/Members/jean/zope-notes/ debug-spinning-zope and http://svn.python.org/view/python/trunk/ Misc/gdbinit?view=markup. Another option, if you are using zserver, is to (carefully) use the Medusa monitor server and client. This lets you telnet to the server and get a limited Python prompt that lets you poke around at the Python level. Of course, this is a potential security hole if not done carefully. I used to find it very useful for looking at hung Zope 2 applications before it was disabled in Zope 3 for security reasons. I would try what Benji suggested first and then pursue the monitor server if that doesn't work. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] two small bugs in zc.relationship
On Jul 2, 2007, at 6:19 PM, Gary Poster wrote: On Jul 2, 2007, at 3:24 PM, Markus Kemmerling wrote: Hi, I discovered two smalll bugs in `zc.relationship`. Thanks, I'll get those in 24 hours or so. FWIW, generally, tests would be appreciated too, particularly of the index. I'll make one for the index: I use that heavily and the tests are pretty thorough (never thorough enough, of course). The container stuff is sadly not very well tested, and I don't have the motivation for adding to it. I just looked at the bugs and they are both in the container wrappers, as opposed to the core index. Could you whip up a diff for container.txt to test this? I'll then commit it to the trunk (slated for 2.0 RSN), make a 1.1 branch from the 1.1a tag and commit it on the branch, and make a 1.1 release and a 2.0a release. Thanks again Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
Gary Poster wrote: In that case, would what I released (except that I used "-dev" rather than "dev") be correct? Yep. And those that only want final releases would be required to say so when invoking setuptools (or buildout). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On Jul 2, 2007, at 9:42 PM, Jim Fulton wrote: Thanks for reply. quick notes: I think that in *technically* depending on a newer version introduces a backward incompatibility. (It's like strengthening a precondition of a method.) This is especially a problem if people are specifying upper limits for their requirements, which is only necessary if there backward incompatible changes. ZODB 3.9 won't be backward incompatible in any meaningful way. ZODB 3.9, like 3.8 *is* backward incompatible because it drops features that we agreed, as a community, to drop. Arguably, ZODB 3.8 should have been ZODB 4 and ZODB 3.9 should be ZODB 5, but I don't think we want to do that. So, let''s say, as a practical matter, that ZODB 3.9 is backward compatible with 3.8. We don't know that 3.9 is ready for use yet. It's possible that there have been bugs introduced in 3.9 (or soon will be) that will be discovered and fixed during the beta cycle. Many people rightly don't want to depend on 3.9 until it has been released in a final form. Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B. Unless I misunderstand, this is what I did, actually, and Bernd (and probably others) didn't like it. That is, I have a zope.org/ distributions release of zope.app.keyreference 3.5 dev and ZODB 3.9 dev, and I said that keyreference 3.5 depended on ZODB 3.9 dev. I like the proposal you and Benji came up with. In that case, would what I released (except that I used "-dev" rather than "dev") be correct? ... - For this particular problem, I wish my ZODB changes could go into ZODB 3.8. As I mentioned in the commit message, the change includes one bug fix for a potentially serious problem that could cause data integrity issues; This could go into 3.8. one new feature (more informative PersisntentReferences) that supports an arguable zope.app.keyreference bugfix (conflict resolution breaks with persistent key references; Can you remind me or point me at something that describes in more detail? ZODB/ConflictResolution.txt line 226 ff. Does zope.app.keyreference work as well as it does now without this? I haven't tested it, but yes, I believe it should. and one feature (conflict resolution now supports multi databases). This is a bug fix and could go into 3.8. Then I'd argue that the zope.app.keyreference change could go into 3.4. Are we really talking about 3.4? Yes, zope.app.keyreference. "Not breaking BTree conflict resolution" could be cast pretty easily as a bugfix. - Even if people agreed with me for the previous bullet, that doesn't make this kind of problem go away. - Also for this particular problem, I suppose I could remove the dependency on ZODB 3.9 and add a test to show that it should still "work" (as well as it did before at least) with ZODB 3.8 persistent references. I'd really rather not, of course, but I can do it in the next week and a half. I guess it would still be "3.5" but it wouldn't depend on 3.9 (...except to actually have any improvements over 3.4!) I think you should do this or make your version of zope.app.keyreference a dev version. OK, I'll see what I can do ... My current opinion is that version numbers are the best solution of a bad lot. I think we really need a way to limit the algorithm for finding distributions to avoid immature (releases). I just brainstormed this with Benji and we both think that it would be enough to have an option that says: "I prefer final versions" meaning that we always want the latest final version that satisfies our requirements, if there is one. Ideally, this would be a setuptools option, however, this would be a new feature and I don't think we'll see new setuptools features any time soon. I could add this as an option to buildout. sounds good to me. Being able to override it for individual packages would be important for me. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
On 02.07.2007, at 20:54, Jim Fulton wrote: See me response to Gary's note. Here's what I propose: 1. We adopt the policy that a distribution's version number must be of less or equal maturity than all of it's dependencies, where maturity is based on it's position in the release cycle. dev is less mature than alpha is less mature than beta is less mature than release candidate is less mature than final. So, for example, dev release of zope.app.keyreference can depend on a dev release of ZODB3, but an alpha release of zope.app.keyreference cannot. Initially, this will be a convention. Eventually, I'll add a feature to buildout to warn when this policy is violated. +1 2. We approach the distutils sig with a feature request for an option to prefer final versions, so that, if we specify the new option, we always get the newest final version that satisfies a requirement, if there is one. I suggest that this be --prefer- final. Anyone want to volunteer to bring this up there? :) I don't think we'll see this feature any time soon. +1 3. I add a prefer-final option to buildout to prefer final versions. I think I can do this in the next week. +1 Thoughts? Jim On Jun 27, 2007, at 10:01 AM, Christian Theune wrote: Hi, the recent introduction of zope.app.keyreference-3.5dev with it's dependency on ZODB 3.9 brought some issues for me as I get conflicts in various buildouts (e.g. z3c.zalchemy). In my example, z3c.zalchemy doesn't care about which version of zope.app.keyreference it gets, as even the newer one won't affect us. I'd like to re-visit the discussion about "stable package versions" and how to approach the distutils list to get what we want. Currently I resolve this issue by putting a specific version in my project's buildout and leave the package (e.g. z3c.zalchemy) alone. I'm not sure whether this is the strategy we should use. Should z3c.zalchemy say: I'm good with zope.app.keyreference==3.4 (with our proposed syntax, or <3.5dev with the current syntax)? I'd like to see some consensus on how we handle those ... Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- "Special cases aren't special enough to break the rules." -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: using utilities/sites from threads in zope3
What Tres said. :) Jim On Jun 29, 2007, at 8:54 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Stebbing wrote: G'day, I've recently ran into a bit of a problem attempting to use threads in zope 3.2.1, hooks.getSite() returns None, and any attempt to get a utility results in a component lookup error within my threads. I've attempted to pass a site into a thread and set it with hooks.setSite() but this is apparently not the way to go, I get the feeling that a thread that needs access to things form the database probably needs its own connection, context etc. Your worker thread almost certainly needs its own database connection(s): applicaiton code typically relies on the isolation provided by connection-per-thread, which means that it is not "safe" in general to share persistent objects between threads. Assuming that you do grab a connection and get its root object, you should then be able to traverse to your friendly local site manager, calling 'setSite' at *each* parent site manager you pass along the way. I'm aware of ITask's but unsure if developers are supposed to use them for their own purposes? Do these handle setting up of contexts like db, site, global utils etc? I've googled around a fair bit and been over all the z3 doco, it would be great if there was a simple howto on setting up a thread that would have the usual access to various components. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFGhQEG+gerLs4ltQ4RAh6EAJ9DzBW20NPz4tAE3BydJ789Vokx0wCg2qMp yBB8XemrjD7dXPwwwz4y9Yo= =+iwh -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RFC: versioning proposal Re: [Zope3-dev] Specifying upper limits in dependencies
See me response to Gary's note. Here's what I propose: 1. We adopt the policy that a distribution's version number must be of less or equal maturity than all of it's dependencies, where maturity is based on it's position in the release cycle. dev is less mature than alpha is less mature than beta is less mature than release candidate is less mature than final. So, for example, dev release of zope.app.keyreference can depend on a dev release of ZODB3, but an alpha release of zope.app.keyreference cannot. Initially, this will be a convention. Eventually, I'll add a feature to buildout to warn when this policy is violated. 2. We approach the distutils sig with a feature request for an option to prefer final versions, so that, if we specify the new option, we always get the newest final version that satisfies a requirement, if there is one. I suggest that this be --prefer-final. Anyone want to volunteer to bring this up there? :) I don't think we'll see this feature any time soon. 3. I add a prefer-final option to buildout to prefer final versions. I think I can do this in the next week. Thoughts? Jim On Jun 27, 2007, at 10:01 AM, Christian Theune wrote: Hi, the recent introduction of zope.app.keyreference-3.5dev with it's dependency on ZODB 3.9 brought some issues for me as I get conflicts in various buildouts (e.g. z3c.zalchemy). In my example, z3c.zalchemy doesn't care about which version of zope.app.keyreference it gets, as even the newer one won't affect us. I'd like to re-visit the discussion about "stable package versions" and how to approach the distutils list to get what we want. Currently I resolve this issue by putting a specific version in my project's buildout and leave the package (e.g. z3c.zalchemy) alone. I'm not sure whether this is the strategy we should use. Should z3c.zalchemy say: I'm good with zope.app.keyreference==3.4 (with our proposed syntax, or <3.5dev with the current syntax)? I'd like to see some consensus on how we handle those ... Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
On Jun 27, 2007, at 11:36 AM, Gary Poster wrote: On Jun 27, 2007, at 2:30 AM, Bernd Dorn wrote: On 26.06.2007, at 21:44, Gary Poster wrote: On Jun 26, 2007, at 3:29 PM, Bernd Dorn wrote: i think as long the package has a dev dependency like ZODB 3.9 it should at least have alpha or beta status Hi Bernd. Why? because it pulls in software that has development status like zodb 3.9 and the release of 3.9 will take at least a half a year from now on imho. My basic response--"don't use this version of zope.app.keyreference"--doesn't appear to be sufficient for you (or Theuni, from his "Specifying upper limits in dependencies" email today). I have asserted, and I think people agree that setting upper limits in setup scripts is a bad idea as it will soon lead to situations where the current algorithm used by setuptools to build working sets of compatible revisions will fail. Of course, it isn't a problem to introduce tighter version requirements in "application" setup scripts or buildout configurations. It is ok for me because my project is specifying versions, which is also the strategy he says he is pursuing. I don't know of a better one, actually. Both you and he seem to be looking for one though, which I appreciate. gary, is it possible to be compatible to 3.8 too? Not productively. We could have "if the PersistentReference doesn't have the 3.9 stuff then just refuse to do a ConflictError" but then that's no different that the keyreference 3.4 behavior. Heh, actually, that's effectively the behavior we probably have now for keyreference 3.5dev running against ZODB 3.8, since errors in the conflict resolution will simply cause the resolution to fail, and the 3.5dev changes would generate AttributeErrors against ZODB 3.8 during conflict resolution. So...it would be a bit of a lie to claim to be compatible with 3.8. The changes are useless without the 3.9 changes. But the code *should* technically work with the same restrictions we have now. That said, I don't really want to support the changes against 3.8. ...I could move the releases to our ZC download location, rather than the zope.org one, if folks want... i don't think that this is a good idea, for example our company uses both of the download locations Well, I can move it any number of places, but this does sound like a hack, hiding the basic problem. Yup. What's the problem? I'm happy to help, especially if it doesn't take too much time, and you can wait a day or two. ok, i think if another new feature is implemented in keyreference and we want this feature for zodb3.8 we have to do a version inbetween, so if you call this a 3.5 release, what should that other version be? 3.6 I guess this is a problem. I certainly understand the story. We (the community/dev mailing list) had said before that you needed to start a new major version when you broke backwards compatibility. I did not break backwards compatibility, I just depended on a new feature of another package. The only answer I see to solve the story you just told is to also say that you have to rev the major version whenever you depend on the new feature of another package. I think that in *technically* depending on a newer version introduces a backward incompatibility. (It's like strengthening a precondition of a method.) This is especially a problem if people are specifying upper limits for their requirements, which is only necessary if there backward incompatible changes. ZODB 3.9 won't be backward incompatible in any meaningful way. ZODB 3.9, like 3.8 *is* backward incompatible because it drops features that we agreed, as a community, to drop. Arguably, ZODB 3.8 should have been ZODB 4 and ZODB 3.9 should be ZODB 5, but I don't think we want to do that. So, let''s say, as a practical matter, that ZODB 3.9 is backward compatible with 3.8. We don't know that 3.9 is ready for use yet. It's possible that there have been bugs introduced in 3.9 (or soon will be) that will be discovered and fixed during the beta cycle. Many people rightly don't want to depend on 3.9 until it has been released in a final form. Bernd has suggested a policy that I think we should adopt, which is that a package's release status should be no higher than the status of it's dependencies. So, for example, if A depends on a dev version of B, then the version of A that has this dependency should be a dev version. A should not be able to go to alpha, or beta, or final without a corresponding advance of its dependency on B. However, I am afraid that this would lead to ugly (and expensive to maintain) if-else clauses in our software, or rapidly escalating version numbers, and even maintaining multiple branches simultaneously. Dependencies are precisely what is supposed to address this problem, I thought. Except we've found corners in the depend
Re: [Zope3-dev] two small bugs in zc.relationship
On Jul 2, 2007, at 3:24 PM, Markus Kemmerling wrote: Hi, I discovered two smalll bugs in `zc.relationship`. Thanks, I'll get those in 24 hours or so. FWIW, generally, tests would be appreciated too, particularly of the index. I'll make one for the index: I use that heavily and the tests are pretty thorough (never thorough enough, of course). The container stuff is sadly not very well tested, and I don't have the motivation for adding to it. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] two small bugs in zc.relationship
Certainly true. I just wanted the bug fix to stay in sync with the package author's coding style. He already used logical operator magic to mimic the '?:' ternary operator in a similar method. I myself prefer boring if ... else constructs. Markus Kemmerling Am 02.07.2007 um 14:51 schrieb Stefan H. Holek: As a general rule you should avoid taking the boolean value of objects. You never know what the result will be and how expensive the underlying operations are (e.g. computing the length of a BTree can be *very* expensive). Stefan On 2. Jul 2007, at 14:24, Markus Kemmerling wrote: But I wouldn't have expected a non built-in type, that *also* supports the mapping API, to be considered as `False` as long as the mapping is empty ... -- Anything that happens, happens. --Douglas Adams ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] two small bugs in zc.relationship
As a general rule you should avoid taking the boolean value of objects. You never know what the result will be and how expensive the underlying operations are (e.g. computing the length of a BTree can be *very* expensive). Stefan On 2. Jul 2007, at 14:24, Markus Kemmerling wrote: But I wouldn't have expected a non built-in type, that *also* supports the mapping API, to be considered as `False` as long as the mapping is empty ... -- Anything that happens, happens. --Douglas Adams ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] two small bugs in zc.relationship
Markus Kemmerling wrote: But I wouldn't have expected a non built-in type, that *also* supports the mapping API, to be considered as `False` as long as the mapping is empty ... Built-in or otherwise, empty containers are almost universally "false" in Python. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] two small bugs in zc.relationship
Hi,
I discovered two smalll bugs in `zc.relationship`. The first is just
a typo in the `ManyToOneRelationship` convenience class of the
`shared`module:
@@ -149,7 +149,7 @@
interface.implements(interfaces.IManyToOneRelationship)
def __init__(self, sources, target):
-super(OneToManyRelationship, self).__init__(sources, (target,))
+super(ManyToOneRelationShip, self).__init__((sources,),
target) @apply
def sources():
The second is a little bit more subtle. The `findRelationships`
method misbehaves if both, `source` and `target`, are not None, but
`bool(target)` evaluates to False. The fix is equally easy (and
similar to the `isLinked` method):
@@ -292,7 +292,7 @@
res = self.relationIndex.findRelationshipTokenChains(
tokenize({'source': source}),
maxDepth, filter and ResolvingFilter(filter, self),
-target and tokenize({'target': target}),
+target is not None and tokenize({'target': target})
or None,
targetFilter=minDepthFilter(minDepth))
return self._forward(res)
elif target is not None:
I discovered the last one when relating to a `target` that is a full
blown Zope object but also happens to be a yet empty container. It
certainly makes sense that an empty dictionary is considered to be
`False` when converted to a boolean. But I wouldn't have expected a
non built-in type, that *also* supports the mapping API, to be
considered as `False` as long as the mapping is empty ...
Markus Kemmerling
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] namechooser : object deleted instead of being renamed
On Mon, Jun 18, 2007 at 07:22:20PM +0300, Marius Gedminas wrote: > On Mon, Jun 18, 2007 at 12:20:57PM +0200, Christophe Combelles wrote: > > Hi, > > > > I've experienced a dangerous behaviour with namechoosers : > > > > If the namechooser computes a name which is the same as the current name, > > the object is deleted! > > > > This is simple to reproduce : > > - register a name chooser that only returns "foobar" > > - create your object → ok it's name is foobar > > - from the Contents view of it's container, try to rename it (with a > > different name) > > - → deleted > > > > Someone should try to reproduce that, to be sure that's not a side effect > > of my app, but I don't think so. > > I can reproduce it with a unit test: I've added this to the bug tracker so it doesn't get lost: https://bugs.launchpad.net/zope3/+bug/123532 Marius Gedminas -- Ambition is a poor excuse for not having enough sense to be lazy. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
