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

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

skipping __init__ and using exploiting a class member instead

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

Contents

  skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-19 14:44 -0700
    Re: skipping __init__ and using exploiting a class member instead Ned Batchelder <ned@nedbatchelder.com> - 2013-10-19 17:55 -0400
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-19 15:11 -0700
    Re: skipping __init__ and using exploiting a class member instead Robert Kern <robert.kern@gmail.com> - 2013-10-19 23:18 +0100
    Re: skipping __init__ and using exploiting a class member instead Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-19 22:30 +0000
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-19 17:07 -0700
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-19 17:42 -0700
      Re: skipping __init__ and using exploiting a class member instead Ned Batchelder <ned@nedbatchelder.com> - 2013-10-19 21:13 -0400
      Detecting whether a value was passed for a parameter (was: skipping __init__ and using exploiting a class member instead) Ben Finney <ben+python@benfinney.id.au> - 2013-10-20 22:50 +1100
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 00:09 -0700
      Re: skipping __init__ and using exploiting a class member instead Roy Smith <roy@panix.com> - 2013-10-20 08:55 -0400
      Re: skipping __init__ and using exploiting a class member instead Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-20 14:16 +0100
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 01:46 -0700
    Re: skipping __init__ and using exploiting a class member instead Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-10-20 07:27 -0700
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 10:57 -0700
      Re: skipping __init__ and using exploiting a class member instead Roy Smith <roy@panix.com> - 2013-10-20 16:44 -0400
      Re: skipping __init__ and using exploiting a class member instead Chris Angelico <rosuav@gmail.com> - 2013-10-21 07:57 +1100
        Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 14:34 -0700
          Re: skipping __init__ and using exploiting a class member instead Roy Smith <roy@panix.com> - 2013-10-20 18:31 -0400
            Re: skipping __init__ and using exploiting a class member instead Ben Finney <ben+python@benfinney.id.au> - 2013-10-21 10:55 +1100
              Re: skipping __init__ and using exploiting a class member instead Neil Cerutti <neilc@norwich.edu> - 2013-10-21 18:47 +0000
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 21:30 -0700
    Re: skipping __init__ and using exploiting a class member instead Peter Cacioppi <peter.cacioppi@gmail.com> - 2013-10-20 21:31 -0700
      Re: skipping __init__ and using exploiting a class member instead feedthetroll@gmx.de - 2013-10-21 00:16 -0700

Page 1 of 2  [1] 2  Next page →

#57116 — skipping __init__ and using exploiting a class member instead

Is the following considered poor Python form?

class Foo (object) :
    _lazy = None
    def foo(self, x) :
        _lazy = _lazy or self.get_something(x)
    def get_something(self, x) :
        # doesn't really matter

I like this idiom for certain situations, just wondering if it will raise the hackles of other Pythonistas. 

I use this idiom sparingly, but sometimes it just fits the task at hand, I hear Guidos voice saying "use the Force" in my ear, etc.

[toc] | [next] | [standalone]

#57117

On 10/19/13 5:44 PM, Peter Cacioppi wrote:
> Is the following considered poor Python form?
>
> class Foo (object) :
>      _lazy = None
>      def foo(self, x) :
>          _lazy = _lazy or self.get_something(x)
>      def get_something(self, x) :
>          # doesn't really matter
>
> I like this idiom for certain situations, just wondering if it will raise the hackles of other Pythonistas.
>
> I use this idiom sparingly, but sometimes it just fits the task at hand, I hear Guidos voice saying "use the Force" in my ear, etc.

You present this as a choice between __init__ or a class attribute, but 
those two things are very different.  Is your intent to have an instance 
attribute, or a class attribute?  Lazily populated instance attributes 
are fine, I would do it like this:

class Foo(object):
     def __init__(self):
         self._lazy = None

     def foo(self, x):
         if self._lazy is None:
             self._lazy = self.get_something(x)
         ...

--Ned.

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

#57119

