The Artima Developer Community
Sponsored Link

Weblogs Forum
Python Optional Typechecking Redux

36 replies on 3 pages. Most recent reply: Mar 28, 2006 8:03 PM by James Merrill

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 36 replies on 3 pages [ « | 1 2 3 ]
joe blow

Posts: 1
Nickname: encanto
Registered: Feb, 2005

Re: Python Optional Typechecking Redux Posted: Feb 13, 2005 4:04 PM
Reply to this message Reply
Advertisement
Oh please. Can we get past the love affair with dynamic type checking? Dynamic type checking was a cool idea 30 years ago, but not it has been put into ancient history by
type inferencing. I am forced to use python at work and I hate it. Even 20 years ago Common Lisp gave you the option of listing types to improve performance. Thus, in my book, python isn't even up to the level of common lisp 20 years ago.

Why does the industry insist on being so behind the research community? Most people that have used a type inferencing language swear that it is a major advance in technology. But we are still stuck using python which is pre-common-lisp in sophistication.

Oren Tirosh

Posts: 3
Nickname: orentirosh
Registered: Feb, 2005

Re: Python Optional Typechecking Redux Posted: Feb 13, 2005 5:23 PM
Reply to this message Reply
I know the purpose of optional type checking is not improving performance but it should not harm performance too much, either. Function calls are already pretty expensive in Python. I think optimization is not premature when it comes to adding a call to a complex function for each argument of each method call.

It would be nice if the results of type checking could be cached. Some objects derive their signature from their type while others can have a different signature for each instance (e.g. functions). But for most programs the number of signature pairs tested should be limited and covered pretty quickly, reaching a cache hit rate of 100%. This reduces the overhead of type checking to a hash table lookup per argument. For caching to work correctly signatures must be immutable objects.

What about adaptation? The adaptation "plugin" would be called only when the argument signature check fails. This is less flexible than the proposed __typecheck__ function which can do virtually anything. I don't necessarily see this limitation as a bad thing. The result of the adaptation function should be tested again for compliance with the signature and an exception raised if it fails to adapt the argument to something matching the signature.

There are some problems with python's dynamic nature, of course. Instance members can mask inherited methods, changing the object's signature. Class objects may be modified at runtime, changing the signatures of all derived classes. Recalculating the signatures for all derived classes would be expensive. I guess they could be invalidated and recalculated on demand. Here Be Dragons.

Benjamin Travis Hamilton

Posts: 1
Nickname: nebulous
Registered: Mar, 2005

Re: Python Optional Typechecking Redux Posted: Mar 2, 2005 4:48 PM
Reply to this message Reply
I think that adding typechecking is nice but doesn't it make the current class implementation look even more useless for the novice? I mean I think its confusing and thats my problem with it. Decorators? OK I can't use them and it makes me mad.

Reliability can come from permanent types and no conversion or predictable conversion. Fortran is less confusing type wise, and its fast and reliable (I think). Reliable is when something breaks in the code and it still runs fine. sometimes python magically does this.

Also speed is what I'm after and automatic guis and easy programming that stays fun. Typing sounds like a fun hack
and another notch on the proverbial totem pole.

But I shouldn't complain python is still great and if history repeats typing will be easy to use (unlike decorators, what the heck a sub interpreter/clickable assembler would be more fun).

Python rulez!

Ronald Adam

Posts: 5
Nickname: ron100
Registered: Mar, 2005

Re: Python Optional Typechecking Redux Posted: Mar 15, 2005 2:53 PM
Reply to this message Reply
I'm probably suggesting something that's already been ruled out sometime ago, if so, please disregard this if it's been voted out already.

I think having the option to use types constraints optional or on the fly is a good idea and can further pythons use in areas that require higher confidence.

If the following can be considered true:( Now or in the future. )

* Every object knows it's own type.
* Some objects may know how to convert it's self to another type if asked to.
* Every name in name space has a type preference associated with it, which may be 'none' or 'any'.
* Then when ever an object is attached to a name, the name type preference must match the objects type.
* If in the case they do not match, then the object is asked to change if it knows how.
* If it can't change, then a 'unmatched type' error is produced.

So considering the above, the name is created with a type preference and assigned to an object at the same time.

a:int = 1

I'm not sure I care for the use of : and -> symbols. They are short and concise, but also can be confusing. I would
prefer the use of something more readable.

a of 'int' = 1

name [of 'type'] = object

where the [of 'type'] is optional and has the meaning of:

"From now on, this name can only be pointed to objects of this type."

