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, 23 Aug 2010 15:13:34 +0100, Mark Lawrence
wrote:
> Suffering from dead parrot syndrome? Kiss of life please :)
The hosting company has been notified.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
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
Hello,
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 class. It's a good thing that it doesn't do that wi
Suffering from dead parrot syndrome? Kiss of life please :)
Kindest regards.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
59 matches
Mail list logo
