An Object's Type

[bg_ie]

Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

Thanks,

Barry

[Diez B. Roggisch]

bg***@yahoo.com wrote:

Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

http://docs.python.org/lib/built-in-funcs.html

Look for isinstance.

Diez

[Christian Heimes]

bg***@yahoo.com wrote:

Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

class Example(object):
pass

class AnotherExample(Example):
pass

>>issubclass(Example, object)

True

>>issubclass(AnotherExample, object)

True

>>issubclass(AnotherExample, Example)

True

>>issubclass(Example, AnotherExample)

False

And finally

>>isinstance(Example, type)

True

This is true because type is the metaclass of object. Though you don't
have to understand it. ;)
Christian

[Bruno Desthuilliers]

bg***@yahoo.com a écrit :

Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

You have the answer, thanks to Diez and Christian. Now unless you have a
*very* compelling reason to check the type of an object, *just forget
about it*. 9 times out of 10, this is fighting against the language's
type system (hint: google for "duck typing").

[paul]

Bruno Desthuilliers schrieb:

bg***@yahoo.com a écrit :

>Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

You have the answer, thanks to Diez and Christian. Now unless you have a
*very* compelling reason to check the type of an object, *just forget
about it*. 9 times out of 10, this is fighting against the language's
type system (hint: google for "duck typing").

So I have to give up the concept that argument types are part of the
interface or signature? Honestly, I don't like that. Granted; not having
strict type checking makes for great flexibility but the price is you
either write typchecking code or let the error propagate into the
function or method. I hope type annotations in py3k will allow for
something like constraints in C# where you can tell the caller right
away she's doing something wrong.

greetings
Paul

BTW: are type annotations to be backported to 2.x?

[Diez B. Roggisch]

paul schrieb:

Bruno Desthuilliers schrieb:

>bg***@yahoo.com a écrit :

>>Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

You have the answer, thanks to Diez and Christian. Now unless you have
a *very* compelling reason to check the type of an object, *just
forget about it*. 9 times out of 10, this is fighting against the
language's type system (hint: google for "duck typing").

So I have to give up the concept that argument types are part of the
interface or signature? Honestly, I don't like that. Granted; not having
strict type checking makes for great flexibility but the price is you
either write typchecking code or let the error propagate into the
function or method. I hope type annotations in py3k will allow for
something like constraints in C# where you can tell the caller right
away she's doing something wrong.

This is a dead horse beaten into the ground, full way through to china.
If you want typechecking - use a statically checked language. After all,
if you like to constrain yourself to certain types - why not benefit
from a compiler then?

I for once prefer to be able to pass object that behaves like e.g. a
file - think StringIO - to something taking a file, instead of
introducing a interface-maze like the java.io-hierarchy to capture each
possible thinkable aspect of file IO in a separate interface - and then
hoping that the third party library was careful enough to only require
what is really needed.

Diez

[Bruno Desthuilliers]

paul a écrit :

Bruno Desthuilliers schrieb:

>bg***@yahoo.com a écrit :

>>Hi,

Is it possible to find out if an object is of a certain type or of a
type derived from this type?

You have the answer, thanks to Diez and Christian. Now unless you have
a *very* compelling reason to check the type of an object, *just
forget about it*. 9 times out of 10, this is fighting against the
language's type system (hint: google for "duck typing").

So I have to give up the concept that argument types are part of the
interface or signature?

Nope - you have to give up the notion of type you learned from
statically typed languages, and get used to the one used in dynamically
typed languages. Same word, different concept, really.

Honestly, I don't like that. Granted; not having
strict type checking makes for great flexibility but the price is you
either write typchecking code or let the error propagate into the
function or method.

Just tell me: what will happens if, *in Python*, you "write typechecking
code" ? Surely, when you'll (possibly wrongly[1]) conclude you don't
have the "correct" type (meaning: the one you expected when writing your
code[1]), you'll raise an exception, won't you ? (I can't imagine what
else...). So ask yourself: in which way will the final result be
different from would very probably happens without the "typecheking
code" ? In *both* cases, you end up with a runtime exception.

