[lug] Running a mixed Python environment
Rob Nagler
nagler at bivio.biz
Thu Sep 17 13:50:49 MDT 2020
On Wed, Sep 16, 2020 at 7:25 PM Davide Del Vento wrote:
> FWIW, as a Physicist I can't avoid calculating how much time is saved
going 30 or 35 vs going 20 or 25. It's mere seconds for any reasonably
sized 'hood. On the other hand, the energy involved in an impact goes with
the square of the speed, so the potential damage in an impact is easily
twice or three times as much (assuming the reaction time, become faster
with speed, which it doesn't so it's even worse). Hence, it's tunnel vision
plus ignorance that cause this problem.
Someone once recommended (and I wholeheartedly agree) that we should switch
to momentum violations or kinetic energy violations instead of just speed.
The scale should be progressive (geometric?) to compensate for reaction
time being constant.
> Yegge agrees it is difficult (or at least tedious and expensive), so it's
not just me and the teams I worked with that are incompetent
I think one thing I've learned over the years is that programming is
tedious, and that it pays to be patient, read the code (if available) and
not just the documentation.
Consider the bug I fixed yesterday
<https://github.com/radiasoft/sirepo/issues/2943> due to a patch version
upgrade to a pip package (Authlib==0.14.1 worked and 0.14.3 didn't). I
could have tried to figure out a way to get Authlib's Flask integration to
work with our custom cookies, but instead I figured out how to write the
integration, completely eliminating Flask's sessions (which are another
mess), in less code. It did take hours, but the fact is that we use to use
oauthlib, which was deprecated in favor of Authlib (same author), and I
didn't spend the time at the time of the upgrade to figure things out
properly. It cost as much time then (to do the oauthlib to Authlib upgrade)
as it did to do it properly (decoupling from Flask) with less code and a
clearer execution path.
The bug with Authlib was typical: it wasn't checking the state returned on
OAuth2 replies if you didn't set the session value so if you didn't set a
secret_key in flask, you could be subject to cross-site script attacks on
OAuth2. The interesting part was that we noticed that there was no check
and were doing the state checks ourselves so there was no bug in the
end-to-end implementation until the bug fix was implemented in Authlib.
Another interesting part (to me :) is that the patch release completely
broke OAuth logins. The change in behavior was breaking. Therefore, one
could argue it should have been a major release. However, it was such a
small change that it was combined with other changes and buried. There was
no real description of the fix in Authlib and didn't make it into the
release notes. That's why romantic versioning is the right name for it.
Finally, for those with a lot of time on their hands and who care about
Authlib, chase down the above bug fix, and you'll learn how to bypass much
of the unnecessary abstractions in Authlib (registry, WAT?) to implement an
Authlib "integration" in a few lines of code without breaking public
promises. This will pay for itself when you, say, want to migrate away from
Flask to, say, Tornado.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20200917/c2d6480d/attachment.html>
More information about the LUG
mailing list