On 04/13/2014 04:58 PM, R. David Murray wrote:
On Sun, 13 Apr 2014 15:59:36 -0400, Terry Reedy wrote:
On 4/13/2014 4:11 AM, �ukasz Langa wrote:
On Apr 13, 2014, at 12:48 AM, Stefan Behnel wrote:
So, what I've learned from seven years of Cython is that static typing in
signatures is actually less interesting than you might think at first
sight. It might be ok for documentation purposes, although its verboseness
makes that also a bit questionable.
You raise a valid point that type hinting a dict instead of a Mapping is
likely to create an overly limiting API. This sort of error is however
quite easy to fix forward.
To counter, we’ve had multiple data points during the summit suggesting
that duck typing is not really that often used in production code. In
other words, after initial prototyping and testing, an API of a callable
gets settled and is later used with a very limited number of types.
For public library code, where the use case is not known, apis should
usually be as generic as sensible. For private library code, I can
imagine that apis are and possibly even should be limited to classes
actually used. There naturally is a bit of a bias here for public code.
The way *I* heard it was that types of the input arguments did not, in
general, change *during the running of an application*. That doesn't
mean that the types wouldn't be different in a different application,
which means that in a library that duck types, duck typing is indeed used
in production, it's just that the types don't *change* for a production
application. So, yeah, pretty much what Terry said about library code
versus application code. That is, after all, what duck typing is about,
and there is a *reason* we use it.
Personal experience: I have my own copy of paramiko because it type checks for
strings, and I routinely use a str-subclass.
--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
