On Sun, 13 Apr 2014 15:59:36 -0400, Terry Reedy <tjreedy at udel.edu> wrote: > On 4/13/2014 4:11 AM, Åukasz Langa wrote: > > On Apr 13, 2014, at 12:48 AM, Stefan Behnel <stefan_ml at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4