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

Ethan Furman ethan at stoneleaf.us
Mon Aug 18 22:15:36 CEST 2014


After reading through the OST threads, and learning a bit more about what static typing means, and the difference 
between nominal and structural subclassing, I think I have a better appreciation for the knee-jerk "no way!" reaction, 
and also how to make what seems like a foreign-to-Python concept pythonistic.

The most-feared problem seems to be over-specification (it is certainly mine). I think the answer has been alluded to a 
couple times already, but just to hopefully bring it front and center:

Instead of either 'nominal' or 'structural', use our own 'dynamical' subclassing scheme.

In other words:

   def spamify(current: datetime.date, moved:int) -> bool:
      # ONE_DAY is a one day time delta, previously declared
      days = ONE_DAY * moved
      proposed_date = current + days
      return it_works(proposed_date)

The type checker will not look to see if 'current' is a datetime.date, but rather will check that what datetime.date's 
__add__ works with (datetime.delta) and then check that what is passed in for current has an __add__ that also works 
with datetime.delta.

I think this would be far more valuable than just nominal as it follows duck-typing, and hopefully less work than 
structural as it's only checking the methods and attributes actually used.

On the minus side, there are times when we need *exactly* a datetime.date, so we would need a way to specify exact vs 
dynamic, but dynamic should be the default.

--
~Ethan~


More information about the Python-ideas mailing list