Strategies for managing use of types in Python

Question

I'm a long time programmer in C# but have been coding in Python for the past year. One of the big hurdles for me was the lack of type definitions for variables and parameters. Whereas I totally get the idea of duck typing, I do find it frustrating that I can't tell the type of a variable just by looking at it. This is an issue when you look at someone else's code where they've used ambiguous names for method parameters (see edit below).

In a few cases, I've added asserts to ensure parameters comply with an expected type but this goes against the whole duck typing thing.

On some methods, I'll document the expected type of parameters (eg: list of user objects), but even this seems to go against the idea of just using an object and let the runtime deal with exceptions.

What strategies do you use to avoid typing problems in Python?

Edit: Example of the parameter naming issues: If our code base we have a task object (ORM object) and a task_obj object (higher level object that embeds a task). Needless to say, many methods accept a parameter named 'task'. The method might expect a task or a task_obj or some other construct such as a dictionary of task properties - it is not clear. It is them up to be to look at how that parameter is used in order to work out what the method expects.

Answer 1

As of Python 3, you can annotate at least function parameters and return values with types:

def foo(task: 'task') -> 'bool':
    pass

The type annotation can be any valid Python expression. In this case I used strings, but you can just as well use integers, dicts, lists, or – and that's the interesting bit – classes.

Answer 2

Write unit tests. They are also useful for typed languages, but in dynamic typed languages such as Python or Smalltalk unit tests give you the added bonus of type checking.

I'm not saying you should check types in the unit test, but that the test will probably fail if you use the wrong types.

edit:

But maybe I misunderstood your question. Are you having real productivity problems with weak typing in Python? Or are you just worried you will?

If its the former, go with TDD, it will also give you confidence in the code you are writing. If the latter, just go ahead and don't worry to much. When I first learned about Smalltalk I was coming from Java, and the weak typing issue surprised me. So the first thing I asked a veteran Smalltalk coder was:

-don't you have lot's of type-related runtime bugs?

-no, that was never a problem for me

Usually the weak-typed languages are more productive than the strong-typed, so any inconvenniences with typying is not a big deal.

Answer 3

I can't tell the type of a variable just by looking at it.

Why would you need to?

ambiguous names for method parameters.

Not sure what this could possibly mean. You'll have to provide examples.

I've added asserts to ensure parameters comply with an expected type but this goes against the whole duck typing thing.

Worse. It can break a perfectly good program by checking for too small a subset of legitimate types. Done badly, it makes subclass extensions difficult.

I'll document the expected type of parameters (eg: list of user objects)

Good.

but even this seems to go against the idea of just using an object and let the runtime deal with exceptions.

That's false. Documenting the interface to an object required by a method is a good thing. It doesn't "go against" anything.

def foo( self, some_object ):
    """some_object must have methods x() and y()."""
    some_object.x()
    some_object.y()

The docstring doesn't go against anything. It's perfectly correct. Perhaps unhelpful, but still correct.

What strategies do you use to avoid typing problems in Python?

You should choose better terms. There are no typing "problems".

What you're asking about is -- perhaps -- better called the transition discomfort. You have legacy habits built up around C#. It takes a while to get over those habits.

You don't mention unit testing. Why not?

Answer 4

The types a function expects should be ideally documented in the function's docstring (or by using the Python3 annotations). Then it's up to the caller of the function to provide the right kinds of ducks. This has the advantage that many Python IDEs use the first line of the docstring as a context help when hovering over a function/method name (in situations where the IDE is able to determine the type from context).

In most cases, the parameter names should make the expected type clear enough in the context of the given module. Your example sounds like you need to agree on some better conventions for parameter names instead of just using "task" for everything.