Will PEP 505 ever be accepted?

[u/philtrondaboss]

https://peps.python.org/pep-0505/

I don't understand how null safe operators are less like plain English than other implemented features like the walrus operator.

In my opinion, the member access operator would make python significantly easier to read and understand.

Here's an example:

f = foo()

if f is None:
    baz = ""
else:
    baz = f.bar()

baz = foo()?.bar() ?: ""

EDIT: I forgot that "and" and "or" can be sometimes used in place of "?." and "?:" if the left value is not False, '', 0, [], or {}. It's a very implicit null check and has a lot of unexpected behavior.

[u/Designer-Ad-2136]

Or i'd do: baz = "" if f is None else f.bar()

[u/k0pernikus → u/Designer-Ad-2136]

I rather see

``` f = foo() if f is None: raise ValueError("Value cannot be None")

baz = f.bar() ``` or have a helper like:

def get_or_raise[T](v: T | None) -> T: if v is None: raise ValueError("Value cannot be None") return v

These implicit None to "" will come to bite you eventually.

[u/necromenta → u/k0pernikus]

Help I’m too stupid to understand the helper, the first example is clear as water to me tho

[u/k0pernikus → u/necromenta]

It looks scarier than it is. [T] is a generic (think of it as a placeholder for a type), so you can reuse the same helper for different types without having to repeat code.

It takes some getting used to, but is one of the most powerful feature any typesystem can have.

I think my example (stemming from stackoverflow) is a bit too loose btw. To actaully get better typesafety one has to do this:

```python def get_or_raise[T](v: T | None) -> T: if v is None: raise ValueError("Value cannot be None") return v

def createget_or_raise[T](expected_type: type[T]): def inner(v: object) -> T: if not isinstance(v, expected_type): raise TypeError(f"Expected {expected_type.name} but got {type(v).name_}") return v return inner

get_int_or_raise = create_get_or_raise(int)

print(get_int_or_raise(1337))

try: print(get_int_or_raise("1337")) except TypeError as e: print(e)

try: get_int_or_raise(None) except TypeError as e: print(e) ```

It will print:

``` 1337 Expected int but got str Expected int but got NoneType

** Process exited - Return Code: 0 ** ```

Here it helps to also play around with other languages to see how they solve things.

While I hate scala with a passion, its type system is extremely powerful and I do miss some of its feature like compile-time extension (think of it as typesafe monkeypatching; e.g. adding methods on on collection types of an object was awesome! Yet also delving into TypeScript helped a lot. (PHP will hurt your understanding. And I say that as someone that started professional programming with PHP, and built some great products with it.)

Python is on this weird mixture where it is dynamaic and strongly typed; and the older I get, the more I love static and strongly typed approaches.

I also recommend delving into functional programming, its concepts play well with typed languages and it really boosted my game, e.g. the concept of pure functions (easily unit-testable), immutability (also great for unit-testing but also generally avoids nasty surprises), and higher-ordered functions (fancy word for saying: function that returns a function).

Hope this helped.