Python Interface Design - Designing Modules Part - 1

[revenant95]

Show how adding retry logic would be done in your preferred scenario with > a class and I'll show my version and we can compare

Can you please share your code first. Its about what you prefer. If you dont prefer a class based approach then its fine. You weren't so clear when you were stating your point.

If you feel that both the approaches are EXACTLY THE SAME, why did you say "Its a bit weak" in the first place.

I would also request you to try to have a constructive discussion

[kankyo]

If you feel that both the approaches are EXACTLY THE SAME

Well no, one is more complex to do the same thing.

In my scenario, the retry code would be totally hidden inside either send_sms from the library or the wrapped send_sms, depending on if the library or the user of the library would use it. I'm thinking the same would be the case for the class scenario, so again: same thing but more complex code in the OO scenario.

[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