Constant generalization

[chrysn]

Possible solution for #175, see there for the moment.

[chrysn]

One aspect that'll need addressing is whether properties derived from ACK_TIMEOUT should be recalculated. It'd make sense, but as long as I'm using the class itself as a value, I can't do that just with @propertys.

[Jc2k]

@roysjosh have you had a chance to look at this?

@chrysn from my pov, we can work with this. The only thing is we'd have have to have a TransportTuning instance rather than using the class (there is no hard coded ACK_TIMEOUT for us because the sleep interval is a runtime setting from the device, so we'd have to have a TransportTuning per connection). But because aiocoap isn't using mypy that shouldn't matter to aiocaop. If you are planning on adding typing I guess that could bite us down the line.

[chrysn]

Yeah, it's probably more consistent to use instances all the way. Maybe even instantiate once per message by default; that way, a user setting it per message won't cause spooky action at global scope.

[roysjosh]

I agree that this is a usable solution for the problem at hand. I'm not half the python programmer @Jc2k is so I'll just smile and nod at the second paragraph :)

[Jc2k]

I have put together a PoC of this in HA HomeKit, but haven't had time to flesh it out yet. I'm still happy with your approach @chrysn.

[chrysn]

I'm merging this with a few new changes (as announced: Using properties, instanciating it for every message).

There is a slight incompatibility in the change as the now deprecated globals are not available through wildcard imports any more, but these are sufficiently frowned upon in libraries anyway that I doubt you'd run into any trouble (and besides, it's not like there's any good reason to access them from the outside).

I expect to have a release with those in rather soon, but there are several fixes I'm spooling up for this, so not Right Now.

[chrysn]

Release 0.4.7 is out and contains these changes.