On Saturday, October 19, 2013 2:44:55 PM UTC-7, Peter Cacioppi wrote:
> Is the following considered poor Python form?
> 
> 
> 
> class Foo (object) :
> 
>     _lazy = None
> 
>     def foo(self, x) :
> 
>         _lazy = _lazy or self.get_something(x)
> 
>     def get_something(self, x) :
> 
>         # doesn't really matter
> 
> 
> 
> I like this idiom for certain situations, just wondering if it will raise the hackles of other Pythonistas. 
> 
> 
> 
> I use this idiom sparingly, but sometimes it just fits the task at hand, I hear Guidos voice saying "use the Force" in my ear, etc.

To be clear, I use this when I'm subclassing something and don't need to do anything with the _lazy other than set it to None in the __init__. I like this idiom because it removes the risk of miscalling the parent __init__, and it's also quick and easy to code.

Yes there is a class member I am creating, but each instance has a distinct member. (In other words, I'm an adult, I tested it and it works, but I couldn't find anything in the Google indicating what the collective reaction would be from Pythonistan)

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

#57122

On 2013-10-19 22:55, Ned Batchelder wrote:
> On 10/19/13 5:44 PM, Peter Cacioppi wrote:
>> Is the following considered poor Python form?
>>
>> class Foo (object) :
>>      _lazy = None
>>      def foo(self, x) :
>>          _lazy = _lazy or self.get_something(x)
>>      def get_something(self, x) :
>>          # doesn't really matter
>>
>> I like this idiom for certain situations, just wondering if it will raise the
>> hackles of other Pythonistas.
>>
>> I use this idiom sparingly, but sometimes it just fits the task at hand, I
>> hear Guidos voice saying "use the Force" in my ear, etc.
>
> You present this as a choice between __init__ or a class attribute, but those
> two things are very different.  Is your intent to have an instance attribute, or
> a class attribute?  Lazily populated instance attributes are fine, I would do it
> like this:
>
> class Foo(object):
>      def __init__(self):
>          self._lazy = None
>
>      def foo(self, x):
>          if self._lazy is None:
>              self._lazy = self.get_something(x)
>          ...

I think he left some important characters out.

class Foo (object) :
     _lazy = None
     def foo(self, x) :
         self._lazy = self._lazy or self.get_something(x)
         # Use self._lazy for something

     def get_something(self, x) :
         # doesn't really matter

The main difference being that he doesn't initialize the instance attribute and 
just relies on the fallback to class attribute lookup. In my experience, using a 
static[1] class attribute as a default for an instance attribute is accepted 
practice, and one that gets touted as a positive feature of Python's namespace 
model when compared against other languages. That said, I have seen it more 
often in the past.

[1] In the general "unchanging" sense rather than the C++ "static" keyword sense.

-- 
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

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

#57125

On Sat, 19 Oct 2013 14:44:55 -0700, Peter Cacioppi wrote:

> Is the following considered poor Python form?
> 
> class Foo (object) :
>     _lazy = None
>     def foo(self, x) :
>         _lazy = _lazy or self.get_something(x)
>     def get_something(self, x) :
>         # doesn't really matter
> 
> I like this idiom for certain situations, just wondering if it will
> raise the hackles of other Pythonistas.

I agree with Ned's comments -- the basic idea is fine, it's just caching 
some calculated result.

I often use this idiom in read-only properties, for something that only 
needs to be calculated once, but it's time-consuming to calculate and 
therefore I want to delay doing the calculation until the last possible 
minute. Something like this:

class Spam:
    @property
    def spam(self):
        try:
            result = self._spam
        except AttributeError:
            # Perform some time-consuming calculation.
            result = self._spam = \
                ("spam "*5).capitalize() + "LOVELY SPAM!!!!!"
        return result

but there are a million different variations on this theme.


> I use this idiom sparingly, but sometimes it just fits the task at hand,
> I hear Guidos voice saying "use the Force" in my ear, etc.

Good reasons for avoiding this pattern might include:

- the speed benefit is too trivial to justify the extra complexity;

