Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75754 > unrolled thread

Making every no-arg method a property?

Back to article view | Back to comp.lang.python

Contents

  Making every no-arg method a property? Christian Calderon <calderon.christian760@gmail.com> - 2014-08-05 12:39 -0700
    Re: Making every no-arg method a property? Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-08-05 13:57 -0700
    Re: Making every no-arg method a property? Grant Edwards <invalid@invalid.invalid> - 2014-08-05 21:14 +0000
      Re: Making every no-arg method a property? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-08-06 10:34 +1200
        Re: Making every no-arg method a property? Grant Edwards <invalid@invalid.invalid> - 2014-08-06 05:13 +0000
          Re: Making every no-arg method a property? Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-08-06 09:53 -0700
        Re: Making every no-arg method a property? alister <alister.nospam.ware@ntlworld.com> - 2014-08-06 10:09 +0000
          Re: Making every no-arg method a property? Terry Reedy <tjreedy@udel.edu> - 2014-08-06 15:04 -0400
    Re: Making every no-arg method a property? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-06 10:49 +1000
      Re: Making every no-arg method a property? Chris Angelico <rosuav@gmail.com> - 2014-08-06 12:07 +1000
        Re: Making every no-arg method a property? Steven D'Aprano <steve@pearwood.info> - 2014-08-06 09:15 +0000
          Re: Making every no-arg method a property? Chris Angelico <rosuav@gmail.com> - 2014-08-06 21:26 +1000
    Re: Making every no-arg method a property? alister <alister.nospam.ware@ntlworld.com> - 2014-08-06 10:12 +0000

#75754 — Making every no-arg method a property?

[Multipart message — attachments visible in raw view] — view raw

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?

[toc] | [next] | [standalone]

#75757

On Tue, 5 Aug 2014 12:39:18 -0700
Christian Calderon <calderon.christian760@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#75758

On 2014-08-05, Christian Calderon <calderon.christian760@gmail.com> 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.edwards        Yow! Everywhere I look I
                                  at               see NEGATIVITY and ASPHALT
                              gmail.com            ...

[toc] | [prev] | [next] | [standalone]

#75767

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

[toc] | [prev] | [next] | [standalone]

#75777

On 2014-08-05, Gregory Ewing <greg.ewing@canterbury.ac.nz> 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

[toc] | [prev] | [next] | [standalone]

#75805

On Wed, 6 Aug 2014 05:13:07 +0000 (UTC)
Grant Edwards <invalid@invalid.invalid> wrote:

> On 2014-08-05, Gregory Ewing <greg.ewing@canterbury.ac.nz> 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.

[toc] | [prev] | [next] | [standalone]

#75789

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

[toc] | [prev] | [next] | [standalone]

#75810

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

[toc] | [prev] | [next] | [standalone]

#75773

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

[toc] | [prev] | [next] | [standalone]

#75774

On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#75788

On Wed, 06 Aug 2014 12:07:58 +1000, Chris Angelico wrote:

> On Wed, Aug 6, 2014 at 10:49 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#75792

On Wed, Aug 6, 2014 at 7:15 PM, Steven D'Aprano <steve@pearwood.info> 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
>> <steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#75790

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?
> <div dir="ltr">I have been using python for 4 years now, and I just
> started learning ruby. I like that in ruby I don&#39;t have to type
> parenthesis at the end of each function call if I don&#39;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 &#39;self&#39; 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?</div>

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web