On 21 April 2015 at 15:31, Chris Angelico <ros...@gmail.com> wrote: > Granted, there are some > vague areas - how many functions take a "file-like object", and are > they all the same? - but between MyPy types and the abstract base > types that already exist, there are plenty of ways to formalize duck > typing.
Are there? Can I have a link or an example, please? I feel like I don't know how I'm supposed to do this, and I'd like to see how that works. I'll even give a concrete use-case: I want to be able to take a file-like object that has a .read() method and a .seek() method. > And frankly, even with the uncertainties, I'd still rather > have a function declared as taking a "file-like object" than "an > object with a .read() method that takes an integer and returns up to > that many bytes of data, and a .seek() method that blah blah blah > blah". Sometimes, the precision is completely useless. It is completely useless. Happily, this is a strawman, and no-one was asking for it, so we can all live happily ever after! The correct specification is "read method with this type signature" and "seek method with this type signature". I would even be prepared to waive the type signatures on read and seek, given that enforcing the type hinting on others is not a good idea. I suspect I have a mismatch with several others in this discussion. My position is that if I'm going to have a type system, I'd like to have a powerful one: Haskell, not Java. Otherwise I'll get by with the duck typing that has worked just fine for us over the last 20 years. I suspect, however, that many others in this conversation want any type system at all, so long as they can have one. Is that an accurate characterisation of your position, Chris? _______________________________________________ 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
