In <@python.org>, Yacao Wang
wrote:
However, type signatures are not only a kind of information provided for
the compiler, but also for the programmer, or more important, for the
programmer. Without it, we have to "infer" the return type or required
agument types of a function, and this can't be done without seeing the
implementation of it,
That's what documentation is meant for. If you are forced to look at the
implementation, the documentation is bad.
Haskell can also determine type information dynamically, but it still
supports and recommends the programming style with type signatures,
Does Haskell really determine the type information dynamically!? AFAIK
it's done at compile time.
which makes the code very readable and maitainable. As I understand,
Python relies too much on run-time type-checking, that is, whenever you
give the wrong type, you just end up with an exception, which is
logically correct, but not that useful as type signatures. Any ideas on
this issue?
Which issue? ;-)
Just stop thinking in terms of types. Python is about *behavior*. If
the docs say `this functions takes an iterable as input` then `iterable`
isn't a specific type but an object that implements the behavior of an
iterable. You can't check that reliable without actually trying to
iterate over it. Search for "duck typing".
Ciao,
Marc 'BlackJack' Rintsch

Which is expecially true when using IDEs with auto-completion.
Using VisualStudio/MonoDevelop and C# I rarely need to look at the
documentation because I can quickly see what a method accept and returns.
And when I need to pass flags or options, enums are much more neat and
encapsulated.

With Python I'm constantly looking at the documentation when surfing a
library. I personally like the terse code and abstraction features of Python
which is making me slowly writing more and more tools in it. Still, I have
to agree that there are edges (like these) that must be sharpened out

7/24/06, paul <paul (AT) subsignal (DOT) orgwrote:

Marc 'BlackJack' Rintsch wrote:
In <@python.org>, Yacao Wang
wrote:
>
>However, type signatures are not only a kind of information provided
for
>the compiler, but also for the programmer, or more important, for the
>programmer. Without it, we have to "infer" the return type or required
>agument types of a function, and this can't be done without seeing the
>implementation of it,
>
That's what documentation is meant for. If you are forced to look at
the
implementation, the documentation is bad.
I think the P refers to reading the *code*, the documentation might not
exist (yet). Sometimes I feel python is easier to write than to read and
missing argument type declarations (just for documentation purposes)
are IMH one reason. Another are missing (optional) argument type
checks at runtime. Something like WrongArgumentType exceptions instead
of rather unspecific AttributeError from deep inside the code would be
very convenient.

Yes docstrings are nice but sometimes a simple:

foo(int:param1, string:param2) is way better than:

foo(param1, param2):
"""
@type param1: integer
@type parame2: string
"""

cheers
Paul

In <@python.org>, paul lle
wrote:

Marc 'BlackJack' Rintsch wrote:
>In <@python.org>, Yacao Wang
>wrote:
>
However, type signatures are not only a kind of information provided for
the compiler, but also for the programmer, or more important, for the
programmer. Without it, we have to "infer" the return type or required
agument types of a function, and this can't be done without seeing the
implementation of it,
>
>That's what documentation is meant for. If you are forced to look at the
>implementation, the documentation is bad.
I think the P refers to reading the *code*, the documentation might not
exist (yet).

It should be right there under the `def` as docstring.

Sometimes I feel python is easier to write than to read and
missing argument type declarations (just for documentation purposes)
are IMH one reason. Another are missing (optional) argument type
checks at runtime. Something like WrongArgumentType exceptions instead
of rather unspecific AttributeError from deep inside the code would be
very convenient.

The you start getting `WrongArgumentType` exceptions sooner or later for
arguments that have all the necessary attributes in place but are of the
wrong "type". Very inconvenient.

Ciao,
Marc 'BlackJack' Rintsch