type-checking support in Python?

[Joe Strout]

I'm just re-learning Python after nearly a decade away. I've learned
a good healthy paranoia about my code in that time, and so one thing
I'd like to add to my Python habits is a way to both (a) make intended
types clear to the human reader of the code, in a uniform manner; and
(b) catch any type errors as early and automatically as possible.

I found the "typecheck" module (http://oakwinter.com/code/typecheck/),
but I notice that it hasn't been updated since 2006, and it's not
included with the Python distribution. Are there other modules
providing similar functionality that I should consider instead?

Also, I'll probably be considering a lint-like tool at some point...
are there any that allow you to declare some extra type information,
and have that checked at lint time?

Finally, one thing I've considered is adopting some identifier
prefixes indicating type. Maybe "iFoo" for integer, "fFoo" for
floating-point numbers, "d" for dictionary, "l" for list, "t" for
tuple, "o" for object, and "v" for variable types that may be more
than one of the above. I gather (from just a couple days of browsing)
that such a naming convention isn't common in the Python community,
but is there anyone else here who does it? I'd rather adopt an
existing standard (even if it's not widely used) than make one up.

Many thanks,
- Joe

[Diez B. Roggisch]

Joe Strout wrote:

I'm just re-learning Python after nearly a decade away. I've learned
a good healthy paranoia about my code in that time, and so one thing
I'd like to add to my Python habits is a way to both (a) make intended
types clear to the human reader of the code, in a uniform manner; and
(b) catch any type errors as early and automatically as possible.

I found the "typecheck" module (http://oakwinter.com/code/typecheck/),
but I notice that it hasn't been updated since 2006, and it's not
included with the Python distribution. Are there other modules
providing similar functionality that I should consider instead?

Also, I'll probably be considering a lint-like tool at some point...
are there any that allow you to declare some extra type information,
and have that checked at lint time?

Finally, one thing I've considered is adopting some identifier
prefixes indicating type. Maybe "iFoo" for integer, "fFoo" for
floating-point numbers, "d" for dictionary, "l" for list, "t" for
tuple, "o" for object, and "v" for variable types that may be more
than one of the above. I gather (from just a couple days of browsing)
that such a naming convention isn't common in the Python community,
but is there anyone else here who does it? I'd rather adopt an
existing standard (even if it's not widely used) than make one up.

The short answer is:

- don't use typechecks, or at least as few as possible - only for
polymorphy. Ducktyping is important for good python code, and shouldn't be
prevented by excessive typechecks.

- if you don't trust your code, write tests. Actually, *always* write
tests. It really helps getting the design of your code better, saves time
when refactorings or enhancements are needed - and captures more errors
that static typechecking - and your typechecking actually isn't even static
& thus you'd need tests to get code coverage anyway.

- don't adopt these silly microsoft perversion of hungarian notation.
clear, expressive variable names - sure. with pre- or suffixes to indicate
their kind, possible. But using iX or fX where all one cares is that X
holds a number is not helpful.

Diez

[Bruno Desthuilliers]

Joe Strout a écrit :

I'm just re-learning Python after nearly a decade away. I've learned a
good healthy paranoia about my code in that time, and so one thing I'd
like to add to my Python habits is a way to both (a) make intended types
clear to the human reader of the code,

Good naming and documentation.

in a uniform manner; and (b)
catch any type errors as early and automatically as possible.

For which definition of "type error" ?-)

To make a long story short, duck typing is the pythonic way to do
things. From experience, type errors are rare, and usually very quickly
spotted and fixed. Except when it comes to handling user inputs, don't
bother coding in a defensive style. Just write the minimal necessary
code, and only worry about exceptions you somehow except *and* can
handle locally.

I found the "typecheck" module (http://oakwinter.com/code/typecheck/),
but I notice that it hasn't been updated since 2006, and it's not
included with the Python distribution. Are there other modules
providing similar functionality that I should consider instead?

yes : unittests.

Also, I'll probably be considering a lint-like tool at some point... are
there any that allow you to declare some extra type information, and
have that checked at lint time?

Not AFAIK. This may come with py3k using ABCs and type annotations, but
once again, don't worry too much about this.

I know these advices may sound scary to declarative static typing
addicts, but man/years of experience have proven that duck typing
JustWork(tm). So don't fight the language, it would only make you suffer
useless pain and frustration.

Finally, one thing I've considered is adopting some identifier prefixes
indicating type.

Don't.

Maybe "iFoo" for integer, "fFoo" for floating-point
numbers, "d" for dictionary, "l" for list, "t" for tuple, "o" for
object,

Then you can already prefix each and any of your identifiers (including
classes and functions) with an 'o', since everything in Python is an
object !-)

I gather (from just a couple days of browsing) that such a
naming convention isn't common in the Python community,

It's not only uncommon, but - just like useless typechecking -
considered bad form.

but is there
anyone else here who does it? I'd rather adopt an existing standard
(even if it's not widely used) than make one up.

The standard coding conventions are here:
http://www.python.org/dev/peps/pep-0008/

FWIW, Python relies quite heavily on naming conventions. Better to stick
to pep8.

[Kay Schluehr]

On 6 Okt., 16:19, Joe Strout <[e-mail]:

I'm just re-learning Python after nearly a decade away. *I've learned *
a good healthy paranoia about my code in that time, and so one thing *
I'd like to add to my Python habits is a way to both (a) make intended *
types clear to the human reader of the code, in a uniform manner; and *
(b) catch any type errors as early and automatically as possible.

I found the "typecheck" module (http://oakwinter.com/code/typecheck/), *
but I notice that it hasn't been updated since 2006, and it's not *
included with the Python distribution. *Are there other modules *
providing similar functionality that I should consider instead?

Incidentally I started to use the typecheck package just yesterday.
It's not that I'm using it in a typical application but I'm working on
a mapping of a statically typed language onto a Python framework that
emerges in parallel. So I have to rebuild the type semantics of the
original language in Python but defer typechecks until runtime.

My impressions so far have been mixed. I stumbled across some strange
failures that required uncommenting source code in the typecheck
package which might cause failures elsewhere. I also hit a barrier
when working with methods instead of functions. I also noticed that
passing two strings to a funtcion:

@accepts(Number, Number)
def add(x,y):
return x+y

is acceptable behaviour.

From all those experiences I'd rate the package alpha and I'm sad
noticing that it is apparently abandonware. I'll continue to use it
nevertheless.

[Lawrence D'Oliveiro]

In message
<70**********************************@v72g2000hsv. googlegroups.com>, Kay
Schluehr wrote:

... and I'm sad noticing that it is apparently abandonware.

In Open Source, nothing is ever truly abandonware unless nobody cares about
it any more. :)