Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
> Weirdly, when I'm evaluating open source libraries having their own domain name rather than a site on GitHub pages or ReadTheDocs is a very slight mark against them in my book - because of exactly this.
> If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come.
The requests documentation is hosted on ReadTheDocs already. Also you can generate the docs yourself:
https://github.com/psf/requests/blob/main/docs/Makefile#L25
I find your focus on the domain kind of odd to be honest. I'm not really sure why it's so important.
Weirdly, when I'm evaluating open source libraries having their own domain name rather than a site on GitHub pages or ReadTheDocs is a very slight mark against them in my book - because of exactly this.
If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come. If it's a relatively concise library I would much rather it use a trustworthy service to host its documentation as opposed to some custom domain that's likely to expire and break links in the future.
(My own open source projects now mostly hang off my https://datasette.io/ domain, but I was a few years into that project before I committed to a domain name that I plan to renew for the rest of my life.)
So this is interesting to me in the context of having just realised a Python framework (http://www.tetraframework.com) and choosing to self host the docs.
It's something that I put a lot of thought into, but I decided to go that route for two reasons:
- I want to be able to embed into the docs working examples, as you often see in JavaScript front end framework docs. I could have done this by just embedding a Glitch for each example but I also intend the whole docs site to be a good example of how to build with the framework (once I flesh out routing). 15 years ago when I first found Django, it's site was the perfect reference to look at too see how to use Django in a larger context.
- There is also a marketing aspect to it, I was to present Tetra as something significant. Show how much thought and work is going into it.
However you comment (and the situation with Requests) has been a nudge, I will be sure to mirror Tetras docs on to a docs hosting site too.
- PEP 568 – Generator-sensitivity for Context Variables
(and that's as far as I cared to look - unfortunately https://peps.python.org/ lists the authors by last name and there are multiple people named "Smith")
So it seems he has in fact "done much".
> I do not recall that the author of this pamphlet has ever done much
He made the Trio library, which is ridiculously good and also ridiculously hard to implement (just look at this issue [1] for example where he carefully examines the three (!) different async APIs on Windows). Lessons from it are being folded back into the asyncio library in core Python (e.g. exception groups) everyone benefits even if they don't use Trio directly.
[1] https://github.com/python-trio/trio/issues/52