__init__ style questions

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Will McGugan

    #1

    __init__ style questions

    I am writting a Vector3D class as a teaching aid (not for me, for
    others), and I find myself pondering over the __init__ function. I want
    it to be as easy to use as possible (speed is a secondary
    consideration).

    Heres the __init__ function I have at the moment.

    class Vector3D(object ):

    __slots__ = ('x', 'y', 'z')

    def __init__(self, x_or_iter=None, y=None, z=None):

    if x_or_iter is None:
    self.x = self.y = self.z = 0
    elif z is None:
    it = iter(x_or_iter)
    self.x = float(it.next() )
    self.y = float(it.next() )
    self.z = float(it.next() )
    else:
    self.x = float(x_or_iter )
    self.y = float(y)
    self.z = float(z)

    A Vector3D can be constructed in 3 ways. If no parameters are given it
    assumes a default of (0, 0, 0). If one parameter is given it is assumed
    to be an iterable capable of giving 3 values. If 3 values are given
    they are assumed to be the initial x, y, z.

    And now for the ponderings...

    1) Is 'overloading' like this pythonic, or should I supply alternative
    contstructors?

    2) I convert the input values to floats, which seems convenient because
    a Vector could be constructed with integers and other objects capable
    of being converted to floats. Could this hide errors?

    3) I like the constructing from an iterable, but it does mean that I
    can do something crazy like Vector3D("123") . Could this also hide
    errors?

    4) This does seem like a good candidate for __slots__, since there will
    could be large-ish lists of Vector3Ds. But is it a premature
    optimization?

    If it was just for myself or other experienced programmers I wouldn't
    be bothered about having the ability to do stupid things, because I
    simply wouldnt do them! But I dont want to teach beginner programmers
    bad habbits!

    Any comments appreciated...

    Will McGugan
    --


  • Duncan Booth

    #2
    Re: __init__ style questions

    "Will McGugan" <will@willmcgug an.comwrote:
    A Vector3D can be constructed in 3 ways. If no parameters are given it
    assumes a default of (0, 0, 0). If one parameter is given it is assumed
    to be an iterable capable of giving 3 values. If 3 values are given
    they are assumed to be the initial x, y, z.
    >
    And now for the ponderings...
    >
    1) Is 'overloading' like this pythonic, or should I supply alternative
    contstructors?
    No it isn't Pythonic. Why not just require 3 values and move the
    responsibility onto the caller to pass them correctly? They can still use
    an iterator if they want:

    Vector3D(a, b, c)
    Vector3D(*some_ iter)

    Then your initialiser becomes:

    def __init__(self, x=0, y=0, z=0):
    self.x, self.y, self.z = x, y, z

    much cleaner and also catches accidental use of iterators.

    Alternatively, insist on always getting exactly 0 or 1 arguments:

    Vector3D((a,b,c ))
    Vector3D(some_i ter)

    def __init__(self, (x, y, z)=(0,0,0)):
    self.x, self.y, self.z = x, y, z

    which is great if you already have lots of 3-tuples, but a pain otherwise
    to remember to double the parentheses.

    Comment

    • Fredrik Lundh

      #3
      Re: __init__ style questions

      Duncan Booth wrote:
      No it isn't Pythonic.
      rubbish. using a single constructor that handles two common use cases is
      perfectly Pythonic (especially if you're targeting casual programmers).

      </F>



      Comment

      • Will McGugan

        #4
        Re: __init__ style questions


        Duncan Booth wrote:
        No it isn't Pythonic. Why not just require 3 values and move the
        responsibility onto the caller to pass them correctly? They can still use
        an iterator if they want:
        >
        Vector3D(a, b, c)
        Vector3D(*some_ iter)
        I kind of liked the ability to partially use iterators. It would be
        convenient for reading in from a file for example

        f = file( "model.txt" )
        v1 = Vector3D( f )
        v2 = Vector3D( f )
        v3 = Vector3D( f )

        Which you couldnt do with a tuple, because the * syntac would attempt
        to read the entire file (I think).
        >
        Then your initialiser becomes:
        >
        def __init__(self, x=0, y=0, z=0):
        self.x, self.y, self.z = x, y, z
        >
        much cleaner and also catches accidental use of iterators.
        >
        Alternatively, insist on always getting exactly 0 or 1 arguments:
        >
        Vector3D((a,b,c ))
        Vector3D(some_i ter)
        >
        def __init__(self, (x, y, z)=(0,0,0)):
        self.x, self.y, self.z = x, y, z
        >
        which is great if you already have lots of 3-tuples, but a pain otherwise
        to remember to double the parentheses.
        Hmm. Not keen on that for the reason you mentioned. For my particular
        use case there would be a lot of Vector3D 'literals'.

        Comment

        • Duncan Booth

          #5
          Re: __init__ style questions

          "Fredrik Lundh" <fredrik@python ware.comwrote:
          Duncan Booth wrote:
          >
          >No it isn't Pythonic.
          >
          rubbish. using a single constructor that handles two common use cases is
          perfectly Pythonic (especially if you're targeting casual programmers).
          >
          Yes, but I don't think that the specific case the OP asked about would be
          pythonic: there was no need two separate calling conventions there.

          Comment

          • Duncan Booth

            #6
            Re: __init__ style questions

            "Will McGugan" <will@willmcgug an.comwrote:
            Duncan Booth wrote:
            >
            >No it isn't Pythonic. Why not just require 3 values and move the
            >responsibili ty onto the caller to pass them correctly? They can still
            >use an iterator if they want:
            >>
            > Vector3D(a, b, c)
            > Vector3D(*some_ iter)
            >
            I kind of liked the ability to partially use iterators. It would be
            convenient for reading in from a file for example
            >
            f = file( "model.txt" )
            v1 = Vector3D( f )
            v2 = Vector3D( f )
            v3 = Vector3D( f )
            >
            Which you couldnt do with a tuple, because the * syntac would attempt
            to read the entire file (I think).
            Yes, it would, although since the implication is that your class expected
            numbers and the file iterator returns strings I'm not sure how much it
            matters: you are still going to have to write more code than in your
            example above. e.g.

            v1 = Vector3D(float( n) for n in itertools.islic e(f, 3))

            or with my variant:

            v1 = Vector3D(*(floa t(n) for n in itertools.islic e(f, 3)))


            I think my main objection to your code was that it introduced too many ways
            for the constructor to do unexpected things silently. e.g. your suggestion
            Vector3D("abc") , or Vector3D((1,2,3 ,4)) and I don't like errors going
            uncaught. That's why I think it is better to pass in exactly the arguments
            you need and convert them at the point where you can tell what the ambigous
            construction actually meant. I have no objection though to e.g. a class
            factory method which does all of this:

            @classmethod
            def fromStringSeque nce(cls, iter):
            return cls(*(float(n) for n in itertools.islic e(iter, 3)))

            because that still makes you decide at the point of call whether you want:

            v1 = Vector3D(1, 2, 3)

            or
            v1 = Vector3D.fromSt ringSequence(f)

            Comment

            • Will McGugan

              #7
              Re: __init__ style questions


              Duncan Booth wrote:
              >
              Yes, it would, although since the implication is that your class expected
              numbers and the file iterator returns strings I'm not sure how much it
              matters: you are still going to have to write more code than in your
              example above. e.g.
              >
              v1 = Vector3D(float( n) for n in itertools.islic e(f, 3))
              >
              or with my variant:
              >
              v1 = Vector3D(*(floa t(n) for n in itertools.islic e(f, 3)))
              >
              The generator expression wouldnt really be neccesary since the
              constructor converts the iterated values to floats.

              But! I understand your objection. It doesn't quite fit with 'explicit
              is better than implicit'. Im just debating the trade-off with catching
              foolish mistakes and making it easier to use for beginners.

              Thanks.

              Comment

              • Gerard Flanagan

                #8
                Re: __init__ style questions

                Will McGugan wrote:
                I am writting a Vector3D class as a teaching aid (not for me, for
                others), and I find myself pondering over the __init__ function. I want
                it to be as easy to use as possible (speed is a secondary
                consideration).
                >
                Heres the __init__ function I have at the moment.
                >
                class Vector3D(object ):
                >
                __slots__ = ('x', 'y', 'z')
                >
                def __init__(self, x_or_iter=None, y=None, z=None):
                >
                if x_or_iter is None:
                self.x = self.y = self.z = 0
                elif z is None:
                it = iter(x_or_iter)
                self.x = float(it.next() )
                self.y = float(it.next() )
                self.z = float(it.next() )
                else:
                self.x = float(x_or_iter )
                self.y = float(y)
                self.z = float(z)
                >
                A Vector3D can be constructed in 3 ways. If no parameters are given it
                assumes a default of (0, 0, 0). If one parameter is given it is assumed
                to be an iterable capable of giving 3 values. If 3 values are given
                they are assumed to be the initial x, y, z.
                >
                here's a slightly different approach:


                class Vector3D(object ):
                __slots__ = ('x', 'y', 'z')

                def __init__(self, X1=None, X2=None, X3=None):
                if X3 is not None:
                #assume 3 numbers
                self.x = X1
                self.y = X2
                self.z = X3
                else:
                X1 = X1 or (0,0,0)
                X2 = X2 or (0,0,0)
                self.x = X1[0] - X2[0]
                self.y = X1[1] - X2[1]
                self.z = X1[2] - X2[2]

                def __getitem__(sel f, index):
                return getattr(self,se lf.__slots__[index])

                def __str__(self):
                return '(%s, %s, %s)' % (self.x, self.y, self.z )

                u = Vector3D()
                print u
                u = Vector3D(3,4,5)
                print u
                u, v = Vector3D( [1,2,3] ), Vector3D( (3,2,1) )
                print u, v
                w = Vector3D( u,v )
                print w
                w = Vector3D( u, (2,2,2))
                print w

                (0, 0, 0)
                (3, 4, 5)
                (1, 2, 3) (3, 2, 1)
                (-2, 0, 2)
                (-1, 0, 1)

                Gerard

                Comment

                • bearophileHUGS@lycos.com

                  #9
                  Re: __init__ style questions

                  Will McGugan:
                  I am writting a Vector3D class as a teaching aid (not for me, for
                  others), and I find myself pondering over the __init__ function. I want
                  it to be as easy to use as possible (speed is a secondary
                  consideration).
                  If optimizations are less important, then don't use __slots__, it
                  simplifies OOP management of it.

                  I think that accepting a single iterable too makes the calling a bit
                  too much elastic, so it can produce silent problems. Something like
                  this may be better:

                  from itertools import imap

                  class Vector3D(object ):
                  def __init__(self, *args):
                  len_args = len(args)
                  if len_args == 3:
                  self.x, self.y, self.z = imap(float, args)
                  elif len_args == 0:
                  self.x = self.y = self.z = 0
                  else:
                  raise TypeError("..." )

                  If you don't like imap, you can change that code.
                  If you want to accept single parameter too then you can use something
                  like:

                  class Vector3D(object ):
                  def __init__(self, *args):
                  len_args = len(args)
                  if len_args == 3:
                  self.x, self.y, self.z = imap(float, args)
                  elif len_args == 1:
                  self.x, self.y, self.z = imap(float, args[0])
                  elif len_args == 0:
                  self.x = self.y = self.z = 0
                  else:
                  raise TypeError("..." )

                  If you don't like the explicit raising of an error you may use:

                  class Vector3D(object ):
                  def __init__(self, first=None, *other):
                  if first:
                  if other:
                  self.x = float(first)
                  self.y, self.z = imap(float, other)
                  else:
                  self.x, self.y, self.z = imap(float, first)
                  else:
                  self.x = self.y = self.z = 0

                  But this last code is less readable.

                  Bye,
                  bearophile

                  Comment

                  Working...