Verifiably better, validated Enum for Python

[Steve D'Aprano]

On Sat, 27 May 2017 02:20 pm, Chris Angelico wrote:

> On Sat, May 27, 2017 at 12:59 PM, Steve D'Aprano
> <steve+python at pearwood.info> wrote:
>>> What is a standards-compliant Python interpreter allowed to do?
>>
>> There's no such thing, so your question is moot.
>>
>> There is no Python standard. There's only:
>>
>> - do what CPython does;
>>
>> - do what the documentation says;
>>
>> - if they disagree, or don't say, ask Guido;
>>
>> - if he doesn't answer, or doesn't care, do what you like.
>>
> 
> Really?

Yes.

> Then how come other Python implementations can be deemed to be 
> "correct" or "incorrect"? 

Do they do what CPython does? Then they're either "correct", or "bug for bug
compatible" with CPython.

Do they do what the documentation says? Then they're either "correct",
or "documented, but incorrect".

Does the documentation not cover some specific behaviour? Then the
documentation is incomplete, and the implementation is in limbo, where
nobody (except Guido) can tell if they are correct, buggy, or "not Python".

(But we can guess, using our experience of Python, and attempt to channel
Guido.)

Is there a conflict between the docs and CPython? Then we have a problem,
and somebody has to ask 

"Is the reference implementation buggy, or the documentation wrong?"

Or possibly both.



> There *is* a Python standard, even if it's a bit ad-hoc and informal. 

A "bit"? Well, if 100% counts as "a bit", then I suppose so.

There is no Python standard blessed by a standards organisation. There isn't
even an internal PSF-only standard.

What we do have is a reference implementation, CPython, but reference
implementations can be wrong or buggy. We have documentation, but that can
be wrong, or incomplete, or it can contradict the reference implementation,
or it can be ambiguous or unclear. We can have Guido's intuition for what's
Python and what isn't, but that's subjective, not written down anywhere,
and even Guido can be persuaded to change his mind. None of these things
are an objective final source of truth for what is Python.

A standard, on the other hand, is intended as a final source of truth. It
should be 100% complete, 100% correct, and objective. (That can include
saying "under these circumstances, you can do whatever you like".) In order
to get to that state (or at least as close to it as any document written by
a committee of Homo sapiens can get), the standard is written in a formal,
precise language with no ambiguity. Sometimes (often) that means the
standard is complicated, complex, hard to read, harder to understand.

But at least it is complete, objective, and correct, and a sufficiently
smart implementer can simply, mechanically, work through the standard
implementing each feature needed, in order to guarantee a
standards-compliant (and therefore "correct") implementation. Modulo any
bugs in their implementation.

It is correct *by definition*. Standards have no bugs. They can be
incomplete or ambiguous, but they do not contain bugs (apart from obvious
typos). Once the standards committee has agreed that (let's say) your
language must treat 4 as a prime number, then in order to be correct, you
must treat 4 as a prime number.

(At least until the committee meets and passes an errata correcting that
error.)

Python has nothing like that. What we have is a collection of ad hoc and
subjective heuristics. If you want to call that a de facto standard, I'm
okay with that, so long as we're aware of the significant gap between a de
facto standard and an actual, formal standard from a standards
organisation.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.