Re: Making every no-arg method a property?
On 8/6/2014 6:09 AM, alister wrote: On Wed, 06 Aug 2014 10:34:04 +1200, Gregory Ewing wrote: Grant Edwards wrote: Did I miss a news story? Have the parentesis mines all exploded causing the price of parenthesis to skyrocket? The Unicode Consortium has been secretly buying them up for some time now. Pretty soon you won't be able to get cheap ASCII parentheses any more, only the fancy high-priced ones like U+2045/U+2046, U+2772/U+2773 and U+27E6/U+27E7. Perhaps that will make JMF rich enough to retire ;-) Gratuitous personal digs are disrespectful and out of place on this list, especially when the target has not even participated in the thread. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, 6 Aug 2014 05:13:07 + (UTC) Grant Edwards wrote: > On 2014-08-05, Gregory Ewing wrote: > > Grant Edwards wrote: > >> Did I miss a news story? Have the parentesis mines all exploded > >> causing the price of parenthesis to skyrocket? > > > > The Unicode Consortium has been secretly buying them > > up for some time now. Pretty soon you won't be able > > to get cheap ASCII parentheses any more, only the > > fancy high-priced ones like U+2045/U+2046, > > U+2772/U+2773 and U+27E6/U+27E7. > > Damn. Time to buy some options... > > -- > Grant > No, no. Options use up commas, not parentheses. Maybe equals signs if you're feeling particularly verbose. Clearly there's a market for some sort of well-diversified punctuation fund. The only problem becomes listing it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, Aug 6, 2014 at 7:15 PM, Steven D'Aprano wrote: > On Wed, 06 Aug 2014 12:07:58 +1000, Chris Angelico wrote: > >> On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano >> wrote: >>> A >>> plethora of argument-less methods is a code smell -- that doesn't mean >>> it's *necessarily* a bad idea, but the class design really needs a >>> careful review. >> >> There are plenty of no-argument mutator methods, where the name of the >> method (and the target object, obviously) is all the info you need. You >> can clear() or copy() something with any more info, reverse() a list, >> pop() from a list, etc. > > They don't have to be mutator methods. The same applies to string methods > like upper(), lower(), isalpha() and many others. > > I'm not sure if you're agreeing or disagreeing with me. Agreeing with your primary point, disagreeing with this subpoint. > All these > examples shouldn't be treated as properties either. This should be > grounds for being slapped with a large herring: > > mydict.clear # returns None, operates by side-effect Wholeheartedly agree. These should NOT be properties. A property should not mutate state, normally (I can imagine exceptions, but they are *definitely* code smell, unless they're doing basic logging or something). What I disagree with is that argument-less methods, even a plethora thereof, are *themselves* code smell. Mutator methods, and the string methods that construct a "this string only different" result (which in many ways are the immutable object's equivalent of mutators), will often take no args, and are most definitely not properties, but IMO aren't code smell. Something like isalpha() is borderline, but making upper() a property implies that, conceptually, the upper-case version of a string is an attribute the string already has, rather than something that you construct from that string. It's debatable, but IMO it makes perfect sense to keep that as a method - and it's fine for it to take no args other than the object it's working on. > As I said, zero-argument (one-argument, if you count self) > methods are a code smell, not an error. As is so often the case in > programming, the fundamental sin here is *coupling* -- zero-argument > methods are bad if they require coupling to temporary attributes which > exist only to communicate an argument to the method. > > In other words, one of the sins of zero-argument methods is the same as > that of zero-argument functions. We wouldn't write this: > > def double(): > return number_to_operate_on*2 > > number_to_operate_on = 23 > print double() > number_to_operate_on = 42 > print double() > > > Turning it into a method on an instance, and turning the global into a > "per instance global" (instead of per module, or application-wide) > doesn't make it any better. But if it were written as: class float(float): pass # allow more attributes on float def double(self): return self*2 float.double = double number = float(23) print(number.double()) Then it's not hidden global state any more, but it's still a zero-argument method. Is that really just as bad? Surely it's the same as "print(double(number))"? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Tue, 05 Aug 2014 12:39:18 -0700, Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning > ruby. > I like that in ruby I don't have to type parenthesis at the end of each > function call if I don't need to provide extra arguments. I just > realized right now that I can do something similar in python, if I make > all methods with only the implicitly passed 'self' into properties. > Which means I can either do some fancy coding and make a metaclass that > does this auto-magically, or I have to have property decorators all over > the place :-P . I was wondering what other thought of this, is it an > overly fanciful way of coding python, or is it an acceptable thing to do > in a real project? > Also, would anyone be interested in helping me make this metaclass? > I have been using python for 4 years now, and I just > started learning ruby. I like that in ruby I don't have to type > parenthesis at the end of each function call if I don't need to > provide extra arguments. I just realized right now that I can do > something similar in python, if I make all methods with only the > implicitly passed 'self' into properties. Which means I can > either do some fancy coding and make a metaclass that does this > auto-magically, or I have to have property decorators all over the place > :-P . I was wondering what other thought of this, is it an overly > fanciful way of coding python, or is it an acceptable thing to do in a > real project? Also, would anyone be interested in helping me make this > metaclass? import this Special Cases are not special enough This is a horrible idea for python code -- Once is happenstance, Twice is coincidence, Three times is enemy action. -- Auric Goldfinger -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, 06 Aug 2014 10:34:04 +1200, Gregory Ewing wrote: > Grant Edwards wrote: >> Did I miss a news story? Have the parentesis mines all exploded >> causing the price of parenthesis to skyrocket? > > The Unicode Consortium has been secretly buying them up for some time > now. Pretty soon you won't be able to get cheap ASCII parentheses any > more, only the fancy high-priced ones like U+2045/U+2046, U+2772/U+2773 > and U+27E6/U+27E7. Perhaps that will make JMF rich enough to retire ;-) -- Live long and prosper. -- Spock, "Amok Time", stardate 3372.7 -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, 06 Aug 2014 12:07:58 +1000, Chris Angelico wrote: > On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano > wrote: >> A >> plethora of argument-less methods is a code smell -- that doesn't mean >> it's *necessarily* a bad idea, but the class design really needs a >> careful review. > > There are plenty of no-argument mutator methods, where the name of the > method (and the target object, obviously) is all the info you need. You > can clear() or copy() something with any more info, reverse() a list, > pop() from a list, etc. They don't have to be mutator methods. The same applies to string methods like upper(), lower(), isalpha() and many others. I'm not sure if you're agreeing or disagreeing with me. All these examples shouldn't be treated as properties either. This should be grounds for being slapped with a large herring: mydict.clear # returns None, operates by side-effect Some things are conceptually either methods or attributes: mydict.keys # could be okay I suppose but I digress. As I said, zero-argument (one-argument, if you count self) methods are a code smell, not an error. As is so often the case in programming, the fundamental sin here is *coupling* -- zero-argument methods are bad if they require coupling to temporary attributes which exist only to communicate an argument to the method. In other words, one of the sins of zero-argument methods is the same as that of zero-argument functions. We wouldn't write this: def double(): return number_to_operate_on*2 number_to_operate_on = 23 print double() number_to_operate_on = 42 print double() Turning it into a method on an instance, and turning the global into a "per instance global" (instead of per module, or application-wide) doesn't make it any better. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On 2014-08-05, Gregory Ewing wrote: > Grant Edwards wrote: >> Did I miss a news story? Have the parentesis mines all exploded >> causing the price of parenthesis to skyrocket? > > The Unicode Consortium has been secretly buying them > up for some time now. Pretty soon you won't be able > to get cheap ASCII parentheses any more, only the > fancy high-priced ones like U+2045/U+2046, > U+2772/U+2773 and U+27E6/U+27E7. Damn. Time to buy some options... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On 6/08/2014 9:49 AM, Ben Finney wrote: Christian Calderon writes: I like that in ruby I don't have to type parenthesis at the end of each function call if I don't need to provide extra arguments. Having the same name sometimes refer to “get this as a value” and other times “call this as a function and get the return value” imposes a cognitive load on the reader, IMO an unnecessary one. It also makes it impossible to use such methods in dispatch patterns or as callbacks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano wrote: > A > plethora of argument-less methods is a code smell -- that doesn't mean it's > *necessarily* a bad idea, but the class design really needs a careful > review. There are plenty of no-argument mutator methods, where the name of the method (and the target object, obviously) is all the info you need. You can clear() or copy() something with any more info, reverse() a list, pop() from a list, etc. (Okay, the last one has a default argument, but that raises an even worse point: adding a defaulted argument to a no-argument method suddenly stops it from being a property, which violates the usual rule that you can add a defaulted argument to anything without breaking anything.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning > ruby. I like that in ruby I don't have to type parenthesis at the end of > each function call if I don't need to provide extra arguments. That's one of the things which I dislike most about Ruby. Python has a nice, clean design: obj.method returns the method object, x() on any object calls it. (Possibly not successfully, if it is not a type, function or method, but it makes the attempt.) Making the parentheses optional just confuses the two, just for the sake of saving a couple of keystrokes. > I just > realized right now that I can do something similar in python, if I make > all methods with only the implicitly passed 'self' into properties. I wouldn't expect that there should be very many of such methods (except in, say, a type like str, where you have a bunch of transformation methods like str.upper() etc. -- but they shouldn't be treated as properties at all). A plethora of argument-less methods is a code smell -- that doesn't mean it's *necessarily* a bad idea, but the class design really needs a careful review. The problem with argument-less methods is that things which should be temporary arguments are being stored as permanent state instead. E.g. if you're calling methods just for their side-effect of setting up a bunch of attributes, just so you can then do what you really want which is call another method, that's a bad design which should be refactored to pass arguments direct to the method: # Bad class SandwichMaker: def prepare_sandwich_ingredients(self, bread, butter, fillings, openface=False): self._bread = bread self.butter = butter self.fillings = fillings self.openface = openface def make_sandwich(self): base = self.bread if not self.openface: cover = self.bread else: cover = None if self.butter in ('butter', 'margarine', 'mayo'): base += self.butter if cover: cover += self.butter for filling in self.fillings: self.thing_to_get = filling base += self.get_ingredient() if cover: # butter goes on the inside, not the top self.thing_to_flip = cover self.flip_the_thing_that_needs_flipping() base += self.thing_to_flip return base Obviously this is a fanciful example, but I've seen too much real code where too many methods existed solely to stuff data into an attribute so another method could get to it, after which that attribute was unneeded. It's the OOP equivalent of writing functions which communicate only by global variable. > Which > means I can either do some fancy coding and make a metaclass that does > this auto-magically, or I have to have property decorators all over the > place > :-P . I was wondering what other thought of this, is it an overly fanciful > way of coding python, or is it an acceptable thing to do in a real > project? Also, would anyone be interested in helping me make this > metaclass? Personally, I think it's a horrible idea, but if you must do it, I'd suggest doing it with a class decorator, not a metaclass. Something like this: # Untested. def make_zero_arg_methods_into_properties(cls): for name, obj in vars(cls).items(): if inspect.isfunction(obj): if inspect.getargspec(obj) == (['self'], None, None, ()): setattr(cls, name, property(obj)) return cls @make_zero_arg_methods_into_properties class Spam: def eggs(self): ... -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
Christian Calderon writes: > I like that in ruby I don't have to type parenthesis at the end of > each function call if I don't need to provide extra arguments. Whereas I like the opposite: there is a clear syntactic distinction between “get the value of ‘foo.bar.baz’” versus “get the value returned when calling ‘foo.bar.baz’”. Having the same name sometimes refer to “get this as a value” and other times “call this as a function and get the return value” imposes a cognitive load on the reader, IMO an unnecessary one. -- \“If this is your first visit to the USSR, you are welcome to | `\ it.” —hotel room, Moscow | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
Grant Edwards wrote: Did I miss a news story? Have the parentesis mines all exploded causing the price of parenthesis to skyrocket? The Unicode Consortium has been secretly buying them up for some time now. Pretty soon you won't be able to get cheap ASCII parentheses any more, only the fancy high-priced ones like U+2045/U+2046, U+2772/U+2773 and U+27E6/U+27E7. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Tue, Aug 5, 2014 at 1:39 PM, Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning ruby. > I like that in ruby I don't have to type parenthesis at the end of each > function call if I don't need to provide extra arguments. I just realized > right now that I can do something similar in python, if I make all methods > with only the implicitly passed 'self' into properties. Which means I can > either do some fancy coding and make a metaclass that does this > auto-magically, or I have to have property decorators all over the place :-P > . I was wondering what other thought of this, is it an overly fanciful way > of coding python, or is it an acceptable thing to do in a real project? > Also, would anyone be interested in helping me make this metaclass? The metaclass to do this is easy: import inspect import types class autoprop(type): def __init__(cls, name, bases, attrs): for name, value in attrs.items(): if (name.startswith('__') and name.endswith('__') or not isinstance(value, types.FunctionType)): continue argspec = inspect.getfullargspec(value) if (len(argspec.args) == 1 and not any([argspec.varargs, argspec.varkw, argspec.kwonlyargs])): setattr(cls, name, property(value)) But I'm in agreement with the others in this thread that it's not really a good idea. In addition to the arguments made by others, note that this doesn't actually make the parentheses optional; it makes their absence required. That's a fundamental limitation, because it's up to the descriptor to automatically call the method or not, and the descriptor has no way of knowing whether the thing it's returning is about to be called or not. Also, as a consequence of the above, note that this only works for methods that take no arguments at all (except self). If the method has optional arguments, and you replace it with a property, then you no longer have any way to pass those optional arguments. -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On 2014-08-05, Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning > ruby. I like that in ruby I don't have to type parenthesis at the end > of each function call if I don't need to provide extra arguments. Did I miss a news story? Have the parentesis mines all exploded causing the price of parenthesis to skyrocket? > I just realized right now that I can do something similar in python, > if I make all methods with only the implicitly passed 'self' into > properties. Which means I can either do some fancy coding and make a > metaclass that does this auto-magically, or I have to have property > decorators all over the place :-P Here's an idea: when using Python, write Python. Just type the parens. I know it requires hitting the shift key and all, but it's not that hard -- especially if you have two hands. If you want to write Ruby, then use Ruby. > I was wondering what other thought of this, is it an overly fanciful > way of coding python, IMO, it's a huge waste of time and an excellent way to reduce both readability and maintainability of your code. > or is it an acceptable thing to do in a real project? No. It's not acceptable. Not even a tiny bit. > Also, would anyone be interested in helping me make this metaclass? Um... [I have the nagging feeling I've been trolled...] -- Grant Edwards grant.b.edwardsYow! Everywhere I look I at see NEGATIVITY and ASPHALT gmail.com... -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Tue, 5 Aug 2014 12:39:18 -0700 Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning ruby. > I like that in ruby I don't have to type parenthesis at the end of each > function call if I don't need to provide extra arguments. I just realized > right now that I can do something similar in python, if I make all methods > with only the implicitly passed 'self' into properties. Which means I can > either do some fancy coding and make a metaclass that does this > auto-magically, or I have to have property decorators all over the place > :-P . I was wondering what other thought of this, is it an overly fanciful > way of coding python, or is it an acceptable thing to do in a real project? > Also, would anyone be interested in helping me make this metaclass? > Overly fanciful to my mind. Also, you'd eliminate the ability to talk about the function itself rather than the value thereof. No more help from the interactive console. No more passing the function as an argument. All to save '()', which is what tells other programmers that you're calling a function. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Making every no-arg method a property?
On Wed, Aug 6, 2014 at 5:39 AM, Christian Calderon wrote: > I have been using python for 4 years now, and I just started learning ruby. > I like that in ruby I don't have to type parenthesis at the end of each > function call if I don't need to provide extra arguments. I just realized > right now that I can do something similar in python, if I make all methods > with only the implicitly passed 'self' into properties. Which means I can > either do some fancy coding and make a metaclass that does this > auto-magically, or I have to have property decorators all over the place :-P > . I was wondering what other thought of this, is it an overly fanciful way > of coding python, or is it an acceptable thing to do in a real project? > Also, would anyone be interested in helping me make this metaclass? It's not a Pythonic style of coding. A property is generally assumed to be a cheap and simple lookup that cannot change anything - that is, it should be 'safe'. A no-arg method could mutate the object, could be expensive, could do just about anything. The parentheses make it clear that something's now happening - code's being called. Properties should be reserved for those cases where it's conceptually an attribute lookup, but for whatever reason you need a bit of code on it - and that's a pretty unusual case, compared to zero-argument methods. Strong recommendation that you don't do this. Of course, Python's "consenting adults" policy says that you're most welcome to - but you'll find that it's much more friendly to subsequent maintainers to keep attribute lookup and method call different. ChrisA -- https://mail.python.org/mailman/listinfo/python-list