[Python-ideas] Optional Static Typing -- the Python Way

Cem Karan cfkaran2 at gmail.com
Sun Aug 24 02:37:34 CEST 2014


As others have said on the list, 'go away for a few days, and find a mega-thread in your inbox'.  Yay.

On Aug 19, 2014, at 1:01 PM, Guido van Rossum <guido at python.org> wrote:

> On Tue, Aug 19, 2014 at 6:27 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> [Agreeable musings about team size...]
> 
> Ultimately, my perspective is that Guido's proposal boils down to
> having a nice syntax where:
> 
>     def myfunc(a : KindX, b: KindY, c: KindZ):
>         ...
> 
> is the moral equivalent of:
> 
>     def myfunc(a, b, c):
>         assert isinstance(a, KindX)
>         assert isinstance(b, KindY)
>         assert isinstance(c, KindZ)
> 
> Please no. The asserts affect runtime. The type declarations are for linting, IDEs and docs. I don't want the difference to be swept under the rug. I want it to be the key feature of the proposal.

<SNIP>

Going slightly sideways on this -- I think this is why we should use decorators instead of annotations; as has already been mentioned twice on the list, http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ does a good job pointing out that static and dynamic typing systems are separate but overlapping concepts.  It also points out that both have their place.  If we define decorators that can be turned on or off easily (command-line option?  Environment variable? other?), then the end user can choose if if her or she is going to do static, dynamic, both, or none.  This could be useful when trying to track down that annoying bug in long-running production code.

Also, Types and Programming Languages by Dr. Pierce has been mentioned at least twice as well; would it be useful to ask him to join in the discussion?

Thanks,
Cem Karan


More information about the Python-ideas mailing list