4 ms·

My question is this: What happened to all the duck-typing evangelism? "If it walks like a duck and quacks like a duck, it is a duck", "static typing only catche

My question is this: What happened to all the duck-typing evangelism? "If it walks like a duck and quacks like a duck, it is a duck", "static typing only catches trivial errors", and so on.

nicolaslem 10y ago
Not a definitive answer to the problem but mypy supports a limited sets of common "interfaces", for instance dict-like or list-like. http://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html#standard-duck-types http://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html#st...
- raverbashing 10y ago
  Ah, that makes things better
- throwaway_374 10y ago
  That's right, mirroring the built in (3.x) abc collections heirarchy. Which then allows you to do interesting things like delegation based polymorphism by registering with the appropriate metaclass so - just to come back to your parent's point - interrogating the type reveals it to be list-like or dict-like.
jsmeaton 10y ago
Being able to lock down known interfaces can be beneficial, while leaving the rest open. Optional typing also lets you ignore the type hints when you really know what you want to do. > "static typing only catches trivial errors" To be honest I've not seen that sentiment very often, and it's definitely not something I agree with.
mattdeboard 10y ago
Everything is cyclical. Pain is forgotten, same mistakes are made, pain is rediscovered, relief is reinvented. I had a high school teacher who said something like, "I haven't bought new ties for 25 years. Why? Because things always go in and out of fashion. A particular tie might be out of fashion for ten years but it comes back eventually."
evgen 10y ago
I use typing at interface boundaries within code and sometimes between functions. Within a function I use duck typing. As others have mentioned, I use this more as an editor hint to warn me of questionable behavior and almost never run mypy. Yes, it only catches trivial errors, but a trivial error highlighted in the editor is easy to see/fix. The extra typing in the function sig is saved in not having to enter the same info in the docstring, so it feels like a wash to me.
deleted 10y ago
[deleted]
kwhitefoot 10y ago
> "static typing only catches trivial errors", That's partly because we tend to use the same types for everything. For instance in a spreadsheet you can subtract a column number from a row number and get no complaints even though the difference between the two quite likely makes no sense. If you have a separate type for row numbers and column numbers such mistakes can be caught.
- throwawayish 10y ago
  In your example you'd just have two different types with no subtraction operation defined between them. That has nothing to do with type hints. What you probably meant: This is where being strongly typed helps. Python is and always has been strongly typed.
lmm 10y ago
Back when static typing meant Java or worse, it was reasonable to think horribly verbose and clunky programming was inherent to static typing. But now we know better.
pmontra 10y ago
It's still here. Types don't matter in many scenarios. Example: get a parameter from a POST, use it as a key to query the db, store it into the db. Is it a string, is it an int? It doesn't really matter to the application because the db driver can handle that. Don't slow me down by making me look at the docs of what I really receive from the web server to declare a type. Multiply by some hundred or thousand times. Strongly typed languages only raise costs for my customers. Given that the budget is constant they get more features with dynamically typed languages. I'm not happy seeing language designers introducing strong or optional typing in languages that didn't have it, but I understand that their goals are different from the goals of the developers that use their languages. I'd say leave the core of Python (and Ruby [1]) alone: if we picked those dynamically typed languages in the last 25 years (they're that old) it means we like them so. We can use plenty of other languages if we really need types. [1] https://blog.heroku.com/ruby-3-by-3 https://blog.heroku.com/ruby-3-by-3 "Matz: ... the third major goal of the Ruby 3 is adding some kind of static typing whille keeping the duck typing, so some kind of structure for soft-typing or something like that. The main goal of the type system is to detect errors early. So adding this kind of static type check or type interfaces does not affect runtime."
- adwn 10y ago
  > Example: get a parameter from a POST, use it as a key to query the db, store it into the db. So you get a string, and you want to pass it unmodified to something that expects a string? The static typing answer is simple: Your variable is a string! How does that slow you down, or cost your customers a single cent?
  - pmontra 10y ago
    I really don't know if it's a string. AFAIK the framework could give my ints when it sees a number. I should check, but what for? I'll do the next time I need to do some math on those values and then forget again. They're not the things developers should waste time with.
    - alexvoda 10y ago
lngnmn 10y ago
The both statements you have quoted are still valid. Moreover, if you would think a bit you would realize that the world around you is duck-typed. At least at the level of proteins. One more thing. Every ontological attempt to use naive categories would fail and end up in duck-typing-like approach, because it reflects how the mother nature is.
OJFord 10y ago
There exist libraries that provide 'duck types' and other goodness for type hinting. typecheck [0] is one (which can also run-time enforce the check) used like: import typecheck as tc def logathing( dest: tc.hasattrs('write'), thing: tc.any(int, float, str), prefix: tc.optional(str)=None ): dest.write(prefix + str(thing) if prefix else str(thing)) [0] - https://github.com/prechelt/typecheck-decorator https://github.com/prechelt/typecheck-decorator

