in a freshly created venv, with attrs and ipython (and deps, of course):
(attrs) % ipython
Python 2.7.14 (default, Oct 19 2017, 23:28:49)
Type "copyright", "credits" or "license" for more information.
IPython 5.6.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: import attr
In [2]: Part = attr.make_class("Part", ["part_num", "description", "quantity"])
In [3]: Part?
Init signature: Part(self, part_num, description, quantity)
Docstring: <no docstring>
Type: type
Outside of the name of the thing that creates the item, the syntax is identical to what you have here.
As a mini-followup: due to this kind of scenario, we ended up having to replace UPS battery packs in about 8 months (1/3 of their minimum intended lifecycle) due to how heavily they got load-rushed over the months.
The load cycle literally killed them in that time.
People are paying for a service, and they expect it to work.
I once (another country, another ISP) dealt with a query/complaint of "it doesn't work!" which turned out to be due to a snowstorm taking out _the entire area_. Which people knew about! And still complained!
The expectation for the service is really much of the same.
Almost ironically, the first marker that people phone about is "my email doesn't work!"
edit/addendum: your customers also have their own solutions for dealing with power outages - more UPSs, generators, laptops (with internal wimax or 3G chips), etc
By way of answering, let me recount a short story for you.
It takes place during the very first time I visited Kampala (the capital of Uganda). It was about 3 years before I had started working in the ISP/telecom space in Africa. This particular trip was soccer-specific (I was working on the team that delivered one of the big trans-national African tournaments' games on television), thus the non-ISP nature of it.
We arrive at our hotel, having driven just under an hour from Entebbe to Kampala. It's fairly pleasant, albeit a tad humid (it's mid-day and near the equator after all; 36C and >=70% humidity - not the worst). There's a group of around 30 of us that now need to check in... this always takes a little while.
So, everything goes on. You loaf around the hotel reception until it's your point in the queue, grab some water now and then when you can. Finally, you're standing at the front desk, starting your process of checkin.
You read off your name... the person behind the counter finds you in the list (of fortunately mostly checked-off people - yay alphabet precedence!), and starts doing some stuff on the front desk computer. At which point you glance over to said desktop and notice the UPS jacked into the UPS jacked into the UPS (yes, three) jacked into the computer. You idly inquire about this. The response is "oh, yeah, the other ones died with all the power outages".
Not a joke, as it turns out. While you're doing your checking, the building experiences a brownout twice.
Years later, you get there for a totally different reason. Time (literal years) has passed. And during setup of some equipment (here, I'm skipping about two days' worth of time), you find that the reason your laptop screen kept dimming and your DC UPS' kept beeping.... is because you're getting such major voltage swings on the building feed that everything is going over-or-under-voltage.
This is daily life (in many parts of Africa). It isn't a thing to fight against. It just is. You take it, and try to do your utter best. You try to deliver your utter best.
And if you just push hard enough (and, imo, if you're really, really lucky) you maybe get somewhere with it!
Nothing exciting published, no. Blogging wasn't particularly big around this part of the world/specific-weird-subset-of-the-market for most of that time. Should I consider writing up some of them?
Past aside, there are many things already underway, in many areas, that you could be involved in if you wished. Do some research around areas that you find yourself interested in (both technologically, and geographically), and see where that takes you.
Read about ILECs/CLECs. Understand what the cable offerings' contention model is.
Do the math.
Understand the support burdens of NAT-on-NAT.
Run the numbers of RF contention, and shared-medium bandwidth management.
Do the math.
Probably the best advice I could give here: It's very easy to do a mediocre job of all this. It's a fair bit harder to do a good job of it. And think of how much you dislike the mediocre ISPs.
Outside of the name of the thing that creates the item, the syntax is identical to what you have here.
edit: removed triple backticks, indented with 2sp according to https://news.ycombinator.com/formatdoc rules