So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and wanted badly to write this. if 'method' on my_object: I'm not the most experienced Python user, but as far as I can tell hasattr is the preferred way of checking if a method exists. Please correct me if there is a better way, otherwise I'd like to see what everyone thinks about an "on" statement being added to the Python language. Thanks, Rob Madole
Robert Madole wrote:
Most Python code should just assume the method is present and let the AttributeError fly if it isn't. If you genuinely need to check for presence of a method, then either catching the AttributeError or using hasattr is fine. This is a relatively rare requirement though, so the chance of getting dedicated syntax (and a new keyword, no less!) to support it is basically nil. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On 4/1/2010 11:15 AM, Robert Madole wrote:
So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and wanted badly to write this.
if 'method' on my_object:
If you do not need the superclass search provided by hasattr, if 'method' in my_object.__dict__:
'__add__' in int.__dict__ True
But I otherwise agree with Nick. Terry Jan Reedy
I think this is a great idea, but I would not want to introduce a new keyword. How about foo is in bar = hasattr(foo,bar) foo is not in bar = not hasattr(foo,bar) But there are other common checks I do all the time that I would really like to have shortcuts for. Here are ways to do them without new keywords: foo is class bar = isinstance(foo,bar) foo is from bar = issubclass(foo,bar) foo is with bar = type(foo) == type(bar) Can we make an exception to the moratorium, just for today? --- Bruce http://www.vroospeak.com On Thu, Apr 1, 2010 at 8:15 AM, Robert Madole <robmadole@gmail.com> wrote:
On Thu, Apr 01, 2010 at 11:54:53AM -0700, Bruce Leban wrote:
foo is in bar = hasattr(foo,bar)
foo is in bar is currently a valid and widely used expression. It means bar.__contains__(foo). Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Thu, Apr 01, 2010 at 03:06:18PM -0500, Robert Kern wrote:
Ah, sorry, you are right. But that shows why the proposed syntax is bad - it's too similar to an existing one. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Bruce Leban wrote:
To me, this is asking whether 'foo' is a class. Better would be: foo in class bar
foo is from bar = issubclass(foo,bar)
Perhaps: foo from class bar (although I'm not happy with it.)
foo is with bar = type(foo) == type(bar)
Can we make an exception to the moratorium, just for today?
Only for foolish ideas. :-)
I'm new to the list, so give me some time to grok why "new statement/keyword" is a Bad Idea. I'll refrain from the usual, "It's just a new statement, what's so bad about that" so you guys don't have to scold me. I suspect the reason relates to bloating the core language :D I think the in statement already hooks into __contains__. So I don't think using "foo is in bar" would work. That already exists and means something else. I forgot about the try / catch approach. I will use this, as I think it's more Pythonic? As far as using class, from, or with; overloading existing keywords seems a bit dangerous. At this point and the more I think about it, I feel pretty convinced it's a bad idea. On Apr 1, 2010, at 1:54 PM, Bruce Leban wrote:
On Thu, Apr 1, 2010 at 8:54 PM, Bruce Leban <bruce@leapyear.org> wrote:
I hope so! I'm tossing in a few more suggestions that would make some idioms more intuitive: * iterable except for item := (x for x in iterable if x!=item) * pass from iterable := for i in iterable: pass * global return value := sys.exit(value) * import obj in module as name import module setattr(module, name, obj) del module * not raise: BLOCK try: BLOCK except: pass * with x as is: BLOCK _x = deepcopy(x) try: BLOCK finally: x = _x; del _x * try for i in iterable: BLOCK1 else: BLOCK2 for i in iterable: try: BLOCK1; break except: pass else: BLOCK2 George
Am 01.04.2010 22:54, schrieb George Sakkis:
I hope so! I'm tossing in a few more suggestions that would make some idioms more intuitive:
My favorite! Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
George Sakkis, 01.04.2010 22:54:
I think this use case is important enough to implement it immediately. However, since the moratorium is currently in place for Python, would it be ok to fork Python 3 to integrate it into the language? I propose Mython as the name of the fork. I also propose to drop the entire Subversion history, so that we can start using Mercurial instantaneously. That will greatly improve the freedom of Mython as a language. Stefan
On 2010-04-04 14:17 , Stefan Behnel wrote:
The name Mython is taken: http://mython.org/ However, you can use the existing Mython to implement this syntax pretty easily. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Apr 4, 2010 at 05:35, Greg Ewing <greg.ewing@canterbury.ac.nz>wrote:
Indeed. On that note, I think I'm going to start implementing Google's recently-announced Google Annotations Gallery as Python decorators. I actually did once implement their @noop... http://google-opensource.blogspot.com/2010/03/google-annotations-gallery.htm... -- Tim Lesher <tlesher@gmail.com>
Robert Madole wrote:
Most Python code should just assume the method is present and let the AttributeError fly if it isn't. If you genuinely need to check for presence of a method, then either catching the AttributeError or using hasattr is fine. This is a relatively rare requirement though, so the chance of getting dedicated syntax (and a new keyword, no less!) to support it is basically nil. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On 4/1/2010 11:15 AM, Robert Madole wrote:
So I just wrote my 1-gazillionth "if hasattr('method', my_object):" and wanted badly to write this.
if 'method' on my_object:
If you do not need the superclass search provided by hasattr, if 'method' in my_object.__dict__:
'__add__' in int.__dict__ True
But I otherwise agree with Nick. Terry Jan Reedy
I think this is a great idea, but I would not want to introduce a new keyword. How about foo is in bar = hasattr(foo,bar) foo is not in bar = not hasattr(foo,bar) But there are other common checks I do all the time that I would really like to have shortcuts for. Here are ways to do them without new keywords: foo is class bar = isinstance(foo,bar) foo is from bar = issubclass(foo,bar) foo is with bar = type(foo) == type(bar) Can we make an exception to the moratorium, just for today? --- Bruce http://www.vroospeak.com On Thu, Apr 1, 2010 at 8:15 AM, Robert Madole <robmadole@gmail.com> wrote:
On Thu, Apr 01, 2010 at 11:54:53AM -0700, Bruce Leban wrote:
foo is in bar = hasattr(foo,bar)
foo is in bar is currently a valid and widely used expression. It means bar.__contains__(foo). Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
On Thu, Apr 01, 2010 at 03:06:18PM -0500, Robert Kern wrote:
Ah, sorry, you are right. But that shows why the proposed syntax is bad - it's too similar to an existing one. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Bruce Leban wrote:
To me, this is asking whether 'foo' is a class. Better would be: foo in class bar
foo is from bar = issubclass(foo,bar)
Perhaps: foo from class bar (although I'm not happy with it.)
foo is with bar = type(foo) == type(bar)
Can we make an exception to the moratorium, just for today?
Only for foolish ideas. :-)
I'm new to the list, so give me some time to grok why "new statement/keyword" is a Bad Idea. I'll refrain from the usual, "It's just a new statement, what's so bad about that" so you guys don't have to scold me. I suspect the reason relates to bloating the core language :D I think the in statement already hooks into __contains__. So I don't think using "foo is in bar" would work. That already exists and means something else. I forgot about the try / catch approach. I will use this, as I think it's more Pythonic? As far as using class, from, or with; overloading existing keywords seems a bit dangerous. At this point and the more I think about it, I feel pretty convinced it's a bad idea. On Apr 1, 2010, at 1:54 PM, Bruce Leban wrote:
On Thu, Apr 1, 2010 at 8:54 PM, Bruce Leban <bruce@leapyear.org> wrote:
I hope so! I'm tossing in a few more suggestions that would make some idioms more intuitive: * iterable except for item := (x for x in iterable if x!=item) * pass from iterable := for i in iterable: pass * global return value := sys.exit(value) * import obj in module as name import module setattr(module, name, obj) del module * not raise: BLOCK try: BLOCK except: pass * with x as is: BLOCK _x = deepcopy(x) try: BLOCK finally: x = _x; del _x * try for i in iterable: BLOCK1 else: BLOCK2 for i in iterable: try: BLOCK1; break except: pass else: BLOCK2 George
Am 01.04.2010 22:54, schrieb George Sakkis:
I hope so! I'm tossing in a few more suggestions that would make some idioms more intuitive:
My favorite! Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
George Sakkis, 01.04.2010 22:54:
I think this use case is important enough to implement it immediately. However, since the moratorium is currently in place for Python, would it be ok to fork Python 3 to integrate it into the language? I propose Mython as the name of the fork. I also propose to drop the entire Subversion history, so that we can start using Mercurial instantaneously. That will greatly improve the freedom of Mython as a language. Stefan
On 2010-04-04 14:17 , Stefan Behnel wrote:
The name Mython is taken: http://mython.org/ However, you can use the existing Mython to implement this syntax pretty easily. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Sun, Apr 4, 2010 at 05:35, Greg Ewing <greg.ewing@canterbury.ac.nz>wrote:
Indeed. On that note, I think I'm going to start implementing Google's recently-announced Google Annotations Gallery as Python decorators. I actually did once implement their @noop... http://google-opensource.blogspot.com/2010/03/google-annotations-gallery.htm... -- Tim Lesher <tlesher@gmail.com>
participants (12)
-
Bruce Leban -
Georg Brandl -
George Sakkis -
Greg Ewing -
MRAB -
Nick Coghlan -
Oleg Broytman -
Robert Kern -
Robert Madole -
Stefan Behnel -
Terry Reedy -
Tim Lesher