3 ms·

The advantage of Python is that you do not need to think about type labels: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probabl

by d0mine 10y ago

The advantage of Python is that you do not need to think about type labels: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck." For example, the builtin print() function accepts any object with write(string) method as the file parameter. There are ABCs classes that capture the "duck" essence but it would be an unnecessary pessimization to require a io.TextIOBase instance as the file parameter in this case. Don't write Java in Python. Go's io.Writer would work in this case (the type label as the documentation and the exact specification) but if you don't mind thinking about type labels and/or believe that the type of bugs that can be found by a compiler worth the trouble instead of just writing tests and expressing directly what you want the code to do then using a statically typed language make sense. Though there are type hints (proposed by BDFL) in the recent Python (to enable better static analysis, IDEs code completion and refactoring) https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html If its usage is not limited (e.g., through Python culture convention); it could be a regression in Python evolution. If your API is so enormous that you need type labels; you should split it. Python code should communicate the intent to a human first over a compiler/static analysis tool. Here's a static typing programmer perspective (how it feels) on dynamic languages "What is the appeal of dynamically-typed languages?" https://gist.github.com/non/ec48b0a7343db8291b92 https://gist.github.com/non/ec48b0a7343db8291b92

snovv_crash 10y ago
Wholly agreed about not writing Java in Python, and I do write idiomatic Python. The problem is that I don't know what methods the returned objects have available, and as such whether they are a duck or a tiger. The examples show that it has a mouth and eyes, but I need to know whether it has wings or claws, and Python's docs don't make that clear. Can I index the returned object, or only iterate over it? Is it mutable? Is it a dict or a tuple of (key,value) tuples? Did the author think it was worth it to make its own class for the return type, because they want the indexes where the value was found as well as the metadata? Python, to a degree, brushes over these problems by being able to print out most types of data and then figure out where the problem is, but TBH I'd prefer to write the correct code to begin with, and the docs don't give me enough information to do so. As such, Python turns into a dodge-the-error-driven-programming, and I feel much less productive than I could be. Yes, duck-typing gets you part of the way, but it doesn't let you pretend type doesn't exist entirely. I feel like using Go's interfaces would be more powerful for a duck-typing language than having type-annotations.
- lqdc13 10y ago
  "The problem is that I don't know what methods the returned objects have available, and as such whether they are a duck or a tiger." I don't get this... Why not do the following: In [1]: import requests In [2]: resp = requests.get('http://www.google.com') In [3]: resp. resp.apparent_encoding resp.iter_lines resp.close resp.json resp.connection resp.links resp.content resp.ok resp.cookies resp.raise_for_status resp.elapsed resp.raw resp.encoding resp.reason resp.headers resp.request resp.history resp.status_code resp.is_permanent_redirect resp.text resp.is_redirect resp.url resp.iter_content Now you can try each of those things and explore their methods.
  - natch 10y ago
    >>> import requests Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'requests' Now, what was your question?
  - snovv_crash 10y ago
    Because I'm not always scripting - sometimes the work I'm doing takes 10 minutes of runtime to get to the end and I want to know what I'm writing before I run it. If Python wants to remain a scripting language forever then the docs are sufficient. But if it wants to graduate, and it seems a lot of people think it already has, then the libraries need to be better documented.
- d0mine 10y ago
  If you don't know whether a method returns an iterator or a mutable/immutable sequence (regardless of the specific type) then the documentation is incomplete (it is a bug). If it is in stdlib; you could submit a documentation patch for a *.rst file on https://bugs.python.org/ https://bugs.python.org/ See https://docs.python.org/devguide/docquality.html https://docs.python.org/devguide/docquality.html

by d0mine 10y ago

snovv_crash 10y ago

Wholly agreed about not writing Java in Python, and I do write idiomatic Python. The problem is that I don't know what methods the returned objects have available, and as such whether they are a duck or a tiger. The examples show that it has a mouth and eyes, but I need to know whether it has wings or claws, and Python's docs don't make that clear. Can I index the returned object, or only iterate over it? Is it mutable? Is it a dict or a tuple of (key,value) tuples? Did the author think it was worth it to make its own class for the return type, because they want the indexes where the value was found as well as the metadata? Python, to a degree, brushes over these problems by being able to print out most types of data and then figure out where the problem is, but TBH I'd prefer to write the correct code to begin with, and the docs don't give me enough information to do so. As such, Python turns into a dodge-the-error-driven-programming, and I feel much less productive than I could be. Yes, duck-typing gets you part of the way, but it doesn't let you pretend type doesn't exist entirely. I feel like using Go's interfaces would be more powerful for a duck-typing language than having type-annotations.

lqdc13 10y ago
"The problem is that I don't know what methods the returned objects have available, and as such whether they are a duck or a tiger." I don't get this... Why not do the following: In [1]: import requests In [2]: resp = requests.get('http://www.google.com') In [3]: resp. resp.apparent_encoding resp.iter_lines resp.close resp.json resp.connection resp.links resp.content resp.ok resp.cookies resp.raise_for_status resp.elapsed resp.raw resp.encoding resp.reason resp.headers resp.request resp.history resp.status_code resp.is_permanent_redirect resp.text resp.is_redirect resp.url resp.iter_content Now you can try each of those things and explore their methods.
- natch 10y ago
  >>> import requests Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'requests' Now, what was your question?
- snovv_crash 10y ago
  Because I'm not always scripting - sometimes the work I'm doing takes 10 minutes of runtime to get to the end and I want to know what I'm writing before I run it. If Python wants to remain a scripting language forever then the docs are sufficient. But if it wants to graduate, and it seems a lot of people think it already has, then the libraries need to be better documented.
d0mine 10y ago
If you don't know whether a method returns an iterator or a mutable/immutable sequence (regardless of the specific type) then the documentation is incomplete (it is a bug). If it is in stdlib; you could submit a documentation patch for a *.rst file on https://bugs.python.org/ https://bugs.python.org/ See https://docs.python.org/devguide/docquality.html https://docs.python.org/devguide/docquality.html