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

[Marc 'BlackJack' Rintsch]

In <11************ **********@p79g 2000cwp.googleg roups.com>, asincero
wrote:

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"?

Not really the Python way I'd say. What if `c` is of type `long` for
instance? Your code would stop with an assertion error for a value that
should work. Strict type checking prevents "duck typing" which is a quite
fundamental concept in Python.

Ciao,
Marc 'BlackJack' Rintsch

[skip]

ArcadioWould it be considered good form to begin every method or
Arcadiofunction with a bunch of asserts checking to see if the
Arcadioparamete rs are of the correct type (in addition to seeing if
Arcadiothey meet other kinds of precondition constraints)?

If it works for you. It's not generally considered Pythonic though. You
should probably read up on "duck typing". Some food for thought: Do you
normally care that the object passed to foo() is a real honest-to-goodness
file object, or do you just care that it has a write() method? You will
learn soon enough if it doesn't, and not that much later than if you have an
assert at the beginning of your function. Of course, sometimes you do truly
care about the type of an object. Then you test. When you care.

ArcadioThis is something I miss from working with more stricter
Arcadiolanguage s like C++, where the compiler will tell you if a
Arcadioparamete r is the wrong type.

It's a mistake to think that Python's typing is somehow less strict than
C++'s. It's not like Perl where 1 + "2" is valid. It's simply that its
type checks are performed at run-time, not at compile-time. If you're
desparate to have some assistance with your code before you run it, check
out pylint and pychecker.

Skip

[hiaips]

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 (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

Many developers who move from a statically-typed languages to dynamic
ones go through this same sort of thought process. I was no different
in that regard, but as I've done more and more Python, I've found that
I just don't encounter type issues all that often. Above all, I see
duck typing as a net benefit - its inherent flexibility far outweighs
the lack of "compile-time" type safety, in my mind.

Along these lines, I'll point you to this article by Bruce Eckel called
"Strong Typing vs. Strong Testing":
http://www.mindview.net/WebLog/log-0025. The bottom line: Focus on unit
tests rather than explicit type checks when you want to verify the
runtime safety of your code. You'll find many more errors this way.

Hope this helps...
--dave

[sjdevnull]

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 (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

That's bad form. If you insist on doing something like this, at least
use "isinstance (a, str)" instead of typeof. But even that breaks duck
typing; if a is a unicode string, that'll fail when the function may
work fine for unicode strings.

You could, of course, test explicitly for the interface you need (e.g.
if you need a to have "lower" and "rjust" methods, do assertion tests
for them). But in practice you're generally better off simply using
the object and getting the exception a few lines lower.

Much of the power of dynamic typing comes from the duck typing concept,
so you should really try to familiarize yourself with it.

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.

Stricter is the wrong word. Python is strictly typed. The difference
here is dynamic vs. static typing.

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"?

There are 3 main things that you can do to help here:
1. Choose better names for the arguments so that it's obvious what they
are. I don't advocate Hungarian naming, normally something like "url"
or "shoeSize" will be strongly indicative of what kinds of values are
acceptable.
2. Write docstrings. That will not only document the types but also
how they're used, what gets returned, and perhaps limits on exactly
what ranges of values are acceptable.
3. Write unit tests. They'll catch far more errors than static typing
ever will.

[Qiangning Hong]

On 24 Aug 2006 20:53:49 -0700, sj*******@yahoo .com <sj*******@yaho o.comwrote:

That's bad form. If you insist on doing something like this, at least
use "isinstance (a, str)" instead of typeof. But even that breaks duck
typing; if a is a unicode string, that'll fail when the function may
work fine for unicode strings.

To check both str and unicode, you could use "isinstance (a, basestring)".

[Simon Forman]

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 (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

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

FWIW, if I saw code that that you presented here I'd assume the
programmer who wrote it was either very new(-bie-ish) or just very very
paranoid, so I guess I could say it's not pythonic... :-)

BTW, speaking of "strictness ", "more stricter" is invalid English,
just "stricter" is the "correct" form. ;-)

Peace,
~Simon

[Hendrik van Rooyen]

"Simon Forman" <ro*********@ya hoo.comwrote:

8<-------------------------------------------------------------

| BTW, speaking of "strictness ", "more stricter" is invalid English,
| just "stricter" is the "correct" form. ;-)

or alternatively the construct "more strict" is also acceptable - Hendrik

[Antoon Pardon]

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

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 (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

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?

--
Antoon Pardon

[Scott David Daniels]

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

--Scott David Daniels
sc***********@a cm.org