I know this creates new syntax, but I feel 'type' is a very fundamental concept, so do you want it out front and explicit, or do you want to combine it within other syntax, which I feel makes it less readable and harder to implement.

Having the type specified as a string has some advantages that we can have many types.

class point3d:
def __init__( self ):
self.x = 0
self.y = 0
self.z = 0

efg of 'point3d' = point3d()

In functions, I think having the variables in the function reassigned to types is enough. Using a:'int' might be considered as a way to give names a preference in advance.


def xyz( a, b):
a of 'int' = a # Reassign with type constraint
b of 'int' = b # could cause conversion if not the
# same, or an error message.
c = a * b**2
return c

Would be the same as the above, and might be a little faster:

def xyz( a:'int', b:'int'):
c = a * b**2
return c


The returned value is typed checked when it is given to
receiving name and object, where we need it.

a = 5
b = 2
result of 'int' = xyz( a, b)

The name type preferences in this way could be reassigned, so it doesn't force, tie. optional, the types.

a of 'int' = 5
a of 'float' = 5.3
a = 3 # conversion takes place due to type mismatch.
a = 'woah' # generates an 'type mismatch' error
a of 'none' = 'anything' # remove a type preference

And for exceptions:

try:
a of 'outerspace' = underwater()
except:
print 'Deploy lifeboats!'


I'm not proficient enough to know how the insides should work, so this may be totally unworkable. But maybe there's some good ideas or concepts.

Would it be possible subdivided name space into sets of 'types' as a way to give them 'type' preferences without causing a performance hit?

Done thinking out loud,
Ron

Tom Brazier

Posts: 3
Nickname: wibble
Registered: Feb, 2006

Re: Python Optional Typechecking Redux Posted: Feb 19, 2006 10:42 AM
Reply to this message Reply
Many posts seem to agree that none of the solutions suggested so far adequately support duck typing. I'd like to suggest a paradigm that I think is compatible with Guido's original suggestion and does support duck typing.

I think we can do this by borrowing the idea of a contract used in the C++ const construct. In C++, the line

void foo(const bar)

holds a contract (enforced by the compiler) that bar will not be changed by function foo(). Could we say that, in Python, the line

def foo(bar: t1):

holds a contract (enforced by the runtime checking system) that foo() will only treat bar as if it were of type t1. This turns the meaning of type checking on its head; we are no longer performing any checking on bar at all, the checking is now all on foo. Consequently, bar can be any type that is suitably t1-like, in particular it can be duck typed.

An immediate question is whether this idea can be implemented in a suitably Pythonic fashion. One possiblity is for Guido's __typecheck__() function to wrap bar with a type checker that is invoked whenever bar is used. A very simple (and incomplete) example would be:

class TypeCheckWrapper(object):
def __init__(self, x, T):
self.x = x
self.T = T
def __getattr__(self, name):
try: self.T.getattr(name)
except: raise TypeError("...")
return self.x.getattr(name)

def __typecheck__(x, T):
if isinstance(x, T): return x
else: return TypeCheckWrapper(x, T)

In the real world, TypeCheckWrapper would have to be a lot more sophisticated, but you get the idea.

I can see a number of potential implementation difficulties, including performance costs and the fact that the wrapper will not be of type x.__class__ and so will behave incorrectly with functions like isinstance(). These may or may not be solvable by some more cunning implementation.

However, setting implementation questions aside, I'd be interested to know whether there is any interest in the contract paradigm itself. Also whether anyone can figure out how typed return values would fit into this paradigm.

James Merrill

Posts: 2
Nickname: jvmerrill
Registered: Mar, 2006

Re: Python Optional Typechecking Redux Posted: Mar 28, 2006 7:50 PM
Reply to this message Reply
I could not have said it better myself. "Duck typing" is totally not-amenable to interface (etc) defn as an alternative, without all the BS that other languages hit.

James Merrill

Posts: 2
Nickname: jvmerrill
Registered: Mar, 2006

Re: Python Optional Typechecking Redux Posted: Mar 28, 2006 8:03 PM
Reply to this message Reply
Oops -- that was my first post; I had clicked "Reply" next to a particular message, and didn't realize that my response would not be "threaded" to the message to which I was replying.

I was responding to Nicolas Lehuen's post of 19Jan05 and its "three consequences", and his desire for the community to work on other things that are more important.

Sorry. (Is there a way to kill, or edit, our own posts?)

Flat View: This topic has 36 replies on 3 pages [ « | 1  2  3 ]
Topic: Think from the User In Previous Topic   Next Topic Topic: The Thinking in Java Conference

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use