> pytype (Google) [1], PyAnnotate (Dropbox) [2], and MonkeyType (Instagram) [3] all do dynamic / runtime PEP-484 type annotation type inference [4] to generate type annotations.
Hypothesis generates tests from type annotations; and icontract and pycontracts do runtime type checking.
If login/Single Sign On is what you are after you are arguably better off with Central Authentication Service (CAS). It is much simpler. Unfortunately it isn't as widely known or popular.
Yep, this is why I say that oidc is vastly misused. There are much better options out there for implementing good solid, login, session flows. Using oidc as the only tool in the toolbox is a recipe for disaster.
Because the CAS protocol is deprecated? It's arguable simpler and easier to deal with and works really well, but not that well supported and that isn't likely do improve at the protocol won't evolve any future.
We're currently in the process of migrating from CAS to OIDC and so far the server side hasn't been much of an issue, but compared to CAS the clients are a little hit and miss. Authentication always works, but claims are annoying.
Speaking of sci-fi, project orion/nuclear propulsion is also featured in Marko Kloos' Frontlines series (though not in the first book if I remember correctly)
> I once heard a professor talk about writing a book 30 or so years ago. He looked at all the available options and decided latex wasn't perfect, but was the best available. 20 years later he decided to look at everything again and was appalled that latex was still the best option he had.
Many many years ago I evaluated the available options as well to write internal documentation for the company I worked for. Looked at groff with the mom macro package. But eventually settled on Lout.
Lout worked very pleasantly (it has a nice markup language) but the output didn't look as beautiful as Latex. Unfortunately it doesn't seemed to be developed anymore.
Lout was the inspiration for LILArt (see http://runtimeterror.com/rep/lilart) which has a @-based syntax. The idea is that you define a document in a tree-like format with nodes, properties and such (similar to XML but not as verbose) and then you pass it to a LIL (a scripting language similar to Tcl) script to... do stuff with the nodes. You call lilart like "lilart -f<format> file.ladoc" where <format> simply makes lilart to load the "<format>.lil" script and call its "process-tree" function, passing in the root node.
The reason i made it was that i liked Lout's syntax but i wanted something closer to DocBook that i could convert to other formats (Lout only works with printed output). I think the closest is GNU Texinfo, but even that was too specific and it needs way more handholding for the underlying output than i'd like. Texinfo defines its node types (and its format isn't really a tree nor very generic) whereas LILArt's node types are just a convention and in practice the scripts can define any sort of node.
Having said that, LILArt is really a backburner project which i only touch wherever i need to write a document in more than one format. The default LILArt scripts can output groff macros for conversion to PS and PDF (i used that because it is already installed in many systems, including the iMac i used at the time, and it is small to download for where it isn't available) and HTML in several variations, like semantic HTML, "simple" HTML for systems like Java help and LHelp, HTML for conversion to mobi and plain text and "naked" HTML for use with QuHelp (a program that i wrote some years ago to convert naked HTML files to full web-based help sites with search). I also had a Texinfo target that could be used to make info files, PDF and PS through TeX and CHM files for a while but it was buggy and decided to rewrite it at some point.
However i only touch that rarely when i need it so i don't really recommend its use as it is right now (the processor is more or less done, but the scripts aren't very well thought out since i was doing stuff as i needed them and they need a bit of a cleanup and some nodes are needlessly verbose - the DocBook inspiration - and need some abbreviation aliases).
"Scribble is a collection of tools for creating prose documents—papers, books, library documentation, etc.—in HTML or PDF (via Latex) form. More generally, Scribble helps you write programs that are rich in textual content, whether the content is prose to be typeset or any other form of text to be generated programmatically."
You type in text and mark up using @-tags that are defined in, and can also contain, the full Racket language. It's like LaTeX with a modern language (but without the tons of available packages).
Nowadays Sphinx is quite usable for writing both long-form documentation and reference docs.
It's a really complex piece of software (much more complex than everyone thinks at first), but most of the time that isn't noticeable. The rST syntax can be somewhat confusing with advanced constructs, but for most stuff a short primer gets everyone going in the right direction. Since it's Python, deployment is a little bit annoying on non-Linux machines, but for docs you want CI anyway. To tweak PDF (i.e. latex) output it requires a fair bit of knowledge of both Sphinx and latex (and possibly rST [0]).
Like I said... it's quite usable.
[0] rST again being much more complex than everyone thinks at first. It's an enterprise markup language.
