PEP 505: status?

I’m new here, but I did a search and wasn’t able to find anything in this forum on PEP 505 (https://www.python.org/dev/peps/pep-0505/). Is this PEP dead? or just unloved? The page says “deferred” but it doesn’t explain why.

5 Likes

PEP 505 is controversial as it’s using ? (the question mark), one of the last few printable non-alphanumeric characters from the 7-bit ASCII subset. The other example being $ (the dollar sign).

You can search archives of the python-ideas and python-dev mailing lists for previous discussion on this PEP.

1 Like

It was mostly controversial because nobody agreed on whether “None” was special or not.

The conversation didn’t make it to python-dev, but searching python-ideas for “PEP 505” should find the last round of discussion.

1 Like

Thanks all. I’ll take a look there.

I think most deferred PEPs have a small writeup in a section titled “PEP defferal” or something similar right at the top. Would it be possible to add something similar to this PEP?

2 Likes

That seems absurd to me. I was just looking for discussion about it to suggest adding a typing addition for Optional where you could have a type annotation using the None-aware syntax (e.g., def test(a: int?):).

Was there a feeling of consensus from other core devs? Were there more people in favor than not?

I am not a core dev, but I feel the community consensus is that None is not “special enough” to warrant a new syntax, but def test(a: int | None) is good enough (which is going to happen in 3.10).

Being one of four singletons builtin, it seems pretty special. That’s good to know about the new syntax, though. I like that. Null operators would still help ergonomics a lot especially as I swap between C#/Rust and Python at work these days quite a bit.

I hope this PEP is revived. I think the ergonomic and type-safety value of safe ? references justify making None special even if it isn’t currently considered to be so.

As others noted, the main semantic sticking point was that the specific is None check was seen as too limiting, but the proposals to offer a more flexible underlying protocol based approach (e.g. https://www.python.org/dev/peps/pep-0532 ) were seen as too complicated. (There was also a syntactic sticking point, which is that ??, ?., and ?[] don’t really meet anyone’s definition of “executable pseudocode”, which is a standard we aspire to for new Python syntax)

Something we didn’t seriously consider at the time, but may want to think about now is whether making the short circuiting check be for x == None rather than x is None might offer enough runtime flexibility to get past the "None is special, but it isn’t that special" objection.

While most of the arguments for withdrawing PEP 531 (https://www.python.org/dev/peps/pep-0531/#pep-withdrawal) would also applying to defining PEP 505 that way (since x == None would effectively become the “existence checking protocol” that PEP 531 suggested), it might be more palatable when it’s just adapting an existing protocol to a new purpose, rather than defining a completely new one.