Is this a good idea or a waste of time?

[asincero]

Would it be considered good form to begin every method or function with
a bunch of asserts checking to see if the parameters are of the correct
type (in addition to seeing if they meet other kinds of precondition
constraints)? Like:

def foo(a, b, c, d):
assert type(a) == str
assert type(b) == str
assert type(c) == int
assert type(d) == bool
# rest of function follows

This is something I miss from working with more stricter languages like
C++, where the compiler will tell you if a parameter is the wrong type.
If anything, I think it goes a long way towards the code being more
self documenting. Or is this a waste of time and not really "the
Python way"?

-- Arcadio

[Antoon Pardon]

On 2006-08-28, Scott David Daniels <sc***********@ acm.orgwrote:

Antoon Pardon wrote:

>On 2006-08-25, Simon Forman <ro*********@ya hoo.comwrote:

>>...
Generally asserts should be used to "enforce" invariants of your code
(as opposed to typechecking), or to check certain things while
debugging.

I don't understand this argument. Can't type checking be seen as
enforcing a code invariant?

But it is practically never the "right" invariant.

And who decides what is and what is not the "right" invariant?

You don't usually
mean type(x) == int, but rather something like x is a prime between 2
and 923. Or 5< x**4 < 429, or _something_ problem specific. saying
that x must be an int is almost always simultaneously too specific and
too general.

There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

--
Antoon Pardon

[sjdevnull]

Antoon Pardon wrote:

There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

I've _never_ seen a case where enforcing types in the manner of the OP
is appropriate.

It fails with trivial wrappers like

class myInt(int):
def printFormatted( self):
..........

Even looser checking with isinstance is rarely right. You may want to
exclude floats, but that doesn't mean you want to exclude int-like
objects that don't inherit from int.

[Terry Hancock]

asincero wrote:

Would it be considered good form to begin every method or function
with a bunch of asserts checking to see if the parameters are of the
correct type [...]

This is something I miss from working with more stricter languages
like C++, where the compiler will tell you if a parameter is the
wrong type. If anything, I think it goes a long way towards the code
being more self documenting. Or is this a waste of time and not
really "the Python way"?

Definitely "unpythonic ".

It's generally better to ask if an object "acts right" rather than if
it "is right". In other words, if you're going to add two objects,
it's more important that they support addition than that they
are integers, longs, floats, or matrices. This makes your code
more portable, because people might create new numeric types
(say "measuremen ts" or "rationals" ). If you leave things open,
then the author of such modules can use your code (they may
have to test special cases if their objects don't behave the same
way as you expect them to, but that becomes their problem).
On the other hand, if your code just arbitrarily breaks because
the objects fail a typecheck, that's an unnecessary obstacle.

If you need assertions, it's better to ask more specifically what will
break the code (e.g. objects that don't support addition -- which
you can check by doing an addition or by looking for th __add__
method. But then, if you need addition support, then your code
probably already has an addition, so why not just let it fail there?).

So be more minimal and throw in checks for specific problems --
especially the ones that would cause a wrong result rather than
an exception.

Cheers,
Terry
--
Terry Hancock (ha*****@Anansi Spaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Antoon Pardon]

On 2006-08-28, sj*******@yahoo .com <sj*******@yaho o.comwrote:

Antoon Pardon wrote:

>There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

I've _never_ seen a case where enforcing types in the manner of the OP
is appropriate.

It fails with trivial wrappers like

class myInt(int):
def printFormatted( self):
..........

Even looser checking with isinstance is rarely right. You may want to
exclude floats, but that doesn't mean you want to exclude int-like
objects that don't inherit from int.

That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

--
Antoon Pardon

[Gabriel Genellina]

At Tuesday 29/8/2006 01:28, Antoon Pardon wrote:

Antoon Pardon wrote:

There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

I've _never_ seen a case where enforcing types in the manner of the OP
is appropriate.

It fails with trivial wrappers like

class myInt(int):
def printFormatted( self):
..........

Even looser checking with isinstance is rarely right. You may want to
exclude floats, but that doesn't mean you want to exclude int-like
objects that don't inherit from int.

