I'd argue that if it's strict explicitness you want, python is the wrong language. if not var is a standard pattern in python. You would be making your code slower for no good reason.

[–] sebsch@discuss.tchncs.de 5 points 3 months ago (3 children)

I never understood that argument. If you can be sure the type is a collection (and this you always should) not list is so moch easier to read and understood than the length check.

[–] Nalivai@lemmy.world 4 points 3 months ago* (last edited 3 months ago)

How many elements in that list? Ah, it's not list. It's list, of course, we checked. But it's not.

[–] furrowsofar@beehaw.org 3 points 3 months ago* (last edited 3 months ago)

Compact does not mean easier to understand. They are different tests. The point is, do not make code less readable for speed unless speed matters. I am not going to argue which is more readable in any specific case. That is up to the developer.

[–] muntedcrocodile@lemm.ee 2 points 3 months ago (1 children)

Is it? Why introduce an additional conversion from not list means empty list that u have to hold in your head. I want to check length I check length I would argue is easyer to comprehend.

[–] sugar_in_your_tea@sh.itjust.works 2 points 3 months ago (1 children)

Because that's a fundamental aspect of Python. When you're using a language, you should be familiar with the truthiness values. In Python, it's pretty sane:

[], {}, set(), "", None, False 0 and related values are all "falesy"
everything else is truthy

Basically, if you have non-default values, it's truthy. Why wouldn't you trust basic features of the language?

[–] muntedcrocodile@lemm.ee 1 points 3 months ago (1 children)

Because I have to do the is this falsy to what I'm actually interested conversion in my head.

Say ur deep inside some complicated piece of logic and u are trying to understand. Now u have a bunch of assumptions in your head. You should be trying to eliminate as many if these assumptions with good code as possible eg u test ur fail case and return/continue that so u don't need to keep that assumption in ur head.

Say I then come along a if not x then you have to figure out what is x what is the truthiness of its type. If I come across an if len(x) == 0 then I automatically know that x is some collection of objects and I'm testing its emptiness.

[–] sugar_in_your_tea@sh.itjust.works 0 points 3 months ago (1 children)

That's why there's type hinting, unit tests, and doc strings. I don't need to guess what the type is intended to be, I can see it.

[–] muntedcrocodile@lemm.ee 1 points 3 months ago (1 children)

But that's an extra step of logic u must hold in ur head while trying to understand 12 other things.

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 months ago

What's the extra logic?

if x:

This always evaluates to True if it's non-empty. There's no extra logic.

If you have to keep 12 things in your head, your code is poorly structured/documented. A given function should be simple, making it plainly obvious what it's intended to do. Use type hints to specify what a variable should be, and use static analysis to catch most deviations. The more you trust your tools, the more assumptions you can safely make.

[–] sugar_in_your_tea@sh.itjust.works 4 points 3 months ago (1 children)

Why? not x means x is None or len(x) == 0 for lists. len(x) == 0 will raise an exception if x is None. In most cases, the distinction between None and [] isn't important, and if it is, I'd expect separate checks for those (again, for explicitness) since you'd presumably handle each case differently.

In short:

if the distinction between None and [] is important, have separate checks
if not, not x should be your default, since that way it's a common pattern for all types

[–] muntedcrocodile@lemm.ee 1 points 3 months ago (1 children)

I try to avoid having the same variable with different types I find it is often the cause of difficult to debug bugs. I struggle to think of a case where u would be performing a check that could be an empty list or None where both are expected possible values.

[–] sugar_in_your_tea@sh.itjust.works 2 points 3 months ago* (last edited 3 months ago) (1 children)

Really? I get that all the time. I do web dev, and our APIs have a lot of optional fields.

[–] muntedcrocodile@lemm.ee 0 points 3 months ago (1 children)

I do web dev

Theirs ur problem.

But in all seriousness I think if u def some_func(*args, kwarg=[]) Is a more explicit form of def some_func(*args, kwarg=None)

[–] sugar_in_your_tea@sh.itjust.works 3 points 3 months ago* (last edited 3 months ago) (1 children)

def some_func(*args, kwarg=[])

Don't do this:

def fun(l=[]):
    l.append(len(l))
    return l

fun()  # [0]
fun()  # [0, 1]
fun(l=[])  # [0]
fun()  # [0, 1, 2]
fun(l=None)  # raise AttributeError or TypeError if len(l) comes first

This can be downright cryptic if you're passing things dynamically, such as:

def caller(*args, **kwargs):
    fun(*args, **kwargs)

It's much safer to do a simple check at the beginning:

if not l: 
    l = []

[–] muntedcrocodile@lemm.ee 1 points 3 months ago (2 children)

I like the exception being raised their is no reason I should be passing in None to the function it means I've fucked up the value of whatever I'm passing in at some point.

[–] logging_strict@programming.dev 2 points 3 months ago (1 children)

Oh no a stray None! Take cover ...

Robust codebase should never fail from a stray None

Chaos testing is specifically geared towards bullet proofing code against unexpected param types including None.

The only exception is for private support function for type specific checking functions. Where it's obviously only for one type ever.

We live in clownworld, i'm a clown and keep the company of shit throwing monkeys.

[–] muntedcrocodile@lemm.ee 1 points 3 months ago (1 children)

Ur function args if fucked up should always throw an error that's the entire point of python type hints

[–] logging_strict@programming.dev 1 points 3 months ago

type hints are static, not necessarily runtime.

A chaos monkey throws everything at everything to see what breaks.

That won't be caught by perfect type hints, which is merely one tool in the toolbox.

and when things break, often hear WAD, works as designed. Or some other nonsense excuse.

[–] sugar_in_your_tea@sh.itjust.works 2 points 3 months ago

Then make it explicit:

if l is None:
    raise ValueError("Must provide a valid value for...")

Having an attribute or type error rarely provides the right amount of context to immediately recognize the error, especially if it's deep inside the application. A lot of our old code makes stupid errors like TypeError: operator - not defined on types NoneType and float, because someone screwed up somewhere and wasn't strict on checks. Don't reply on implicit exceptions, explicitly raise them so you can add context, because sometimes stacktraces get lost and all you have is the error message.

But in my experience, the practical difference between [] and None is essentially zero, except in a few cases, and those should stand out. I have a few places with logic like this:

if l is None:
    raise MyCustomInvalidException("Must provide a list")
if not l: 
    # nothing to do
    return

For example, if I make a task runner, an empty list could validly mean no arguments, while a null list means the caller screwed up somewhere and probably forgot to provide them.

Explicit is better than implicit, and simple is better than complex.

[–] ExtremeDullard@lemmy.sdf.org 3 points 3 months ago* (last edited 3 months ago)

In complex cases where speed is less important than maintainability, I tend to agree.

In this case, a simple comment would suffice. And in fact nothing at all would be okay for any half-competent Python coder, as testing if lists are empty with if not is super-standard.

[–] logging_strict@programming.dev 1 points 3 months ago

Another use case is to reduce maintenance cost