1

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):
        super.__init__()

or

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.

Community
  • 1
Patrick Collins
  • 2,195

2 Answers2

3

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.

Karl Bielefeldt
  • 148,830
1

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.

Roman Susi
  • 1,803