That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

In any case, I don't see how this supports the original claim that
strict type checking input params is good practice.

Gabriel Genellina
Softlab SRL

_______________ _______________ _______________ _____
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Simon Forman]

Antoon Pardon wrote:

On 2006-08-28, sj*******@yahoo .com <sj*******@yaho o.comwrote:

Antoon Pardon wrote:

There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

I've _never_ seen a case where enforcing types in the manner of the OP
is appropriate.

It fails with trivial wrappers like

class myInt(int):
def printFormatted( self):
..........

Even looser checking with isinstance is rarely right. You may want to
exclude floats, but that doesn't mean you want to exclude int-like
objects that don't inherit from int.

That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

What the hell are you talking about?

I'm curious: what is the meaning, to you, of the word "this" in your
sentence above?

>
--
Antoon Pardon

[Antoon Pardon]

On 2006-08-29, Gabriel Genellina <ga******@yahoo .com.arwrote:

At Tuesday 29/8/2006 01:28, Antoon Pardon wrote:

Antoon Pardon wrote:
There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

I've _never_ seen a case where enforcing types in the manner of the OP
is appropriate.

It fails with trivial wrappers like

class myInt(int):
def printFormatted( self):
..........

Even looser checking with isinstance is rarely right. You may want to
exclude floats, but that doesn't mean you want to exclude int-like
objects that don't inherit from int.

That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

In any case, I don't see how this supports the original claim that
strict type checking input params is good practice.

I'm not defending that claim. I'm just putting question marks
with the claim that strict type checking input parameters is
bad practice.

--
Antoon Pardon

[Gabriel Genellina]

At Tuesday 29/8/2006 02:45, Antoon Pardon wrote:

>That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

In any case, I don't see how this supports the original claim that
strict type checking input params is good practice.

I'm not defending that claim. I'm just putting question marks
with the claim that strict type checking input parameters is
bad practice.

I think others have shown enough examples of good things that can be
done by *not* enforcing a specific type...

Gabriel Genellina
Softlab SRL

_______________ _______________ _______________ _____
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

[Antoon Pardon]

On 2006-08-29, Simon Forman <ro*********@ya hoo.comwrote:

Antoon Pardon wrote:

>On 2006-08-28, sj*******@yahoo .com <sj*******@yaho o.comwrote:

Antoon Pardon wrote:
There seem to be enough problems that work with ints but not with
floats. In such a case enforcing that the number you work with
is indeed an int seems fully appropiate.

I've _never_ seen a case where enforcing types in the manner of the OP
is appropriate.

It fails with trivial wrappers like

class myInt(int):
def printFormatted( self):
..........

Even looser checking with isinstance is rarely right. You may want to
exclude floats, but that doesn't mean you want to exclude int-like
objects that don't inherit from int.

That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

What the hell are you talking about?

Yes, I should have been more clearer.

I'm curious: what is the meaning, to you, of the word "this" in your
sentence above?

That something like "type(x) == int" or "isinstance (x, int)" doesn't
allow to check for all int like objects, nor that there is some python
idiom that should allow you to test for such a thing (although it might
be circumvented).

With that second sentence I mean that there could exist a python
convention that prescribed that all int like objects had to be
subtypes of int. In that case code that followed the convention
could use "isinstance (x, int)" to check for int like objects.

--
Antoon Pardon

[Antoon Pardon]

On 2006-08-29, Gabriel Genellina <ga******@yahoo .com.arwrote:

At Tuesday 29/8/2006 02:45, Antoon Pardon wrote:

>>That may be true. But one may wonder if this is a failing of the
programmer or a failing of the language that doesn't support
such things.

In any case, I don't see how this supports the original claim that
strict type checking input params is good practice.

I'm not defending that claim. I'm just putting question marks
with the claim that strict type checking input parameters is
bad practice.

I think others have shown enough examples of good things that can be
done by *not* enforcing a specific type...

That doesn't contradict that in other situations good things can be
done by enforcing specific type or at least limiting to a subset
of specific types.

--
Antoon Pardon