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

Groups > comp.lang.python > #57147

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

Show all headers | View raw

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

Back to comp.lang.python | Previous | Next — Previous 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