On 25 August 2010 20:57, P.J. Eby wrote:
> [snip...]
> As you can see, the __call__ attribute in each case is whatever the proxied
> object's __call__ attribute is, even though the proxy itself has a __call__
> method, that is invoked when the proxy is called.
>
> This is actually pretty straight
On 24/08/2010 08:40, Michael Foord wrote:
On 24/08/2010 01:25, Nick Coghlan wrote:
On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote:
Now, it may be worth considering an addition to the inspect module
that was basically:
def getattr_static(obj, attr):
"""Retrieve attributes without triggeri
At 08:58 PM 8/25/2010 +0300, Michael Foord wrote:
If your proxy class defines __call__ then callable returns True,
even if the delegation to the proxied object would cause an
AttributeError to be raised.
Nope. You just have to use delegate via __getattribute__ (since 2.2)
instead of __getatt
On 25/08/2010 19:27, P.J. Eby wrote:
At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote:
Consider an object that is trying to be a transparent
proxy for another object, and behave as much as possible
as though it really were the other object. Should an
attribute statically defined on the proxied obj
At 12:10 PM 8/25/2010 +1200, Greg Ewing wrote:
Consider an object that is trying to be a transparent
proxy for another object, and behave as much as possible
as though it really were the other object. Should an
attribute statically defined on the proxied object be
considered dynamically defined o
Steven D'Aprano wrote:
But that's the thing... as far as I am concerned, a dynamically defined
attribute *doesn't* exist.
Maybe for your particular use case, but the concept of
whether an attribute is dynamically defined or not is
not well-defined in general.
Consider an object that is trying
On Aug 24, 2010, at 8:31 AM, Benjamin Peterson wrote:
> 2010/8/24 Hrvoje Niksic :
>> The __length_hint__ lookup expects either no exception or AttributeError,
>> and will propagate others. I'm not sure if this is a bug. On the one hand,
>> throwing anything except AttributeError from __getattr_
At 10:13 AM 8/24/2010 -0500, Benjamin Peterson wrote:
2010/8/24 James Y Knight :
>
> On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
>
>> 2010/8/24 P.J. Eby :
>>>
>>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
a) a "business" case of throwing anything other than AttributeE
2010/8/24 James Y Knight :
>
> On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
>
>> 2010/8/24 P.J. Eby :
>>>
>>> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
a) a "business" case of throwing anything other than AttributeError from
__getattr__ and friends is almost certain
On Aug 24, 2010, at 10:26 AM, Benjamin Peterson wrote:
2010/8/24 P.J. Eby :
At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
a) a "business" case of throwing anything other than
AttributeError from
__getattr__ and friends is almost certainly a bug waiting to
happen, and
FYI, best prac
2010/8/24 R. David Murray :
> On Tue, 24 Aug 2010 09:26:09 -0500, Benjamin Peterson
> wrote:
>> 2010/8/24 P.J. Eby :
>> > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>> >>
>> >> a) a "business" case of throwing anything other than AttributeError from
>> >> __getattr__ and friends is almost
On Tue, 24 Aug 2010 09:26:09 -0500, Benjamin Peterson
wrote:
> 2010/8/24 P.J. Eby :
> > At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
> >>
> >> a) a "business" case of throwing anything other than AttributeError from
> >> __getattr__ and friends is almost certainly a bug waiting to happen, an
On Tue, Aug 24, 2010 at 4:51 AM, Steven D'Aprano wrote:
> But that's the thing... as far as I am concerned, a dynamically defined
> attribute *doesn't* exist. If it existed, __getattr__ would never be
> called. A minor semantic difference, to be sure, but it's real to me.
Eh? If "x.y" succeeds, i
On 8/24/2010 9:45 AM, Benjamin Peterson wrote:
> 2010/8/24 Hrvoje Niksic :
>> On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
>>>
>>> 2010/8/24 Hrvoje Niksic:
The __length_hint__ lookup expects either no exception or
AttributeError,
and will propagate others. I'm not sure if
2010/8/24 P.J. Eby :
> At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
>>
>> a) a "business" case of throwing anything other than AttributeError from
>> __getattr__ and friends is almost certainly a bug waiting to happen, and
>
> FYI, best practice for __getattr__ is generally to bail with an
> A
At 03:37 PM 8/24/2010 +0200, Hrvoje Niksic wrote:
a) a "business" case of throwing anything other than AttributeError
from __getattr__ and friends is almost certainly a bug waiting to happen, and
FYI, best practice for __getattr__ is generally to bail with an
AttributeError as soon as you see
2010/8/24 Hrvoje Niksic :
> On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
>>
>> 2010/8/24 Hrvoje Niksic:
>>>
>>> The __length_hint__ lookup expects either no exception or
>>> AttributeError,
>>> and will propagate others. I'm not sure if this is a bug. On the one
>>> hand,
>>> throwing anyt
On 08/24/2010 02:31 PM, Benjamin Peterson wrote:
2010/8/24 Hrvoje Niksic:
The __length_hint__ lookup expects either no exception or AttributeError,
and will propagate others. I'm not sure if this is a bug. On the one hand,
throwing anything except AttributeError from __getattr__ is bad styl
2010/8/24 Hrvoje Niksic :
> The __length_hint__ lookup expects either no exception or AttributeError,
> and will propagate others. I'm not sure if this is a bug. On the one hand,
> throwing anything except AttributeError from __getattr__ is bad style (which
> is why we fixed the bug by deriving o
On Tue, 24 Aug 2010 11:09:10 am Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 4:56 PM, Steven D'Aprano
wrote:
[...]
> > I have always thought that hasattr() does what it says on the box:
> > it tests for the *existence* of an attribute, that is, one that
> > statically exists rather than bein
On 08/23/2010 04:56 PM, Guido van Rossum wrote:
On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson wrote:
2010/8/23 Yury Selivanov:
1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow
only AttributeError exceptions (exactly like 'getattr'). Probably, Python 3.2
re
On 24/08/2010 01:25, Nick Coghlan wrote:
On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote:
Now, it may be worth considering an addition to the inspect module
that was basically:
def getattr_static(obj, attr):
"""Retrieve attributes without triggering dynamic lookup via the
descriptor p
2010/8/23 Guido van Rossum :
> Yuri, I think you are making a good case (though I would like for you
> to be a good citizen and use the bug tracker to submit this for
> review). Benjamin, what do you think?
I will have a look right now.
--
Regards,
Benjamin
> On 2010-08-23, at 10:37 PM, Guido van Rossum wrote:
> Yuri, I think you are making a good case (though I would like for you
> to be a good citizen and use the bug tracker to submit this for
> review). Benjamin, what do you think?
NP, issue #9666 ;-)
-
Yury
__
Yuri, I think you are making a good case (though I would like for you
to be a good citizen and use the bug tracker to submit this for
review). Benjamin, what do you think?
--Guido
On Mon, Aug 23, 2010 at 7:14 PM, Yury Selivanov wrote:
>> On 2010-08-23, at 10:56 AM, Guido van Rossum wrote:
>> On
> On 2010-08-23, at 10:56 AM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson
> wrote:
>> 2010/8/23 Yury Selivanov :
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to
>>> swallow only AttributeError exceptions (exactly like 'getattr'). Probabl
On Mon, Aug 23, 2010 at 4:56 PM, Steven D'Aprano wrote:
> On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
>
>> > * Is there anything that hasattr(obj, key) can or should do that
>> > can't already be done with getattr(obj, key, None)?
>> > If not, do we really need to change anything?
On Mon, Aug 23, 2010 at 17:04, Benjamin Peterson wrote:
> 2010/8/23 Steven D'Aprano :
>> On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
>>
>>> > * Is there anything that hasattr(obj, key) can or should do that
>>> > can't already be done with getattr(obj, key, None)?
>>> > If not, do
2010/8/23 Steven D'Aprano :
> On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
>
>> > * Is there anything that hasattr(obj, key) can or should do that
>> > can't already be done with getattr(obj, key, None)?
>> > If not, do we really need to change anything?
>>
>> getattr(obj, 'key', Non
On Tue, 24 Aug 2010 06:50:19 am Guido van Rossum wrote:
> > * Is there anything that hasattr(obj, key) can or should do that
> > can't already be done with getattr(obj, key, None)?
> > If not, do we really need to change anything?
>
> getattr(obj, 'key', None) returns None when obj.key exists
Michael Foord wrote:
It would be backwards incompatible with usage of hasattr for dynamically
created 'members' using __getattr__ though.
Also keep in mind that builtin types mostly don't keep
their attributes in dictionaries. To make this work
properly, hasattr would need its own special meth
On Mon, Aug 23, 2010 at 3:45 PM, P.J. Eby wrote:
> At 06:12 PM 8/23/2010 -0400, Yury Selivanov wrote:
>>
>> BTW, is it possible to add new magic method __hasattr__? Maybe not
>> in Python 3.2, but in general.
>
> In order to do this properly, you'd need to also add __has__ or __exists__
> (or som
On Aug 23, 2010, at 03:45 PM, Benjamin Peterson wrote:
>It's generally more convenient that getattr(obj, "blah", None) is not
>None.
Clearly, the solution is a new builtin called 'Missing'.
-Barry
signature.asc
Description: PGP signature
___
Python-
At 06:12 PM 8/23/2010 -0400, Yury Selivanov wrote:
BTW, is it possible to add new magic method __hasattr__? Maybe not
in Python 3.2, but in general.
In order to do this properly, you'd need to also add __has__ or
__exists__ (or some such) to the descriptor protocol; otherwise you
break descr
On Tue, Aug 24, 2010 at 8:25 AM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov :
>> So, the proposed magic method is not intended to change the protocol,
>> but to complement and enhance it.
>
> But it still raises the potential to break the relationship between
> hasattr and getattr.
>
> I
At 12:02 AM 8/24/2010 +0300, Michael Foord wrote:
For properties there is *no reason* why code should be executed
merely in order to discover if the attribute exists or not.
That depends on what you mean by "exists". Note that a property
might raise AttributeError to signal that the attribute
On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote:
> Now, it may be worth considering an addition to the inspect module
> that was basically:
>
> def getattr_static(obj, attr):
> """Retrieve attributes without triggering dynamic lookup via the
> descriptor protocol,
> __getattr__ or __
2010/8/23 Yury Selivanov :
>> On 2010-08-23, at 6:17 PM, Benjamin Peterson wrote:
>> 2010/8/23 Yury Selivanov :
On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov
wrote:
>>> BTW, is it possible to add new magic method __hasattr__? Ma
> On 2010-08-23, at 6:17 PM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov :
>>> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
>>> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov
>>> wrote:
>> BTW, is it possible to add new magic method __hasattr__? Maybe not
>> in Python 3.2, but in
On Tue, Aug 24, 2010 at 7:49 AM, Michael Foord
wrote:
> Certainly that is true for len. getattr obviously involves invoking code if
> you are fetching a property or descriptor. No idea how you conclude that
> hasattr executing code adds flexibility to the language though.
Proxy objects like the o
2010/8/23 Yury Selivanov :
>> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
>> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov wrote:
> BTW, is it possible to add new magic method __hasattr__? Maybe not
> in Python 3.2, but in general.
-1 The whole point of hasattr() is that getattr() on th
On Tue, Aug 24, 2010 at 7:40 AM, Nick Coghlan wrote:
>> Properties are allowed to do whatever the heck they want. That doesn't mean
>> that you have to execute code to determine whether they exist or not.
>
> If you don't want to execute properties, do the lookup on the type,
> not the instance (o
> On 2010-08-23, at 6:00 PM, Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov wrote:
>> As I understand the only possible way to make 'hasattr' work as it name
>> indicates (i.e. just check if attribute exists, not run it), is to add
>> another magic method(s?) to the ex
On Mon, Aug 23, 2010 at 2:22 PM, Yury Selivanov wrote:
> As I understand the only possible way to make 'hasattr' work as it name
> indicates (i.e. just check if attribute exists, not run it), is to add
> another magic method(s?) to the existing __getattr__ and __getattribute__
> which will tell
2010/8/23 Michael Foord :
> On 24/08/2010 00:40, Nick Coghlan wrote:
>>>
>>> Properties are allowed to do whatever the heck they want. That doesn't
>>> mean
>>> that you have to execute code to determine whether they exist or not.
>>
>> If you don't want to execute properties, do the lookup on the
On 24/08/2010 00:40, Nick Coghlan wrote:
Properties are allowed to do whatever the heck they want. That doesn't mean
that you have to execute code to determine whether they exist or not.
If you don't want to execute properties, do the lookup on the type,
not the instance (obviously, you know th
> Properties are allowed to do whatever the heck they want. That doesn't mean
> that you have to execute code to determine whether they exist or not.
If you don't want to execute properties, do the lookup on the type,
not the instance (obviously, you know the dance you need to do, since
you've lin
On 2010-08-23, at 5:22 PM, Yury Selivanov wrote:
> On 2010-08-23, at 5:02 PM, Michael Foord wrote:
>
>> On 23/08/2010 23:55, Benjamin Peterson wrote:
>>> 2010/8/23 Raymond Hettinger:
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
> 2010/8/23 Michael Foord:
>> To me hasat
On 2010-08-23, at 5:02 PM, Michael Foord wrote:
> On 23/08/2010 23:55, Benjamin Peterson wrote:
>> 2010/8/23 Raymond Hettinger:
>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>
2010/8/23 Michael Foord:
> To me hasattr *looks* like a passive introspection function, and the fa
2010/8/23 Michael Foord :
> Properties are allowed to do whatever the heck they want. That doesn't mean
> that you have to execute code to determine whether they exist or not.
I thought you were trying to determine whether the attribute exists
not the property.
>
> If fetching an attribute raises
On 24/08/2010 00:05, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
On 23/08/2010 23:55, Benjamin Peterson wrote:
2010/8/23 Raymond Hettinger:
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
To me hasattr *looks* like a passive introspection function, an
2010/8/23 Michael Foord :
> On 23/08/2010 23:55, Benjamin Peterson wrote:
>>
>> 2010/8/23 Raymond Hettinger:
>>>
>>> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>>>
2010/8/23 Michael Foord:
>
> To me hasattr *looks* like a passive introspection function, and the
> fact
>
On 23/08/2010 23:55, Benjamin Peterson wrote:
2010/8/23 Raymond Hettinger:
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
To me hasattr *looks* like a passive introspection function, and the fact
that it can trigger arbitrary code execution is unfortunate - es
2010/8/23 Guido van Rossum :
> Changing C APIs is even harder than changing Python API because you
> can't add exceptions to something that wasn't returning exceptions
> before. We did that for comparisons in the past and it was a pain (but
> worth it). For these two little APIs I think it is not w
On Mon, Aug 23, 2010 at 1:50 PM, Raymond Hettinger
wrote:
>
> On Aug 23, 2010, at 1:45 PM, Benjamin Peterson wrote:
>
> > 2010/8/23 Raymond Hettinger :
> >>
> >> P.S. The current behavior seems to be deeply embedded:
> >
> > Well, that's what happens when a behavior is added in 1990. :)
>
> More
2010/8/23 Raymond Hettinger :
>
> On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
>
>> 2010/8/23 Michael Foord :
>>> To me hasattr *looks* like a passive introspection function, and the fact
>>> that it can trigger arbitrary code execution is unfortunate - especially
>>> because a full workar
On 23/08/2010 23:13, Benjamin Peterson wrote:
2010/8/23 Michael Foord:
To me hasattr *looks* like a passive introspection function, and the fact
that it can trigger arbitrary code execution is unfortunate - especially
because a full workaround is pretty arcane.
That's the danger of a dynamic l
On 2010-08-23, at 4:33 PM, Raymond Hettinger wrote:
>
> On Aug 23, 2010, at 1:03 PM, Guido van Rossum wrote:
>
>>> But hasattr() has a far different set of use cases, so we should explore
>>> an alternate solution to the problem. The usual reason that people use
>>> hasattr() instead of getattr(
On Mon, Aug 23, 2010 at 1:33 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> I don't have a specific proposal in mind.
>
That's why I called it scope creep. :-) Trust me, your proposal will not
lead to a quick and better replacement for hasattr(). (See several other
people's replie
On Aug 23, 2010, at 1:45 PM, Benjamin Peterson wrote:
> 2010/8/23 Raymond Hettinger :
>>
>> P.S. The current behavior seems to be deeply embedded:
>
> Well, that's what happens when a behavior is added in 1990. :)
More generally: it is an API code smell whenever documentation
promises some
On Aug 23, 2010, at 1:13 PM, Benjamin Peterson wrote:
> 2010/8/23 Michael Foord :
>> To me hasattr *looks* like a passive introspection function, and the fact
>> that it can trigger arbitrary code execution is unfortunate - especially
>> because a full workaround is pretty arcane.
Well said. Th
2010/8/23 Raymond Hettinger :
> I don't have a specific proposal in mind. My main questions are
> * Is there anything that hasattr(obj, key) can or should do that
> can't already be done with getattr(obj, key, None)?
> If not, do we really need to change anything?
For one, it's annoying when
On Aug 23, 2010, at 1:03 PM, Guido van Rossum wrote:
>> But hasattr() has a far different set of use cases, so we should explore
>> an alternate solution to the problem. The usual reason that people use
>> hasattr() instead of getattr() is that they want to check for the presence of
>> of a meth
2010/8/23 Guido van Rossum :
> The main problem I can see with letting exceptions other than
> AttributeError bubble through (besides perverted dependencies on the
> current semantics) is that there are some situations where it is
> pretty arbitrary whether TypeError or AttributeError is raised. I
2010/8/23 Michael Foord :
> To me hasattr *looks* like a passive introspection function, and the fact
> that it can trigger arbitrary code execution is unfortunate - especially
> because a full workaround is pretty arcane.
That's the danger of a dynamic language like Python. Even dir() can
now tri
On 23/08/2010 22:59, Benjamin Peterson wrote:
[snip...]
IMO, this is a much better solution, more in line with known use cases
for hasattr(). If the proposed change when through, it would fail to
address the common use case and cause people to start writing their
own versions of hasattr() tha
On Mon, Aug 23, 2010 at 12:47 PM, Raymond Hettinger
wrote:
>
> On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
>
>> I know the issue has been discussed several times already, however I
>> couldn't find any reasonable explanation of its strange behaviour. The main
>> problem with 'hasattr' fu
On 2010-08-23, at 3:47 PM, Raymond Hettinger wrote:
>
> On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
>
>> I know the issue has been discussed several times already, however I
>> couldn't find any reasonable explanation of its strange behaviour. The main
>> problem with 'hasattr' functio
At 12:47 PM 8/23/2010 -0700, Raymond Hettinger wrote:
As your example shows, property() defeats this intent by actually executing
the code. A better behavior would not run the code at all. It would check
the dictionaries along the MRO but not execute any descriptors associated
with a given key
2010/8/23 Raymond Hettinger :
> Thanks for the nice analysis and good example.
>
> I disagree with the solution though. If we want to see the exceptions
> associated
> with actually getting an attribute, then using getattr() instead is a
> perfectly
> reasonable solution that people can already
On 23/08/2010 22:47, Raymond Hettinger wrote:
On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
I know the issue has been discussed several times already, however I couldn't
find any reasonable explanation of its strange behaviour. The main problem
with 'hasattr' function is that is swallo
On Aug 23, 2010, at 7:22 AM, Yury Selivanov wrote:
> I know the issue has been discussed several times already, however I couldn't
> find any reasonable explanation of its strange behaviour. The main problem
> with 'hasattr' function is that is swallows all exceptions derived from
> Exception
On 8/23/2010 10:22 AM, Yury Selivanov wrote:
1) I propose to change 'hasattr' behaviour in Python 3, making it to
swallow only AttributeError exceptions (exactly like 'getattr').
Probably, Python 3.2 release is our last chance.
I gather that this amounts to changing "an exception" to
"Attribu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson
> wrote:
>> 2010/8/23 Yury Selivanov :
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to
>>> swallow only AttributeError exceptions (exactly like 'ge
2010/8/23 Guido van Rossum :
> On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson
> wrote:
>> 2010/8/23 Yury Selivanov :
>>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to
>>> swallow only AttributeError exceptions (exactly like 'getattr'). Probably,
>>> Python 3.2 releas
On Mon, Aug 23, 2010 at 7:46 AM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov :
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow
>> only AttributeError exceptions (exactly like 'getattr'). Probably, Python
>> 3.2 release is our last chance.
>
> I would be i
On 2010-08-23, at 10:46 AM, Benjamin Peterson wrote:
> 2010/8/23 Yury Selivanov :
>> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow
>> only AttributeError exceptions (exactly like 'getattr'). Probably, Python
>> 3.2 release is our last chance.
>
> I would be in su
2010/8/23 Yury Selivanov :
> 1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow
> only AttributeError exceptions (exactly like 'getattr'). Probably, Python
> 3.2 release is our last chance.
I would be in support of that.
>
> 2) If you afraid that this new behaviour wi
78 matches
Mail list logo
