For example division by zero often indicates an "unexpected" error, but it wouldn't if you were implementing a spreadsheet.

So to me the approach of using different forms of error reporting for the two kinds of error doesn't seem promising: if you imagine you had to implement division yourself, which kind of error should it report? Should you have two variants of every fallible function so the caller can choose?

For Debian, that's what tag2upload is doing.

They didn't assume nobody would guess the URL.

They did take active steps to ensure the data was only available at the correct time.

But they didn't check that their access control was working, and it wasn't.

I think "perhaps the density of crashes will be tolerable" means something like "we can reasonably hope that the crashes from Fil-C's memory checks will only be of the same sort, that aren't reached when the program is used as it should be".

But that would compete with the commercial offerings of at least one of the organisations sponsoring that message. So I expect they won't do that.

I haven't yet seen a problem with running your own transformations against untrusted XML.

Maybe a new maintainer could aim to make the second case fully supported but not the first.

After the "write a new spec" plan was abandoned in 2024 the next stated plan was to turn the Reference into the spec, though they never got as far as deciding how that was going to work. That plan lasted six months before they changed direction again. The only practical effect was to add the paragraph identifiers like [destructors.scope.nesting.function-body].

They're currently arguing about whether to write something from scratch or somehow convert the FLS[1] into a spec.

[1]: https://github.com/rust-lang/fls

The team that was formed to carry out RFC3355 still exists, though it's had an almost complete turnover of membership.

They're currently engaged in repeating the process of deciding what they think a spec ought to be like, and how it might be written, from scratch, as if the discussion and decisions from 2023 had never happened.

The tracking issue for the RFC was https://github.com/rust-lang/rust/issues/113527 . You can see the last update was in 2023, at the point where it was time to start the actual "write the spec" part.

That's when it all fell apart, because most of the people involved were, and are, much more interested in having their say on the subject of what the spec should and shouldn't be like than they are in doing the work to write it.

The support for writing CGI programs in Python is in wsgiref.handlers.CGIHandler .

All that was in the cgi module was a few functions for parsing HTML form data.

Of course that's exactly what traditional Linux distributions signed up to do.

Clearly many people have decided that they're better off without the distributions' packaging work. But maybe they should be thinking about how to get the "buffering" part back, and ideally make it work better than the distributions managed to.

So I think it would be a decent quality-of-life improvement to make generators of the sort you suggest easily available, and have the tutorial docs use them from the start.

Suppose I have a function which takes four string parameters, and I have a bug which means it crashes if the third is empty.

I'd rather see this in the failure report:

("ldiuhuh!skdfh", "nd#lkgjdflkgdfg", "", "dc9ofugdl ifugidlugfoidufog")

than this:

("", "", "", "")

If I was coming to this project for the first time I think the questions I'd immediately like the answers to are:

- What language is this language server for? Is it just for SQL proper, or for PL/pgSQL, or writing C extensions, or what?

- What makes it PostgreSQL-specific? Is it just that it follows PostgreSQL's dialect of SQL?

- Does it expect to be told about your database's schema? And if so, do you tell it by giving it a database connection, or letting it see files defining the schema, or what?