3 ms·

How do you check for None?

stevesimmons 3y ago
Or check that two dicts really are the same object, as opposed to two different dict objects that just happen to have the same keys/values?
- wodenokoto 3y ago
  I'm not sure I've ever had to do that. When is that a need?
  - misnome 3y ago
    My immediate first thought is, optimisation? If you know you’ve been the same object, you could skip e.g. comparison, or change update logic
    - dist-epoch 3y ago
      This kind of micro optimizations don't make much sense in Python. They complicate the code, and you are still 100 times slower than compiled languages.
      - misnome 3y ago
        It really… doesn’t have to complicate. And I disagree that optimising python code is never necessary. Not everybody is writing 100-line one-off glue scripts. Also, you are somewhat changing the topic from “what is an example of when you might want to is-compare two dicts”, no?
thrdbndndn 3y ago
I personally do use "if var is None:", but can't you just use "if var == None"?
- nomel 3y ago
  ‘is’ checks if it the object ids are the same, with None having a unique one. Equals can be tricked. Here’s a class that is equal to None, and everything else: class EqualsEverything: def __equals__(self, other: Any) -> bool: return True
  - thrdbndndn 3y ago
    Thanks, I saw this on SO too. Just curious: would it ever happen in practice?
    - svilen_dobrev 3y ago
      every little thing happens in practice... usually unnoticed and buried while refactoring something innocent/ly. sooner or later the __eq__ method will be redefined for some class, then reworked, and then.. == None might not be what was supposed to be.. or, my favorite, x='a' ; (x,)[0] == x[0] == x .. but are only equal until x changes to something not-1-long-sequence..
    - nomel 3y ago
      I try to avoid statistical programming, preferring determinism, driven by intent. ;) So, I use "is" since "is" is not a context dependent concept, like equals is. I've seen this once in the wild, and it made sense for its use: def __eq__(self, other): return bool(self) == bool(other)
Timothycquinn 3y ago
You are correct. I kind of took `is None` for granted as it just feels boilerplate when coding in Python. Although I have written over a hundred thousand of lines of code in Python over the years; I use Python mostly for dev ops tooling, reporting, monitoring and automation so they don't get super complex and they mostly can lean on procedural programming patterns. I could imagine complex frameworks needing heavy use of Objects that could lean on the 'is' keyword.

Or check that two dicts really are the same object, as opposed to two different dict objects that just happen to have the same keys/values?

wodenokoto 3y ago
I'm not sure I've ever had to do that. When is that a need?
- misnome 3y ago
  My immediate first thought is, optimisation? If you know you’ve been the same object, you could skip e.g. comparison, or change update logic
  - dist-epoch 3y ago
    This kind of micro optimizations don't make much sense in Python. They complicate the code, and you are still 100 times slower than compiled languages.
    - misnome 3y ago
      It really… doesn’t have to complicate. And I disagree that optimising python code is never necessary. Not everybody is writing 100-line one-off glue scripts. Also, you are somewhat changing the topic from “what is an example of when you might want to is-compare two dicts”, no?

thrdbndndn 3y ago

I personally do use "if var is None:", but can't you just use "if var == None"?

nomel 3y ago
‘is’ checks if it the object ids are the same, with None having a unique one. Equals can be tricked. Here’s a class that is equal to None, and everything else: class EqualsEverything: def __equals__(self, other: Any) -> bool: return True
- thrdbndndn 3y ago
  Thanks, I saw this on SO too. Just curious: would it ever happen in practice?
  - svilen_dobrev 3y ago
    every little thing happens in practice... usually unnoticed and buried while refactoring something innocent/ly. sooner or later the __eq__ method will be redefined for some class, then reworked, and then.. == None might not be what was supposed to be.. or, my favorite, x='a' ; (x,)[0] == x[0] == x .. but are only equal until x changes to something not-1-long-sequence..
  - nomel 3y ago
    I try to avoid statistical programming, preferring determinism, driven by intent. ;) So, I use "is" since "is" is not a context dependent concept, like equals is. I've seen this once in the wild, and it made sense for its use: def __eq__(self, other): return bool(self) == bool(other)

Timothycquinn 3y ago

You are correct. I kind of took `is None` for granted as it just feels boilerplate when coding in Python. Although I have written over a hundred thousand of lines of code in Python over the years; I use Python mostly for dev ops tooling, reporting, monitoring and automation so they don't get super complex and they mostly can lean on procedural programming patterns. I could imagine complex frameworks needing heavy use of Objects that could lean on the 'is' keyword.