PEP: Is initializing typed variable with None bad practice? (lemmy.world)

submitted 2 days ago by AstroLightz@lemmy.world to c/python@programming.dev

20 comments fedilink hide all child comments

For example:

class FooBar:
    def __init__(self):
        self.a: int = None
        self.foo: str = None

Is this bad practice/go against PEP guidelines or is it fine?

you are viewing a single comment's thread
view the rest of the comments

[-] logging_strict@programming.dev 1 points 11 hours ago* (last edited 11 hours ago)

kudos for pointing that out. Another reason to dump Optional.

Union[None] is not ambiguous

As coders we have the potential to have lots of coder friends. Union[None] is just the sad reality.

Optional[None] is sorta keeping our hopes up like there is some distant future where the situation improves. Where all these coder fiends come over every night of the week to bitch about static typing issues and running out of beer and pizza. And when that one guy has to bring up politics; everyone will react like he just let out a massive fart in the room, poisoning the air. Suddenly can feel the IQ in the room dramatically drop. Everyone reacts predicatively, spontaneously, and synchronously in disgust; thinking, dude what a tard! And someone will say, lets do this again tomorrow.

Fck yeah! This is the place where i want to live.

[-] solrize@lemmy.ml 1 points 10 hours ago

Not sure what you're getting at about Union but it's not an option type either. Option means a value might be present or absent. Like maybe there's a database column that holds an int, but that column is nullable so it has type Optional[int]. Now you might want to read a row from the db and get that column from it, but that row itself might be absent. That is, the value you return has type Optional[Optional[int]]. But if you get back None, does that mean the row was present and the column was nulled, or that the row was absent?

With a genuine option type you'd return something like Just None (Haskell notation) for the case where the row is present and the column is nulled. C++, Rust, ML, and so on all have versions of this that work. Python's version is sadly broken.

[-] logging_strict@programming.dev 1 points 10 hours ago

You are describing Sentinel. Recommend using attrs.NOTHING. Unfortunately, the static typing, NothingType, is in private API. Until the Python community can settle on the one Sentinel to rule them all, will stick with attrs cuz it's usually already a dependency.

You can come by my place anytime for beers and pizza. Bitching about static typing should be an Olympic sport. Or at least involve beer.

[-] solrize@lemmy.ml 1 points 8 hours ago

You might like: https://curtispoe.org/articles/what-to-know-before-debating-type-systems.html

I remember looking at attrs but not getting around to using it. These days I use dataclasses. I don't worry about this stuff too much in Python. I just notice some issues and smile. Haskell does a lot more to focus the mind, when it comes to types.

[-] logging_strict@programming.dev 1 points 6 hours ago

Thanks for the article link. Worried code too much and don't study enough.

Appreciate the reading material.

[-] logging_strict@programming.dev 1 points 7 hours ago

i'm in love with typing_extensions. Know why? I'm not on the latest greatest Python version. But want to use the usable latest features. As package author/maintainer, upgrading to the latest and greatest is not a viable option.

in py39, dataclasses lacked critical features that came out later. Especially for a fundamental structure like a dataclass, new features requiring a Python upgrade is a show stopper. On the level of a flaw. Either backport or in a separate package or i don't want to touch it. That's why use attrs and not dataclasses.dataclass

And so should we all.

There is always going to be some great features we want to use and then not being able to is not great UX. Every package that matters really must be external, except for Python features like free threading, sub-interpretors, etc.

There are always many coding languages, unfortunately jumping from one to the next is a pipe dream. So really doesn't matter what Haskell can do. Or how Rust devs all have 10 gfs.