[Types-sig] check_type()

Paul Prescod paul@prescod.net
Wed, 15 Dec 1999 10:38:21 -0800

> > original RFC spelled this as:  has_type( foo, types.StringType ) which
> > returns (in this case) a string or NULL. This strikes me as more
> > flexible than ! because you can use it in an assertion but you don't
> > have to. You can also use it like this:
> >
> > j=has_type( foo, types.StringType ) or has_type( foo, types.ListType ):
> You'll have issues with empty strings and empty lists, as Guido pointed
> out.

Yes, you have to use it in ways that follow Python's boolean rules. A
better name would be check_type.

j=check_type( foo, types.StringType ) 

> has_type() does not create a *definitive* type assertion. The compiler
> cannot extract any information from the presence of has_type(). Using an
> operator which raises an exception allows the compiler to make the
> assertion (and thereby assist with type inferencing and type checking).

j=check_type( foo, types.StringType)

j is *guaranteed* to be either a string or None.

Note that check_type is actually an operator in that it cannot be
overwritten or shadowed. It just happens to be an operator that looks
like a function and that returns a useful value instead of immediately
causing an exception. It also happens to be compatible with the current
Python grammar.

I have big aesthetic problems with adding a special character to a
language that uses the word "or" to mean, well "or" and "not" to mean
"not". I might be able to live with 

"k = eval('1') as int"

if it isn't too horribly ambiguous. 

Sorry, I've seen so many posts back and forth that I can't remember what
the consensus on this was. That's my fault as moderator. 

We'll have to start focusing on individual issues soon because the
fireman's hose approach is reaching its limits (but it was great at

 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time