On Sun, 13 Apr 2014 15:59:36 -0400, Terry Reedy <tjre...@udel.edu> wrote: > On 4/13/2014 4:11 AM, Åukasz Langa wrote: > > On Apr 13, 2014, at 12:48 AM, Stefan Behnel <stefan...@behnel.de> wrote: > > > >> Stefan Behnel, 12.04.2014 19:11: > >> > >> 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. --David
_______________________________________________ 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