[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