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


Groups > comp.lang.python > #57122

Re: skipping __init__ and using exploiting a class member instead

From Robert Kern <robert.kern@gmail.com>
Subject Re: skipping __init__ and using exploiting a class member instead
Date 2013-10-19 23:18 +0100
References <fb1b5b6f-619c-4acd-b1bf-a375ccc6f1a6@googlegroups.com> <5262FFED.9010309@nedbatchelder.com>
Newsgroups comp.lang.python
Message-ID <mailman.1269.1382221104.18130.python-list@python.org> (permalink)

Show all headers | View raw


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

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web