__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).

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
--
http://www.willmcgugan.com

[Duncan Booth]

"Will McGugan" <wi**@willmcgugan.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_iter)

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.

[Fredrik Lundh]

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>

[Will McGugan]

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

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

[Duncan Booth]

"Fredrik Lundh" <fr*****@pythonware.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.

[Duncan Booth]

"Will McGugan" <wi**@willmcgugan.comwrote:

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

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.islice(f, 3))

or with my variant:

v1 = Vector3D(*(float(n) for n in itertools.islice(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 fromStringSequence(cls, iter):
return cls(*(float(n) for n in itertools.islice(iter, 3)))

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

v1 = Vector3D(1, 2, 3)

or
v1 = Vector3D.fromStringSequence(f)

[Will McGugan]

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.islice(f, 3))

or with my variant:

v1 = Vector3D(*(float(n) for n in itertools.islice(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.

[Gerard Flanagan]

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__(self, index):
return getattr(self,self.__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

[bearophileHUGS]

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