#🔒 Any way to cut down on this boilerplate?
waxen bramble
night belfryBOT
https://www.reddit.com/r/learnpython/comments/1geb62k/any_way_to_cut_down_on_thi...
@waxen bramble
Python help channel opened
waxen bramble
people seem to really hate this, but it's working pretty well for me
was genuinely interested in if there was a better way to do this
I saw importlib could help, but i didn't want to add another dependency at the time
now that things are working, i can revisit some of this structure
dense stirrup
It does seem like quite the odd way of doing this. Would merging the files together into a single one work better? What do you want to achieve with this structure?
waxen bramble
the file would be huge
if that's the way it's generally done in python, that's fine, but a 1000+ line file would be very difficult to maintain
dense stirrup
The entire file-per-method thing is probably okay given that this looks like a typical HTTP API. What is probably being objected here is the way you're importing them in the main file:
from .teams import _get_all_teams
def get_all_teams(self):
return self._get_all_teams()
from .users import _update_user_by_id
def update_user_by_id(self, user_id):
return self._update_user_by_id(user_id)
It is clear from the _ at the start that these are meant to be private methods not meant to be used externally. So there should be no issue with putting them at the top.
waxen bramble
but the name conflicts
celest gust
https://www.reddit.com/r/learnpython/comments/1geb62k/any_way_to_cut_down_on_thi...
The main thing I would say is to not use relative imports if you can, since that makes everything a pain if you ever want to run an individual file. Besides that, while this is a bit more segmented than I normally do, I have no problems with splitting class internals into different files.
dense stirrup
The entire file-per-method thing is probably okay given that this looks like a t...
If the import would cause a performance detriment (maybe it depends on a huge library or something), perhaps putting it inside the function would work:
def update_user_by_id(self, user_id):
from .users import _update_user_by_id
return _update_user_by_id(user_id)
i'm not overly concerned with performance, i can address that if/when it becomes a problem
dense stirrup
but the name conflicts
I'm assuming that get_all_teams is inside the MyClient class. If that's the case, it should not conflict with the other import.
waxen bramble
hm, i'll have to take a closer look at that
celest gust
This also might be a confusion of intent due to the naming. Normally, if an anything is prefixed by an underscore _something, that means it is an internal, and not supposed to be used elsewhere. This also includes elsewhere in your code, so anything with an underscore prefix in say users should only be used in users.
waxen bramble
yeah that makes sense
oh, i can just:
from .alerts import update_alerts_as_read
and nix the:
def update_alerts_as_read(self, alert_ids):
return self.update_alerts_as_read(alert_ids)
entirely i think
would that still pass self as the first parameter?
hasty yoke
it would if you import it inside your class definition
waxen bramble
i wouldn't have to additionally do something like:
from somewhere import bar
self.bar = bar
I'm never sure of something I'm about to say so I tested it and this seems to be the behaviour that you're looking for
hasty yoke
yeah you wouldn't have to do the self.bar stuff unless you wanted to assign the methods in the object's __init__ function (plus we don't have a sense of 'self' in the scope that I'm importing some_method)
