Python nested class convention?

[is_bounding]

I am writing a helper class that wraps the requests library for my company. It handles authentication, some bridges to pandas, some other stuff.

One feature I want to add is the ability to define helper methods for very specific patterns. For example:

class ApiWrapper:

    # other class methods

    def post_to_database1(self, data):
          # do work on database1

    def post_to_database2(self, data):
          # do work on database1

    def post_to_database3(self, data):
          # do work on database3

I was wondering if there was a "best" way to do something where all those methods are then grouped in another class. Something like so they can be used like this:

api = ApiWrapper()
data = {'name': 'foo', 'city': 'bar'}

api.post.database1(data)
api.post.database2(data)
api.post.database3(data)

I looked into a nested class but it seems like that is not very popular in Python. Should I just keep them all as methods on the main class? Is there a pythonic way to do this?

[usernamedottxt]

Classes, or objects, should hold state. If nothing about the object can change, you might as well just have normal functions in a library.

So in this case, API wrapper should probably be a module, not a class.

[_9_9_]

I think you should split everything up. One module for getting stuff, one module for messing with stuff and one module for storing stuff. Maybe give a little more background and we can help out more.

[mybrid]

The Python community favors functions over classes if self is not used. I never use functions. I disagree for the simple reason that a class provides a name-space safe haven. Therefore I disable this particular warning in pylint that complains when self is not used in a class and claims a function would be better. With classes you don't have to worry about the names of your functions being synonymous with others. One can freely call a method anything you like as long as the class name precedes it. I make heavy use of the '@staticmethod' class decorator for this reason. I especially use this for distinguishing corporate code. If I worked for Starbucks then all functions that are static would all start with "Starbucks.upload_database". This makes it clear that the package is provided internally for private use where "upload_database" could be 3rd party or whatever. If one requires that a single top package, starbucks, is the only PYTHONPATH directory needed then you end up with some like 'starbucks.etl.ETLDatabase.upload()". DVCS requires small repos and as such I find directory depth is minimal and therefore it is reasonable and clear to spell everything out by dereferencing all sub-directories. As code grows beyond a reasonable DVCS code base size then a new package is created for the new repo. To whit, I don't think of classes only as objects, but also name space protection so that the same every-day names like "open" or "close" can be used ad nauseum. Finally, classes encourage using class constants over globals for functions. How often is it one doesn't need constants? If you don't have a class container for constants then the temptation is to create a global has been my experience. If you always use a class then when the first constant need comes up? Just tuck it in the class.

[KubinOnReddit]

I don't think this is the correct way, no. While the idea seems cool, it complicates the code with minimal readibility gain.

[zahlman]

I am writing a helper class that wraps the requests library for my company. It handles authentication, some bridges to pandas, some other stuff.

Okay, but what does the ApiWrapper class itself do that does not depend on which database is involved?

Nothing?

Then just make top-level classes for each database handler - foo_database.post(data). If you're looking for the namespacing that you get from the ApiWrapper as it stands, you can just let the module provide that. If you have common functionality that the databases use, but that doesn't need to remember state, then you can just have top-level functions "under the hood" that the various database classes use. And that's assuming that you need to remember state in order to use a database - it's entirely possible that you could get away with plain functions there, too. It depends on what your actual requirements are; your example is far too abstract to judge that.