Strategie per la gestione dell'uso dei tipi in Python

A partire da Python 3, puoi annotare almeno i parametri delle funzioni e restituire i valori con i tipi:

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

L'annotazione del tipo può essere qualsiasi espressione Python valida. In questo caso ho usato le stringhe, ma puoi anche usare interi, dicts, liste o - e questo è l'interessante bit-classes.

Scrivi test unitari. Sono anche utili per i linguaggi tipizzati, ma in linguaggi tipizzati dinamici come i test di unità Python o Smalltalk ti danno il vantaggio aggiuntivo del controllo dei tipi.

Non sto dicendo che dovresti controllare i tipi nel test di unità, ma che probabilmente il test fallirà se usi i tipi sbagliati.

modifica

Ma forse ho frainteso la tua domanda. Stai riscontrando problemi di produttività reali con una digitazione debole in Python? O sei solo preoccupato che lo farai?

Se è il primo, vai con TDD, ti darà anche fiducia nel codice che stai scrivendo. Se quest'ultimo, vai avanti e non preoccuparti troppo. Quando ho saputo di Smalltalk per la prima volta, venivo da Java e il debole problema di digitazione mi ha sorpreso. Quindi la prima cosa che ho chiesto a un veterano di Smalltalk è stata:

-non hai molti bug di runtime relativi al tipo?

-no, non è mai stato un problema per me

Di solito i linguaggi tipizzati in modo debole sono più produttivi dei caratteri forti, quindi qualsiasi inconvertimento con la dattilografia non è un grosso problema.

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

Perché dovresti?

ambiguous names for method parameters.

Non sei sicuro di cosa potrebbe significare. Dovrai fornire esempi.

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

Peggio. Può rompere un programma perfettamente funzionante controllando un sottogruppo di tipi legittimi troppo piccolo. Fatto male, rende difficili le estensioni delle sottoclassi.

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

Bene.

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

Questo è falso. Documentare l'interfaccia con un oggetto richiesto da un metodo è una buona cosa. Non "va contro" nulla.

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

La docstring non va contro nulla. È perfettamente corretto Forse non utile, ma comunque corretto.

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

Dovresti scegliere termini migliori. Non ci sono "problemi" di battitura.

Ciò che stai chiedendo è - forse - meglio chiamato il disagio della transizione. Hai abitudini legacy costruite attorno a C #. Ci vuole un po 'per superare quelle abitudini.

Non parli dei test unitari. Perché no?

I tipi che una funzione si aspetta dovrebbero essere idealmente documentati nella docstring della funzione (o usando le annotazioni Python3). Quindi tocca al chiamante della funzione fornire i giusti tipi di anatre. Questo ha il vantaggio che molti IDE Python utilizzano la prima riga della docstring come guida contestuale quando si passa sopra un nome di funzione / metodo (in situazioni in cui l'IDE è in grado di determinare il tipo dal contesto).

Nella maggior parte dei casi, i nomi dei parametri dovrebbero rendere il tipo previsto abbastanza chiaro nel contesto del modulo specificato. Il tuo esempio sembra che tu debba concordare alcune convenzioni migliori per i nomi dei parametri invece di usare semplicemente "compito" per tutto.