Finding an object in a folder
Here is the problem. I want to use a form to upload a file (with a specific name) but first I want to check if another file with the same name already exist in that folder. How do I use a if or dtml-if to solve this problem?? --------------------------------- Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard.
Allen Huang wrote at 2005-5-8 02:28 -0700:
Here is the problem. I want to use a form to upload a file (with a specific name) but first I want to check if another file with the same name already exist in that folder. How do I use a if or dtml-if to solve this problem??
<dtml-if expr="hasattr(the_folder.aq_inner.aq_explicit, the_id)"> "the_id" exists <dtml-else> "the_id" does not exist </dtml-if> -- Dieter
Dieter Maurer wrote:
Allen Huang wrote at 2005-5-8 02:28 -0700:
Here is the problem. I want to use a form to upload a file (with a specific name) but first I want to check if another file with the same name already exist in that folder. How do I use a if or dtml-if to solve this problem??
<dtml-if expr="hasattr(the_folder.aq_inner.aq_explicit, the_id)"> "the_id" exists <dtml-else> "the_id" does not exist </dtml-if>
Dieter, I'm shocked ;-) Why in DTML? Even though Allen mentions DTML, this never belongs in DTML. Worse still, you use hasattr with ZODB... hastattr swallows all exceptions, including ConflictErrors, and especially in this example that would be a bad thing... if getattr(thefolder.aq_inner.aq_explicit,the_id,None): print the_id + ' is in use' else: print the_id + ' is in use' return printed cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2005-5-23 20:02 +0100:
Dieter Maurer wrote:
Here is the problem. I want to use a form to upload a file (with a specific name) but first I want to check if another file with the same name already exist in that folder. How do I use a if or dtml-if to solve this problem??
<dtml-if expr="hasattr(the_folder.aq_inner.aq_explicit, the_id)"> "the_id" exists <dtml-else> "the_id" does not exist </dtml-if>
Dieter, I'm shocked ;-)
Why in DTML? Even though Allen mentions DTML, this never belongs in DTML.
We are already familiar with the fact that we often disagree. This is another case. The test whether an object exists is sufficiently trivial (and often needed) that it can be in DTML without a problem. An incredibly long time ago, I filed a feature request for "hasattr_unacquired" -- together with patch, unit tests and documentation update. I am convinced that such a function in the DTML namespace (and therefore always available in restricted code) would be much clearer than the "aq_inner.aq_explicit" dance. But, unfortunately, the Zope developers decided not to accept my patch or the "hasattr_unacquired" idea and instead made "aq_inner" accessible by untrusted code. A bad decision! As a consequence, you see the nasty code. By the way, it is as nasty in Python as it is in DTML.
Worse still, you use hasattr with ZODB... hastattr swallows all exceptions, including ConflictErrors, and especially in this example that would be a bad thing...
Again, the correct way to approach this problem is not to ban "hasattr" from thousands of places but to monkey patch "__builtin__.hasattr" such that it behaves in a Zope compatible way. I have seen several severely broken trial to work around the use of "hasattr" -- by Zope experts not Zope newbies. I strongly argue against it. Fix "hasattr" in the Zope context, instead!
if getattr(thefolder.aq_inner.aq_explicit,the_id,None):
You are aware that this is in general *NOT* an emulation of "hasattr". It may fail e.g. for properties. Such half faithful "hasattr" emulations will make more problems then even the unfixed "hasattr" use. And it would be so easy to fix "hasattr" ;-) -- Dieter
Dieter Maurer wrote:
By the way, it is as nasty in Python as it is in DTML.
I agree with we disagree, I hopethat doesn't cause offence ;-)
Worse still, you use hasattr with ZODB... hastattr swallows all exceptions, including ConflictErrors, and especially in this example that would be a bad thing...
Again, the correct way to approach this problem is not to ban "hasattr" from thousands of places but to monkey patch "__builtin__.hasattr" such that it behaves in a Zope compatible way.
It doesn't matter what is correct and what isn't correct here, you're handing out advice that will break when a person tries it and they least expect it to break. That's not a nice thing to do...
I strongly argue against it. Fix "hasattr" in the Zope context, instead!
Make it so! :-)
if getattr(thefolder.aq_inner.aq_explicit,the_id,None):
You are aware that this is in general *NOT* an emulation of "hasattr".
I didn't say it was ;-)
It may fail e.g. for properties.
How would it fail for properties?
And it would be so easy to fix "hasattr" ;-)
then why haven't you done it? ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wed, May 25, 2005 at 09:03:13PM +0100, Chris Withers wrote:
if getattr(thefolder.aq_inner.aq_explicit,the_id,None):
You are aware that this is in general *NOT* an emulation of "hasattr".
I didn't say it was ;-)
It may fail e.g. for properties.
How would it fail for properties?
Well, it doesn't distinguish between an attribute which doesn't exist and an attribute which has any false value. This makes it unsuitable as a hasattr() replacement IMHO. It feels kind of hacky, but for this kind of thing I've used the "marker" pattern that you find throughout the Zope source: marker = () if getattr(some_object, marker) is not marker: ... -- Paul Winkler http://www.slinkp.com
Well, it doesn't distinguish between an attribute which doesn't exist and an attribute which has any false value. This makes it unsuitable as a hasattr() replacement IMHO.
But you're asking if the object posesses an attribute, not any question about the value of the object. I think returning false if the value is false is potentially dangerous - I may want to retrieve a false value. -- Phillip Hutchings http://www.sitharus.com/ sitharus@gmail.com / sitharus@sitharus.com
On Fri, May 27, 2005 at 09:20:52AM +1200, Phillip Hutchings wrote:
Well, it doesn't distinguish between an attribute which doesn't exist and an attribute which has any false value. This makes it unsuitable as a hasattr() replacement IMHO.
But you're asking if the object posesses an attribute, not any question about the value of the object. I think returning false if the value is false is potentially dangerous - I may want to retrieve a false value.
"But" what? You just said the same thing that I said :-) -- Paul Winkler http://www.slinkp.com
On 27/05/05, Paul Winkler <pw_lists@slinkp.com> wrote:
On Fri, May 27, 2005 at 09:20:52AM +1200, Phillip Hutchings wrote:
Well, it doesn't distinguish between an attribute which doesn't exist and an attribute which has any false value. This makes it unsuitable as a hasattr() replacement IMHO.
But you're asking if the object posesses an attribute, not any question about the value of the object. I think returning false if the value is false is potentially dangerous - I may want to retrieve a false value.
"But" what? You just said the same thing that I said :-)
Sorry, shouldn't reply to things at 9am ;) Anyway, I agree with you, it is broken as the distinction is critical. -- Phillip Hutchings http://www.sitharus.com/ sitharus@gmail.com / sitharus@sitharus.com
Paul Winkler wrote:
marker = () if getattr(some_object, marker) is not marker:
For good measure, I wonder if that should be a [], no a ()? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Fri, May 27, 2005 at 08:51:58AM +0100, Chris Withers wrote:
Paul Winkler wrote:
marker = () if getattr(some_object, marker) is not marker:
For good measure, I wonder if that should be a [], no a ()?
What's wrong with a tuple? There's no reason to mutate the marker. -- Paul Winkler http://www.slinkp.com
Paul Winkler <pw_lists@slinkp.com> wrote:
On Fri, May 27, 2005 at 08:51:58AM +0100, Chris Withers wrote:
Paul Winkler wrote:
marker = () if getattr(some_object, marker) is not marker:
For good measure, I wonder if that should be a [], no a ()?
What's wrong with a tuple? There's no reason to mutate the marker.
The whole point of a marker is that it is unique, so cannot be confused with a legitimate value of the object examined. And all empty tuples are equal. In python 2.3, the idiom most commonly found is to use marker = object(). Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
On Fri, May 27, 2005 at 01:58:44PM +0200, Florent Guillaume wrote:
And all empty tuples are equal.
Not just equal, but all empty tuples are *identical*, so () is () == True. I had no idea this was so :-\
In python 2.3, the idiom most commonly found is to use marker = object().
Thanks for that. -- Paul Winkler http://www.slinkp.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Winkler wrote:
On Fri, May 27, 2005 at 08:51:58AM +0100, Chris Withers wrote:
Paul Winkler wrote:
marker = () if getattr(some_object, marker) is not marker:
For good measure, I wonder if that should be a [], no a ()?
What's wrong with a tuple? There's no reason to mutate the marker.
In Python, there is only empty tuple object, while each empty list is a distinct object. For use as a marker, the empty list can't return a false positive, while the empty tuple can. Tres. - -- =================================================================== Tres Seaver tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClw9J+gerLs4ltQ4RAtyCAJ4y+h+rDtSmo+Sa2n5K+h87z/24DwCgwBFY 9Wrhk9aGMBUPm1DxsOpewec= =O5re -----END PGP SIGNATURE-----
Paul Winkler wrote at 2005-5-27 05:07 -0400:
... What's wrong with a tuple? There's no reason to mutate the marker.
The Python spec allows implementations to identify immutable objects with the same value. Thus, in principle, two "()" created at different times can in fact be the same object. This would violate our use as a marker. Python specifies that mutable objects created at different times are garanteed to be different (as long as both exist). Therefore, you can use them safely as markers. -- Dieter
Chris Withers wrote at 2005-5-25 21:03 +0100:
...
I strongly argue against it. Fix "hasattr" in the Zope context, instead!
Make it so! :-)
_marker = [] def hasattr(obj, attr, marker): a = getattr(obj, attr, _marker) return a is not _marker import __builtin__ __builtin__.hasattr = hasattr Easy enough, isn't it? Way easier than to change "hasattr" anywhere it is now used. Now, there need only to be someone who checks it in.
if getattr(thefolder.aq_inner.aq_explicit,the_id,None):
You are aware that this is in general *NOT* an emulation of "hasattr".
I didn't say it was ;-)
It may fail e.g. for properties.
How would it fail for properties?
It fails for everything with a false value (None, 0, '', [], ...). Properties may have a false value.
And it would be so easy to fix "hasattr" ;-)
then why haven't you done it? ;-)
I do not have write access to the Zope repository (because ZC requires full patent indemnification to grant it and I am unwilling to promise this). -- Dieter
On Thursday 26 May 2005 02:52 pm, Dieter Maurer wrote:
Chris Withers wrote at 2005-5-25 21:03 +0100:
...
I strongly argue against it. Fix "hasattr" in the Zope context, instead!
Make it so! :-)
I'd add the ability to turn on/off acquisition (off by default, import aq_base somewhere above), and get rid of the required marker parameter: _marker = [] def hasattr(obj, attr, acquire=False): if not acquire: obj = aq_base(obj) a = getattr(obj, attr, _marker) return a is not _marker import __builtin__ __builtin__.hasattr = hasattr
Easy enough, isn't it?
Way easier than to change "hasattr" anywhere it is now used.
Now, there need only to be someone who checks it in.
This would be lovely. :-) Alec
On Thu, May 26, 2005 at 11:52:36PM +0200, Dieter Maurer wrote:
Chris Withers wrote at 2005-5-25 21:03 +0100:
...
I strongly argue against it. Fix "hasattr" in the Zope context, instead!
Make it so! :-)
_marker = [] def hasattr(obj, attr, marker): a = getattr(obj, attr, _marker) return a is not _marker
import __builtin__ __builtin__.hasattr = hasattr
Easy enough, isn't it?
Are you currently running zope with a patch like this? Have you noticed any performance difference? the zope 2.6 source code contains over 700 calls to hasattr()...
Now, there need only to be someone who checks it in.
Well, first I think it should be discussed on zope-dev... unless it already has been? I'll post a message there. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2005-5-26 19:57 -0400:
...
Make it so! :-)
_marker = [] def hasattr(obj, attr, marker):
I introduced a bug here (noticed by "Alec Mitchell"). The "marker" argument should have been "_marker=_marker".
... Are you currently running zope with a patch like this?
No, because I never really met an "hasattr" bug (although I acknowledge that it may happen).
Have you noticed any performance difference? the zope 2.6 source code contains over 700 calls to hasattr()...
We replace a small C-implemented function with a small Python one. Although the Python function may be about 10 times slower, the overall effect is almost surely negligible. A higher risk comes from the fact that some Python packages may rely on the broken "hasattr" behaviour. That's the reason why the problem is not fixed in Python itself. -- Dieter
On Fri, May 27, 2005 at 03:26:04PM +0200, Dieter Maurer wrote:
A higher risk comes from the fact that some Python packages may rely on the broken "hasattr" behaviour. That's the reason why the problem is not fixed in Python itself.
And that's a very good reason not to monkeypatch it. We can't have arbitrary third-party packages breaking when they are used with Zope. Such bugs could be maddeningly difficult to diagnose and find. Anyway, Jim has made a papal edict on zope-dev: We will never monkeypatch hasattr in the zope core. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2005-5-27 11:08 -0400:
On Fri, May 27, 2005 at 03:26:04PM +0200, Dieter Maurer wrote:
A higher risk comes from the fact that some Python packages may rely on the broken "hasattr" behaviour. That's the reason why the problem is not fixed in Python itself.
And that's a very good reason not to monkeypatch it. We can't have arbitrary third-party packages breaking when they are used with Zope. Such bugs could be maddeningly difficult to diagnose and find.
Anyway, Jim has made a papal edict on zope-dev: We will never monkeypatch hasattr in the zope core.
But hopefully we will get a decent "safe_hasattr" (or similar), get it used at least in all Zope core code, rather than that each of the 700 occurrencies tries its own "hasattr" emulation via "getattr". -- Dieter
On Saturday 28 May 2005 01:26 am, Dieter Maurer wrote:
Paul Winkler wrote at 2005-5-27 11:08 -0400:
On Fri, May 27, 2005 at 03:26:04PM +0200, Dieter Maurer wrote:
A higher risk comes from the fact that some Python packages may rely on the broken "hasattr" behaviour. That's the reason why the problem is not fixed in Python itself.
And that's a very good reason not to monkeypatch it. We can't have arbitrary third-party packages breaking when they are used with Zope. Such bugs could be maddeningly difficult to diagnose and find.
Anyway, Jim has made a papal edict on zope-dev: We will never monkeypatch hasattr in the zope core.
But hopefully we will get a decent "safe_hasattr" (or similar), get it used at least in all Zope core code, rather than that each of the 700 occurrencies tries its own "hasattr" emulation via "getattr".
Well, Plone at least has one for 2.1 until zope gets one: from Products.CMFPlone import shasattr also: from Products.CMFPlone import safe_callable shasattr is essentially a copy of the AT one, but is importable into trusted. code. Alec
On Tue, May 24, 2005 at 08:59:01PM +0200, Dieter Maurer wrote:
An incredibly long time ago, I filed a feature request for "hasattr_unacquired" -- together with patch, unit tests and documentation update.
Do you mean this? http://www.zope.org/Collectors/Zope/742 the unit tests and docs are missing. But I like the idea. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2005-5-27 16:28 -0400:
On Tue, May 24, 2005 at 08:59:01PM +0200, Dieter Maurer wrote:
An incredibly long time ago, I filed a feature request for "hasattr_unacquired" -- together with patch, unit tests and documentation update.
Do you mean this? http://www.zope.org/Collectors/Zope/742
Probably.
the unit tests and docs are missing.
In what almost surely was the source for the patch, I see: --- Products/OFSP/help/dtml-funcs.stx~ 2002-01-09 18:44:05.000000000 +0100 +++ Products/OFSP/help/dtml-funcs.stx 2002-12-21 16:19:49.000000000 +0100 @@ -55,6 +55,9 @@ getattr(object, name) and seeing whether it raises an exception or not.) + hasattr_unacquired(object, string) -- like "hasattr" but only + unacquired attributes are taken into account. + hash(object) -- Return the hash value of the object (if it has one). Hash values are integers. They are used to quickly compare dictionary keys during a dictionary lookup. Numeric values that compare I.e. the description of "hasattr_unacquired" for Zope's embedded online help (the only docs Zope contains itself). Indeed, I did the unit test extension only later (and only to prevent the test suite to fail -- I trusted my 3 line extension :-). I added to ".../AccessControl/tests/actual_python.py": # After all the above, these wrappers were still untouched: # ['DateTime', '_print_', 'reorder', 'same_type', 'test'] + # DM 2004-07-09: 'hasattr_unacquired' untouched, too # So do something to touch them. def f9(): + # DM 2004-07-09: 'hasattr_unacquired'... + class C: x=1 + c = C() + assert hasattr_unacquired(c,'x') + assert not hasattr_unacquired(c,'xx') d = DateTime() A more elaborate test would add: from ExtensionClass import Base from Acquisition import Implicit class B(Base): x=1 class C(Implicit): y=1 c = C().__of__(B()) assert not hasattr_unacquired(c, 'x') assert hasattr_unacquired(c, 'y') -- Dieter
participants (8)
-
Alec Mitchell -
Allen Huang -
Chris Withers -
Dieter Maurer -
Florent Guillaume -
Paul Winkler -
Phillip Hutchings -
Tres Seaver