This is related to "Extends is evil" vs. OCP? but separate because the idea of "implement the interface" doesn't exist in Python.

I'm writing a class to pull some data off a webpage. It's going to need to hold on to a cookie for authentication, so I'm going to use a requests.Session object in some form. I'm never sure how to approach this -- what's the appropriate choice here?

class FooFetcher(requests.Session):
    def __init__(self):


class FooFetcher(object):
    def __init__(self):
        self.session = requests.Session()


The former seems to end up with FooFetcher having way more public methods than it needs to. The latter looks like it might be unnecessarily convoluted, since pretty much every method of FooFetcher is going to involve a call to a method of that Session object, plus maybe some parsing of JSON that it finds.

  • Would you like to have-a wallet, or be-a wallet? If you chose have-a than the person should have-a wallet. Should your penguins have-a animal or be-a animal? ...and so on and so forth. Sep 13, 2013 at 18:58
  • 1
    Fair enough -- it just seems strange to me in the case like this one where the only thing that matters about FooFetcher is the session. If the only interaction I have with my parents is to ask them for money, it might make sense to say that they are-a wallet rather than have-a wallet, from my perspective. Sep 13, 2013 at 19:03
  • There's no reason you can't implement an interface that provides facilities from the things you have, if you have-a wallet, then perhaps the person interface should have a TakeMoney method on it. In fact many institutions presume we do all have this interface method implemented :| Sep 13, 2013 at 19:05
  • Note that in your first example, the __init__ method is entirely redundant and can be omitted entirely. Sep 13, 2013 at 19:08
  • If the only thing that matters about FooFetcher is the session, is it even really a class? You can just pass your session into a bunch of free functions, if there's no other state
    – Useless
    Sep 13, 2013 at 21:13

2 Answers 2


The trick is to look at the calling code. Is there any code that currently uses a requests.Session object that you want to be able to pass in a FooFetcher instead? If not, then use composition.


Your particular example strongly suggests HAS-A relationship, thus, composition, because FooFetcher is not a Session.

BTW, Python does have multiple inheritance, and sometimes functionality can be added using mix-ins.

For example, you may have Sessioning and add it as a mix-in:

 class FooFetcher(BaseFetcher, Sessioning):

Returning to your second example, I think, session should be explicit:

class FooFetcher(object):
    def __init__(self, session):
        self.session = session

This way it's easier to test and maintain the code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.