Type signature
Hi, I'm a newbie to Python. I've recently read some books about this language and none of them have answered my question. As a dynamically-typed language Python doesn't need any form of type signature which makes the syntax very clean and concise. 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, and sometimes it is still difficult to extract the above information even if the implementation is available. Haskell can also determine type information dynamically, but it still supports and recommends the programming style with type signatures, 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? -- Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
In <[EMAIL PROTECTED]>, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
Yacao Wang wrote: > Hi, I'm a newbie to Python. I've recently read some books about this > language and none of them have answered my question. > As a dynamically-typed language Python doesn't need any form of type > signature which makes the syntax very clean and concise. OK... > However, type > signatures are not only a kind of information provided for the compiler Statically-typed code tends (generally) to be faster than dynamically-typed code, obviously. Often, it doesn't really matter, though. (This is an old argument.) Lush is an interesting Lisp-like language that supports admixture of dynamic and static typing, and uses type signatures to support it. It can produce high performance machine code because of this. > 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. As said before, polymorphism plays an important role. In addition to looking up 'duck typing' (c.f. Programming Ruby), it might also be useful to look for Damian Conway's observations on 'interface polymorphism' (standard practice in Perl, Python, Ruby, etc.) vs. 'inheritance polymorphism' (what you get with C++ and IIRC Java). -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
Yacao Wang wrote: > Hi, I'm a newbie to Python. I've recently read some books about this > language and none of them have answered my question. > As a dynamically-typed language Python doesn't need any form of type > signature which makes the syntax very clean and concise. 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, Reset your brain. Functions don't have required argument types, anything implementing the interface they use will work. e.g.: class a(object): def getVal(self): return "a_val" class b(object): def getVal(self): return "b_val" def someFunc(valObj): return valObj.getVal().upper() someFunc can take objects of class a or class b or any other class that has a getVal method returning something with an upper method (getVal doesn't even have to return a string as long as what it returns has an upper method). a and b don't share an inheritance hierarchy, either. There is no "type signature", there's just which methods/attributes are used by the function. Limiting it to only working on specified types is unnecessarily restrictive. > Haskell can also determine type information > dynamically Haskell does static type inference at compile time, not dynamic typing. It's a completely different programming model (shared with ML, among others) > 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. Dynamic typing is different from static typing, you're right, but it's not worse. You probably want to google for "duck typing" think about the implications on polymorphism. -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
Yacao Wang wrote: > Hi, I'm a newbie to Python. I've recently read some books about this > language and none of them have answered my question. > As a dynamically-typed language Python doesn't need any form of type > signature which makes the syntax very clean and concise. 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, and > sometimes it is still difficult to extract the above information even if the > implementation is available. Haskell can also determine type information > dynamically, but it still supports and recommends the programming style with > type signatures, 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? > > -- > Alex > Hi Yacao/Alex, Try these: "How to duck type? - the psychology of static typing in Ruby" http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511 "3-31-04 I'm Over It" http://66.102.9.104/search?q=cache:6XW473VSflcJ:www.mindview.net/WebLog/log-0053+%2B%22duck+typing%22+%2B+%22static+typing%22+%2Bpython&hl=en&gl=uk&ct=clnk&cd=3&client=firefox-a It seems that the latent or duck typing, used in dynamic languages is counter-intuitve to those from a static typing background. Nevertheless, it does work, and work well. - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
Marc 'BlackJack' Rintsch wrote: > In <[EMAIL PROTECTED]>, 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 OP 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 IMHO 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
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...On 7/24/06, paul kölle <[EMAIL PROTECTED]> wrote: Marc 'BlackJack' Rintsch wrote:> In <[EMAIL PROTECTED]>, 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 OP 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 IMHO one reason. Another are missing (optional) argument type checks at runtime. Something like WrongArgumentType exceptions insteadof rather unspecific AttributeError from deep inside the code would bevery 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-- http://mail.python.org/mailman/listinfo/python-list-- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85 -- http://mail.python.org/mailman/listinfo/python-list
Re: Type signature
In <[EMAIL PROTECTED]>, paul kölle wrote: > Marc 'BlackJack' Rintsch wrote: >> In <[EMAIL PROTECTED]>, 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 OP 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 IMHO 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 -- http://mail.python.org/mailman/listinfo/python-list