My question is this: What happened to all the duck-typing evangelism? "If it walks like a duck and quacks like a duck, it is a duck", "static typing only catches trivial errors", and so on.

nicolaslem 10y ago

Not a definitive answer to the problem but mypy supports a limited sets of common "interfaces", for instance dict-like or list-like. http://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html#standard-duck-types http://mypy.readthedocs.io/en/latest/cheat_sheet_py3.html#st...

raverbashing 10y ago
Ah, that makes things better
throwaway_374 10y ago
That's right, mirroring the built in (3.x) abc collections heirarchy. Which then allows you to do interesting things like delegation based polymorphism by registering with the appropriate metaclass so - just to come back to your parent's point - interrogating the type reveals it to be list-like or dict-like.

jsmeaton 10y ago

Being able to lock down known interfaces can be beneficial, while leaving the rest open. Optional typing also lets you ignore the type hints when you really know what you want to do. > "static typing only catches trivial errors" To be honest I've not seen that sentiment very often, and it's definitely not something I agree with.

mattdeboard 10y ago

Everything is cyclical. Pain is forgotten, same mistakes are made, pain is rediscovered, relief is reinvented. I had a high school teacher who said something like, "I haven't bought new ties for 25 years. Why? Because things always go in and out of fashion. A particular tie might be out of fashion for ten years but it comes back eventually."

evgen 10y ago

I use typing at interface boundaries within code and sometimes between functions. Within a function I use duck typing. As others have mentioned, I use this more as an editor hint to warn me of questionable behavior and almost never run mypy. Yes, it only catches trivial errors, but a trivial error highlighted in the editor is easy to see/fix. The extra typing in the function sig is saved in not having to enter the same info in the docstring, so it feels like a wash to me.

deleted 10y ago

[deleted]

kwhitefoot 10y ago

> "static typing only catches trivial errors", That's partly because we tend to use the same types for everything. For instance in a spreadsheet you can subtract a column number from a row number and get no complaints even though the difference between the two quite likely makes no sense. If you have a separate type for row numbers and column numbers such mistakes can be caught.

throwawayish 10y ago
In your example you'd just have two different types with no subtraction operation defined between them. That has nothing to do with type hints. What you probably meant: This is where being strongly typed helps. Python is and always has been strongly typed.

lmm 10y ago

Back when static typing meant Java or worse, it was reasonable to think horribly verbose and clunky programming was inherent to static typing. But now we know better.

pmontra 10y ago

It's still here. Types don't matter in many scenarios. Example: get a parameter from a POST, use it as a key to query the db, store it into the db. Is it a string, is it an int? It doesn't really matter to the application because the db driver can handle that. Don't slow me down by making me look at the docs of what I really receive from the web server to declare a type. Multiply by some hundred or thousand times. Strongly typed languages only raise costs for my customers. Given that the budget is constant they get more features with dynamically typed languages. I'm not happy seeing language designers introducing strong or optional typing in languages that didn't have it, but I understand that their goals are different from the goals of the developers that use their languages. I'd say leave the core of Python (and Ruby [1]) alone: if we picked those dynamically typed languages in the last 25 years (they're that old) it means we like them so. We can use plenty of other languages if we really need types. [1] https://blog.heroku.com/ruby-3-by-3 https://blog.heroku.com/ruby-3-by-3 "Matz: ... the third major goal of the Ruby 3 is adding some kind of static typing whille keeping the duck typing, so some kind of structure for soft-typing or something like that. The main goal of the type system is to detect errors early. So adding this kind of static type check or type interfaces does not affect runtime."

adwn 10y ago
> Example: get a parameter from a POST, use it as a key to query the db, store it into the db. So you get a string, and you want to pass it unmodified to something that expects a string? The static typing answer is simple: Your variable is a string! How does that slow you down, or cost your customers a single cent?
- pmontra 10y ago
  I really don't know if it's a string. AFAIK the framework could give my ints when it sees a number. I should check, but what for? I'll do the next time I need to do some math on those values and then forget again. They're not the things developers should waste time with.
  - alexvoda 10y ago

lngnmn 10y ago

The both statements you have quoted are still valid. Moreover, if you would think a bit you would realize that the world around you is duck-typed. At least at the level of proteins. One more thing. Every ontological attempt to use naive categories would fail and end up in duck-typing-like approach, because it reflects how the mother nature is.

OJFord 10y ago

There exist libraries that provide 'duck types' and other goodness for type hinting. typecheck [0] is one (which can also run-time enforce the check) used like: import typecheck as tc def logathing( dest: tc.hasattrs('write'), thing: tc.any(int, float, str), prefix: tc.optional(str)=None ): dest.write(prefix + str(thing) if prefix else str(thing)) [0] - https://github.com/prechelt/typecheck-decorator https://github.com/prechelt/typecheck-decorator