- the risk that some condition will unexpectedly change, invalidating
  the cached value, but it's too hard to notice when the cache is 
  invalid;

- caching the result means you unnecessarily hold on to a chunk of
  memory which otherwise would be garbage collected (consider using
  weak references to solve this one);

but otherwise it is unobjectionable.


-- 
Steven

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

#57135

Yes, I see the light now. My idiom works, but Steven has shown me the droids I am looking for. 

Thanks!

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

#57136

To be clear, my original post had a goof. 

So my original, de-goofed, idiom was


class Foo (object) :
    _lazy = None
    def foo(self, x) :
        self._lazy = self._lazy or self.get_something(x)
    def get_something(self, x) :
        # doesn't really matter, so long as it returns truthy result

and the new, improved idiom is 

class Foo (object) :
    def foo(self, x) :
        self._lazy = getattr(self, "_lazy", None) or self._get_something(x)
    def _get_something(self, x) :    
        # doesn't really matter, so long as it returns truthy result

I was laboring under some misconception that there was Python magic that allowed __init__ and only __init__ to add class attributes by setting their values. Good to know this piece of magic isn't part of Python, and thus lazy eval can be handled more cleanly than I originally thought. 

In other words, "Guido was here".

Thanks again

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

#57137

On 10/19/13 8:42 PM, Peter Cacioppi wrote:
> To be clear, my original post had a goof.
>
> So my original, de-goofed, idiom was
>
>
> class Foo (object) :
>      _lazy = None
>      def foo(self, x) :
>          self._lazy = self._lazy or self.get_something(x)
>      def get_something(self, x) :
>          # doesn't really matter, so long as it returns truthy result
>
> and the new, improved idiom is
>
> class Foo (object) :
>      def foo(self, x) :
>          self._lazy = getattr(self, "_lazy", None) or self._get_something(x)
>      def _get_something(self, x) :
>          # doesn't really matter, so long as it returns truthy result

The use of getattr here seems unfortunate.  Your original at least 
didn't have that odd uncertainty about it.  I'm not sure why you want to 
avoid an __init__ method.  Why not simply have one, and use it to 
initialize your attributes, even if it is to None?

--Ned.
> I was laboring under some misconception that there was Python magic that allowed __init__ and only __init__ to add class attributes by setting their values. Good to know this piece of magic isn't part of Python, and thus lazy eval can be handled more cleanly than I originally thought.
>
> In other words, "Guido was here".
>
> Thanks again
>

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

#57147 — Detecting whether a value was passed for a parameter (was: skipping __init__ and using exploiting a class member instead)

Peter Cacioppi <peter.cacioppi@gmail.com> writes:

> I was laboring under some misconception that there was Python magic
> that allowed __init__ and only __init__ to add class attributes by
> setting their values. Good to know this piece of magic isn't part of
> Python, and thus lazy eval can be handled more cleanly than I
> originally thought.

Rather, the magic is that ‘__init__’ will be called automatically by the
class creation protocol, to initialise any new instance of that class.

So the method to write if you want instance-specific initialisation is
still ‘__init__’.

> Think about it this way. None here really means "not yet initialized".
> It is a value that cannot occur naturally and thus functions as a
> not-initialized flag.

As you point out, though, that's not a menaing of None agreed on
everywhere. You can't expect that the caller will not be passing a value
of None for that parameter.

> So this, somewhat arbitrary, context sensitive value should be isolated
> as much as possible. You don't want it popping up hither and yon, you
> want to type as infrequently as possible and localized it to as few
> methods as possible.

Right. The pattern you're looking for is called a “sentinel value”
<URL:https://en.wikipedia.org/wiki/Sentinel_value>.

Usually, the None singleton is good enough for a sentinel value, but
often it has a meaning already in your context, so is not available as a
sentinel value.

