Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor sender module #140

Closed
felix-hilden opened this issue Feb 2, 2020 · 1 comment
Closed

Refactor sender module #140

felix-hilden opened this issue Feb 2, 2020 · 1 comment
Assignees
Labels
change Change behaviour of an existing component style Refactoring, style or architectural improvement
Milestone

Comments

@felix-hilden
Copy link
Owner

From #131. We can't refactor the sender module yet, but I have an idea for an improvement. It would break setting defaults though. We could divide the module into submodules like this:

  • sender.base: Sender, Async/Sync Sender
  • sender.concrete: Transient, Persistent and Singleton sync/async senders
  • sender.extend: Retrying / other extensions that we come up with
  • sender.default: kwargs / sender instance / sender type

This would actually improve setting defaults. Instead of two imports, we could do one:

# Old
from tekore import sender
from tekore.sender import PersistentSender

sender.default_sender_type = PersistentSender

# New
from tekore.sender import default, PersistentSender

default.sender_type = PersistentSender
default.requests_kwargs = {}

I realise the old example could be done with one import, but it would lead to longer names. And now there is no problem importing defaults in other sender submodules. The client base class could also be in e.g. sender.client or base.

@felix-hilden felix-hilden added style Refactoring, style or architectural improvement change Change behaviour of an existing component labels Feb 2, 2020
@felix-hilden felix-hilden added this to the v2.0.0 milestone Feb 2, 2020
@felix-hilden felix-hilden self-assigned this Feb 2, 2020
@felix-hilden
Copy link
Owner Author

With the changes in 2.0 this change won't matter to the users, but let's still do it for the refactoring's sake.

@felix-hilden felix-hilden mentioned this issue May 7, 2020
11 tasks
felix-hilden added a commit that referenced this issue May 7, 2020
felix-hilden added a commit that referenced this issue May 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change Change behaviour of an existing component style Refactoring, style or architectural improvement
Projects
None yet
Development

No branches or pull requests

1 participant