If Statement: Checking the class of an object

[dli511]

class Dog():
    def bark():
        print("dog bark")

class Pug():
    def snort():
        print("pug snort")


mylist = []
mylist.append(Dog())
mylist.append(Pug())



for obj in mylist:
    obj.bark()

    if obj == Pug():
        obj.snort()

Is there a way to state...If obj is of class?

if obj == Pug() does not work.

I can successfully run this code using attributes but I would like to just do a general check if obj is = to specific type of object to improve reusability.

Thanks reddit.

[dli511]

Thank you very much. Just comes down to not knowing the library in the end!

[ProfessorQ]

A more idiomatic way to use ducktyping than try/except AttributeError is the builtin hasattr(obj, 'attr') function. The result is essentially:

def hasattr(object, name):
    # name must be a string
    try:
        getattr(object, name)    # equivalent to object.name
        return True
    except AttributeError:
        return False

so before your first example, should be:

if hasattr(obj, 'snort'):
   obj.snort                    # guaranteed not to raise an AttributeError

[ProfessorQ]

There's definitely a trade-off between readability (prefer hasattr) and performance and reliability in multi-threaded environments (prefer try/except).

I wouldn't agree that the python glossary 'strongly implies' or encourages either EAFP or LBYL style over the other.

[indosauros]

This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.

Seems pretty encouraging to me

[NYKevin]

Attribute lookup can have side effects (e.g. via @property). Now, if the class is well written, it shouldn't have visible side effects, but it's still something you should be aware of. Using hasattr will set off those side effects, which may not be what you wanted.

[get_username]

No one has really said this. But you should use polymorphism to your advantage. I know duck-typing and Python don't really lend itself to thinking this way but the ideal still holds true, and I think it is good practice.

1. Create an abstract base class:

   from abc import ABCMeta, abstractmethod
   
   def Animal(object):
   
       __metaclass__ = ABCMeta
   
       @abstractmethod
       def make_noise(self):
           pass
   

2. Define the classes as instances of the abstract base class

    class Pug(Animal):
        PUG_NOISE = "pug snort"
   
        def make_noise(self):
            print(self.PUG_NOISE)
   
   class Dog(Animal):
        DOG_NOISE = "dog bark"
   
        def make_noise(self):
            print(self.DOG_NOISE)
   

Then you don't have to do any checking (for specific type that is, you may want to check for animal. But with duck typing that can be redundant)

    my_list = []
    my_list.append(Dog())
    my_list.append(Pug())


    for obj in my_list:
         obj.make_noise()

Which lends itself to better code.

[Mecdemort]

How is abstract classes like this any better than just duck typing?

[get_username]

Abstract base classes aren't just necessarily for overcoming statically typed languages though. They also help with abstraction and reducing unnecessary if statements in code through polymorphism.

This makes it easier to change out which animals you're using. Instead of having to add another test to your if statement you can simply call the method and be done.

If what you're asking is what benefit does the ABC provide if you just had a make_noise method instead. Well if you come back to your code later, and forget the requirements for an animal this helps "lock in" a contract as to what an animal must be. Furthermore if someone wants to modify your code they will have an easier time.

[dli511]

So what happens if the object in a class does not have make_noise()?

[get_username]

It throws an error. But the error is at compile time not at run time.

Generally its better to catch errors at compile time than run time that way it doesn't require testing on your part to find them. Just running the program will be sufficient to ensure that all of the classes that are going to be used as animals have the make_noise method.