In cases where None is not available, make a specific value that has no
other meaning, and use that specifically for your parameter's sentinel
value::

    class Foo(object):
        _default_for_x = object()

        def __init__(self, x=_default_for_object):
            """ Initialise a new instance. """
            if x is self._default_for_object:
                # No value for ‘x’ was passed, because ‘_default_for_x’
                # would not be passed by accident.
                x = self._get_value_for_x()
            self.x = x

        def _get_default_value_for_x(self):
            """" Calculate the default ‘x’ value for this instance. """
            return some_computation(self)

-- 
 \       “When a well-packaged web of lies has been sold to the masses |
  `\    over generations, the truth will seem utterly preposterous and |
_o__)                    its speaker a raving lunatic.” —Dresden James |
Ben Finney

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

#57143

>The use of getattr here seems unfortunate

Unfortunate how? It's a perfect for what I want here ... remember the context is such that the lazily stored value is always truthy (I assert this elsewhere).

>   I'm not sure why you want to avoid an __init__ method.

Why do you want to keep it?  The more code you write the more bugs you write. Who knows, maybe I screw up the argument pass to the super __init__. Maybe I screw up the super reference. Didn't Einstein say make it as simple as possible, but no simpler?

Personally, I find the ability of Python to subclass without overriding the constructor very elegant. I don't believe the other languages I've worked in can do this (C++, C#, Java)... or if there is a way it's a bit scary and discouraged. Whereas skipping the __init__ seems to be a standard part of the Python OO development process.

Again, this is just the lazy eval pattern. In C#, for example, I'd write my constructors but refer to _lazy only in the foo function and in it's declaration line (which would explicitly default initialize it).

At any rate, the second idiom is very pretty to me, I'm keeping it unless a compelling argument is presented. Thanks for the kibbutzing though, the first idiom was poor form, as I suspected.

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

#57148

In article <abedb99b-336a-4bbe-9ddc-e98613853026@googlegroups.com>,
 Peter Cacioppi <peter.cacioppi@gmail.com> wrote:

> Personally, I find the ability of Python to subclass without overriding the 
> constructor very elegant. I don't believe the other languages I've worked in 
> can do this (C++, C#, Java)...

I'm not sure what point you're trying to make here.  You certainly don't 
have to write a constructor for a subclass in C++.  This works perfectly 
fine (and prints "Foo" when I run it):

#include <stdio.h>

class Foo {
public:
    Foo() {
        printf("Foo()\n");
    };
};

class Bar : Foo {
};

int main(char**, int) {
    Bar b;
}

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

#57149

On 20/10/2013 08:09, Peter Cacioppi wrote:
>
> Personally, I find the ability of Python to subclass without overriding the constructor very elegant.
>

__new__ is the constructor which to my knowledge you've not mentioned, 
__init__ is the initialiser as mentioned by Ben Finney.

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

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

#57145

> Why not simply have one, and use it to initialize your attributes, 
> even if it is to None? 

Think about it this way. None here really means "not yet initialized". It is a value that cannot occur naturally and thus functions as a not-initialized flag.

But for different contexts, this value could be almost anything. It might even be truthy.

So this, somewhat arbitrary, context sensitive value should be isolated as much as possible.  You don't want it popping up hither and yon, you want to type as infrequently as possible and localized it to as few methods as possible.

For example, look at this version of the idiom

class Foo (Bar) :
   def foo(self, x) :
      if (getattr(self, "_lazy", -1) < 0 ) :
          self._lazy = self._count_something(x)
      assert (self._lazy >= 0) # a negative count is a bug not a bad data entry
   def count_something(self, x) :
       # if it's really counting something, it will return a natural number

Now you really want that -1 in an  __init__ method instead of the foo method? Isn't that asking for trouble when somebody copies this and rewrites it? They could change the boolean expressions in foo (i.e. < 0 means compute it, >= sanity checks the result) but fail to change the proper flag for not-yet-computed (-1) if these things are in two different methods.

My way, it's all in one place. 

Good little idiom to ponder though. I like fussing over these things. Any good gambler develops clean habits to improve his odds, even if each act of hygiene changes the odds but slightly.  I wouldn't complain if a co-worker coded this your way, but I still think it is cleaner my way.

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

#57150

On Sat, Oct 19, 2013 at 2:44 PM, Peter Cacioppi
<peter.cacioppi@gmail.com> wrote:
> Is the following considered poor Python form?
>
> class Foo (object) :
>     _lazy = None
>     def foo(self, x) :
>         self._lazy = self._lazy or self.get_something(x)
>     def get_something(self, x) :
>         # doesn't really matter
>
> I like this idiom for certain situations, just wondering if it will raise the hackles of other Pythonistas.

It raises my hackles, but not for any good reason.

I've seen it a number of times in the Twisted codebase, so you're not
alone in using it.

-- Devin

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

#57153

>  You certainly don't have to write a constructor for a subclass in C++. 

Ahh, this message board is so collectively well informed (once you get past the trolls)

The C++ project I worked on was religious about always overwriting parent class constructors. I had assumed this was because the language proper forbid it, but apparently it was just project protocol. 

Thanks again!

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

#57155

In article <0e9b51a9-bd78-4d34-b277-c463347e8e02@googlegroups.com>,
 Peter Cacioppi <peter.cacioppi@gmail.com> wrote:

> >  You certainly don't have to write a constructor for a subclass in C++. 
> 
> Ahh, this message board is so collectively well informed (once you get past 
> the trolls)
> 
> The C++ project I worked on was religious about always overwriting parent 
> class constructors. I had assumed this was because the language proper forbid 
> it, but apparently it was just project protocol. 

One of the problems with C++ is that it's such a huge language, nobody 
knows all of it.  Most people learn some subset of the language that 
they get comfortable with (often because that's the subset that's used 
on the project they're working on).  Then it's easy to assume that the 
part you know is all there is to know.

Personally, I barely know the STL (because the various C++ projects I've 
worked on all predated the STL and rolled their own container classes).  
Likewise for most of the std streams library.

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

#57156

On Mon, Oct 21, 2013 at 4:57 AM, Peter Cacioppi
<peter.cacioppi@gmail.com> wrote:
>>  You certainly don't have to write a constructor for a subclass in C++.
>
> Ahh, this message board is so collectively well informed (once you get past the trolls)
>
> The C++ project I worked on was religious about always overwriting parent class constructors. I had assumed this was because the language proper forbid it, but apparently it was just project protocol.

Minor point: In C++, you don't overwrite constructors; you simply add
your own. By the time a derived class's constructor is called, the
parents' have all already been called.

ChrisA

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

#57157

At the risk of sounding like a fogey, I actually think I did, at one time, know the distinctions between "our projects protocol" and "the language proper" for C++. I read Scott Meyers books on C++ and STL a couple of times each and helped design the protocol that kept us reasonably safe. 

But this was all a long time ago, and those parts of my RAM are now storing Breaking Bad plot twists and the nuances of the Federer or Nadal debate.

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

#57159

In article <ed8755fd-308d-4a90-ad6c-42d4e909571d@googlegroups.com>,
 Peter Cacioppi <peter.cacioppi@gmail.com> wrote:

> I read Scott Meyers books on C++ and STL a couple of times 
> each and helped design the protocol that kept us reasonably safe. 

Scott Meyers is an incredibly smart C++ wizard.  His books are amazing.  
The fact that it takes somebody that smart, and books that amazing, to 
teach you how not to shoot yourself in the foot with a C++ compiler says 
a lot about the language.

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

#57161

Roy Smith <roy@panix.com> writes:

> Scott Meyers is an incredibly smart C++ wizard.  His books are amazing.  
> The fact that it takes somebody that smart, and books that amazing, to 
> teach you how not to shoot yourself in the foot with a C++ compiler says 
> a lot about the language.

+1 QotW

-- 
 \     “[W]e are still the first generation of users, and for all that |
  `\      we may have invented the net, we still don't really get it.” |
_o__)                                                   —Douglas Adams |
Ben Finney

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web