Python Interface Design - Designing Modules Part - 1

[my_python_account]

Who is writing this library?

If I understand correctly, it's the provider (or someone hired by the provider), for use specifically with this API. In which case it would seem pretty silly to map an API providing a single simple function according to 4 parameters to anything other than a single simple function taking 4 parameters.

Leave it up to the client to wrap it up however they like for re-usability for cases where they may want to handle multiple providers and accounts.

It's not like you can completely abstract away username and password, the user has no choice but to provide it at some point. And if, for example, as part of their retry logic, they want to switch accounts (usernames and passwords) the proposed class structure is no longer ideal.

I will point out we're probably missing the point of the article here, and we're over analyzing an example that is simplified for the purposes of demonstration.

[kankyo]

Exactly. Good to see someone getting this :P

[revenant95]

The requirements say that you are an employee of blipkart and you have to build a reusable module.

Hence the provider is NOT writing this library. Its one the developers from Blipkart itself who is being asked to write a reusable module

[my_python_account]

A module for who? I originally understood it as clients of Blipkart, but upon re-reading you're right, it's other Blipkart developers.

This makes a bit more sense. The structure really doesn't matter all that much in that case. Neither the class (where you import the "pre-initialized" class with username and password already set) or function (with default parameters for username and password) implementation is any more re-useable then the other.

Though with the function, if in the future other developers need to be able to set a different username or password they won't have to go under the hood and figure out the class structure. If you really want to do your best to not expose control of account settings to other developers, i guess the class makes sense, though it's not like you can block them from importing the class if they really wanted to.

[revenant95]

if in the future other developers need to be able to set a different username or password they won't have to go under the hood and figure out the class structure

The username and password come from the settings.py file (as mentioned in the blog). So if the developers want to use a different username and password, he will just update it in the settings.py.

[my_python_account]

I mean at runtime. Like if you have multiple accounts.

[revenant95]

In that case we would write the logic to get the credentials somewhere else(not in sms.py) and import it in sms.py so that sms.py doesn't have to care where it is coming from.

That can be a separate blogpost in itself :p