PEP 3107 and stronger typing (note: probably a newbie question)

[Bruno Desthuilliers]

Paul Rubin a écrit :
> Bruno Desthuilliers <bruno.42.desthuilliers at wtf.websiteburo.oops.com> writes:
> 
>>>If the assertion is wrong, the compiler signals an error.  In
>>>that sense it's like a unit test; it makes sure the function does what
>>>the user expects.
>>
>>It still boils down to the same problem : possibly valid types are
>>rejected based on a declaration.
> 
> 
> I'm not sure what you mean.  If the programmer intended for the
> function to compute an integer, then it's invalid for the function to
> return (say) a string, whether there is a static typecheck or not.

I was mostly thinking of inputs, but it's the same thing for outputs - 
in most cases the concrete "type" (=> class) of the object returned by a 
function is no more significant than the concrete type(s) of it's 
input(s). What is important is that these objects supports the 
(implicit) protocols expected by either the function itself (for inputs) 
or the caller (for output(s)). And FWIW, in Python, it's not unusual for 
a function or method to be able to return objects of any type - cf the 
dict.get(key, default=None) method.

(snip)

>>>However, that may be a self-fulfilling prophecy since maybe I'm
>>>cultivating a coding style that doesn't use the dynamism,
>>
>>Perhaps is this coding style not making the best use of Python's
>>features ? To me, it sounds like doing procedural programming in OCaml -
>>it's of course possible, but probably not the best way to use the language.
>  
> This is in principle possible, though I feel like I'm coding more
> effectively since gravitating to this style. 

> Anton van Straaten (a
> dynamic typing proponent) wrote of static checks
> (http://lambda-the-ultimate.org/node/2216#comment-31954):
> 
>     In most cases, the correctness proof itself is not the most important
>     advantage of static checking of a program. Rather, it's the type
>     discipline that must be followed in order to achieve that correctness
>     proof. The final proof is like the certificate you get when you
>     graduate from college: it's not that important by itself, but to have
>     obtained it you must have done a lot of work, at least some of which
>     is important and necessary. You can do the work without getting the
>     certificate, but many people don't, and in the programming case they
>     may pay a price for that in terms of programs with poor type
>     discipline, which can have consequences for reasoning and the
>     "ilities".
> 
> I coded a fair amount of Lisp before starting with Python though, so
> even before, I tended to code Python in a Lisp-like style, ignoring
> Python's more dynamic features such as metaclasses.

While my knowledge of Lisp is somewhat limited - I played with Common 
Lisp and Scheme (and Emacs Lisp) but never seriously used any Lisp 
dialect - it also had some influence on my coding style. But Python's 
support for "hi-level" programming - including the restricted support 
for functional approach - mostly comes from it's object model, and I 
prefer to take advantage of this object model instead of trying to write 
Lisp (or Haskell or whatever other FPL) in Python. A good example could 
be partial application - which in Python is better implemented as a 
class than using closures.

> I'd also compare the situation with Forth, where functions can consume
> and insert arbitrary numbers of values to the stack, but programmers
> in practice maintain careful stack discipline (making sure to pop and
> push a constant number of values, and documenting the meaning of each
> one) in order to avoid going crazy.  Just because the language offers
> you rope, doesn't mean you can't decline to hang yourself with it.

Indeed. But this doesn't mean you should not use the rope at all - 
specially when it happens to be the RightThing(tm) to do. Compare an old 
framework like Zope 2.x, and new ones (internally) making heavy use of 
metaclasses, descriptors etc, and you may find out that these features 
not only greatly help wrt/ both robustness (less boilerplate) and 
readability (less boilerplate), but also tend to encourage a more 
declarative style (.

> Finally, this article about "gradual typing" (you can write your code
> dynamically and then later add static annotations resulting in type
> safety) might be of interest:

I have too few problems with type errors to feel a need for more "type 
safety" than what Python actually provides, and I don't see the point of 
adding arbitrary restrictions. What's appropriate for language X is not 
necessarily appropriate for language Y, and I know where to find smart 
statically typed languages if and when I do need them.