Granted, without "typechecking", there can be a couple corner cases
where you end up with incorrect results instead of an exception (like
your user passed a string where you expected a sequence which is *not* a
string). These corner cases might be worth the most minimal possible
check. As far as I'm concerned, I've run into this kind of corner case
perhaps half a dozen time in 7+ years. And usually because I (as a user
of someone else's code) failed to read the doc - which is my
responsability, the author's.
[1] dynamic typing means that two totally unrelated types may both
implement the expected (implied) interface. You just can't hope to know
by advance the exhaustive list of classes that will implement the
interface your code expects.

I hope type annotations in py3k will allow for
something like constraints in C# where you can tell the caller right
away she's doing something wrong.

Lord have mercy. As Diez mentions, if you want static type checking,
then don't use a dynamically typed language. But trying to fight against
the language is not going to buy you much.

[Hrvoje Niksic]

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.com >
writes:

So ask yourself: in which way will the final result be different
from would very probably happens without the "typecheking code" ? In
*both* cases, you end up with a runtime exception.

The idea behind such type checks is to make sure type errors are
caught as early as possible. Exceptions caught later, the philosophy
goes, are harder to debug because by then the cause of the problem can
be obscured. Consider an object of the wrong type passed to a method:
the method can store the object in its own instance attribute, and
keep working on something else. Then, much later, the faulty object
gets actually used and the error is raised. By the time the exception
is thrown, you have no idea where the offending object came from.

Personally, I consider the loss in flexibility to outweigh any
benefits of overeager type checks. Besides, type checks are only one
of the many possible constraints you could check in your objects, yet
proponents of type checks tend to treat them as somehow much more
important or fundamental.

Hopefully Python 3's support for abstract base classes will provide a
standard way to have our cake and eat it by allowing declarative
subtypes. That way type checks will be possible to prevent accidents,
but without compromising flexibility. Pure "duck typing" will be made
a bit more verbose, but not impossibly so.

[Bruno Desthuilliers]

Hrvoje Niksic a écrit :

Bruno Desthuilliers <br********************@wtf.websiteburo.oops.com >
writes:

>>So ask yourself: in which way will the final result be different
from would very probably happens without the "typecheking code" ? In
*both* cases, you end up with a runtime exception.

The idea behind such type checks is to make sure type errors are
caught as early as possible. Exceptions caught later, the philosophy
goes, are harder to debug because by then the cause of the problem can
be obscured. Consider an object of the wrong type passed to a method:
the method can store the object in its own instance attribute, and
keep working on something else. Then, much later, the faulty object
gets actually used and the error is raised. By the time the exception
is thrown, you have no idea where the offending object came from.

That's the theory, yes. In practice, when such a situation occurs, it's
usually easy to track down the problem: just add a temporary check in
the method (or around it - using a decorator), rerun the program and
you'll be done. Once the faulty code is corrected, remove the check.

[paul]

Chris Mellon schrieb:

On Dec 6, 2007 5:52 AM, paul <pa**@subsignal.orgwrote:

>function or method. I hope type annotations in py3k will allow for
something like constraints in C# where you can tell the caller right
away she's doing something wrong.

[language rant snipped]

On a more pragmatic basis, there are only 2 kinds of type errors in Python:
1: The object passed doesn't implement the correct interface, and will
raise an error when called. This will be caught by a unit test.
2: The object passed implements something that looks like the right
interface, but implements it incorrectly. This will be caught by a
unit tests.

So if I use your code I need to read all of it to understand how "file
like" something for bla(filelike) needs to be to be able to write
unittests? Or do your unittests magically detect all possible callers
and send them email with nice warnings?

>
Note that both these errors will be caught by behavior exercising unit
tests and do not rely on any sort of "typechecking code" to be
written. Explicit typechecking in Python is done only when you need to
dispatch on type, not because you feel like generating spurious
errors.

Do you prefer situations like Hrvoje has descibed two post below?

To reiterate: I'd like to have a TypeError: "foo called with <str>,
<Pointexpected" which is concise and informative for the caller,
rather than have him hunt down obscure errors in totally unrelated code
like AttributeError: 'str' object has no attribute 'move'.

greetings
Paul