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 1 month 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 1 month ago* (last edited 1 month 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 1 month ago* (last edited 1 month 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 1 month 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks ago* (last edited 4 weeks 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 4 weeks 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 4 weeks ago* (last edited 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 weeks 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 4 weeks 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 1 month ago* (last edited 1 month 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 4 weeks ago

Another use case is to reduce maintenance cost

[–] Kissaki@programming.dev 11 points 1 month ago* (last edited 1 month ago) (3 children)

One of the principles of the Pythonic style is: simple is better than complex.

But is it when you consider ambiguity and expressiveness too?

len(mylist) tells me it's definitely a list and not null or whatever. It also tells me the intent of whoever writes the code was checking length.

If it requires a long article to explain, I'd certainly be hesitant to use and prefer. The question is, is it surprising or intuitive that the truthy becomes a length check. What do you want to express with your code. And who will read it, and what expectations and requirements do you want to require of them.

For sequence type objects, such as lists, their truth value is False if they are empty.

[–] sugar_in_your_tea@sh.itjust.works 8 points 4 weeks ago* (last edited 4 weeks ago)

len(mylist) tells me it’s definitely a list and not null or whatever

Do you know what else can tell you it's a list? Type hinting.

If I care about the distinction between None and an empty list, I'll make separate checks. len(None) raises an exception, and most of the time that's not what I want when checking whether there's something in the list, so not x is generally preferred, especially when type hinting is used consistently enough to be reasonably sure I'm actually getting a list or None. If I get something else, that means things got really broken and they'll likely get an exception alter (i.e. when doing anything list-like).

For sequence type objects, such as lists, their truth value is False if they are empty.

That's generally exactly what I want. len(x) == 0 doesn't tell you it's a list, it just tells you it has __len__. So that could be a dict, list, or a number of other types that have a length, but aren't lists.

Don't rely on checks like that to tell you what type a thing is.

[–] Michal@programming.dev 6 points 4 weeks ago

It's just how pythonic code is written. All python developers know that not and bool can indicate that variable is either empty or null. They will also use the in operator and other python specific syntax.

[–] clay_pidgin@sh.itjust.works 5 points 4 weeks ago (1 children)

foo = "potatoes!"

len(foo)

will give you the number of characters in the string. It's not a surefire way to find a list at all!

[–] sugar_in_your_tea@sh.itjust.works 3 points 4 weeks ago

Same with dictionaries, iterators (will consume the iterator!), and anything else that has a length.

I've actually had the string instead of list issue a number of times, because sometimes things get off and it's hard to track down where things went wrong.

For this reason, I think type hints are the way to go. Use them consistently w/ a static analysis tool like pyright and you'll catch a lot of these issues before running into cryptic error messages.

[–] Dark_Arc@social.packetloss.gg 9 points 4 weeks ago* (last edited 4 weeks ago) (4 children)

I don't know about others ... but I'm not using Python for execution speed.

Typically the biggest problem in a program is not 100 million calls of len(x) == 0. If it was, the interpreter could just translate that expression during parsing.

[–] FizzyOrange@programming.dev 6 points 4 weeks ago

I mean, nobody uses Python for execution speed precisely because it is so slow.

[–] sugar_in_your_tea@sh.itjust.works 6 points 4 weeks ago* (last edited 4 weeks ago) (1 children)

Even so, not x is a pretty nice-to-read pattern, and it's nice that it's faster than the less nice len(x) == 0. I generally do not care to distinguish whether a list is None or empty, I just want to know if there's something there. If I care, then I'll typically separate those checks anyway: if x is None: ..., if len(x) == 0: ....

[–] Dark_Arc@social.packetloss.gg 3 points 4 weeks ago (1 children)

I prefer the clarity of len(x) == 0 personally; it's a pretty low syntactic penalty to clarify intent.

Obviously, if your variable names are good and you're consistent about your usage not list can be fine too, but it is a very JavaScript-y thing to me to be that vague and/or rely on "truthiness."

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

The notion of truthiness is defined by the language.

Here are most of the built-in objects considered false:

constants defined to be false: None and False

zero of any numeric type: 0, 0.0, 0j, Decimal(0), Fraction(0, 1)

empty sequences and collections: '', (), [], {}, set(), range(0)

It's not something that happens to work, it's literally defined that way.

if not x is the common way to tell if you have data or not, and in most cases, the difference between None and empty data ([], {}, etc) isn't important.

len(x) == 0 will raise an exception if you give it None, and that's usually not what you want. So I guess the verbose way to do that is if x is None or len(x) == 0:, but that's exactly equivalent to if not x, with the small caveat that it doesn't check if the value has __len__ implemented. If you're getting wonky types thrown around (i.e. getting a class instance when expecting a list), you have bigger problems.

I use type hinting on pretty much all "public" methods and functions, and many of my "private" methods and functions as well. As such, sending the wrong types is incredibly unlikely, so not x is more than sufficient and clearly indicates intent (do I have data?).

[–] Dark_Arc@social.packetloss.gg 2 points 4 weeks ago* (last edited 4 weeks ago) (1 children)

I did not say it's not semantically well defined.

https://en.wikipedia.org/wiki/Brainfuck#Hello_World! -- this is semantically well defined, but it's still vague. Vagueness is a property of how well the syntax is conveying intent.

[–] sugar_in_your_tea@sh.itjust.works 2 points 4 weeks ago

It's only vague if coming from a language where it's invalid or vague semantically. For example:

Javascript - [] is truthy for whatever reason
C - int x[] = {}; evaluates to true because it's a pointer; C only evaluates to false if something is 0
Rust - invalid because you cannot convert a vec -> bool directly, and there's no concept of null (same w/ Go, but Go has nil, but requires explicit checks)
Lua - empty tables, zero, and empty strings are truthy; basically, it's truthy unless it's nil or false

The only surprising one here is Javascript. I argue Lua and Python make sense for the same reason, Lua just decided to evaluate truthiness based on whether the variable is set, whereas Python decided to evaluate it based on the contents of the variable. I prefer the Python approach here, but I prefer Lua as a language generally (love the simplicity).

[–] AnyOldName3@lemmy.world 3 points 4 weeks ago (1 children)

The interpreter can't make the replacement until it's about to execute the line as __bool__ and __len__ are both (Python's equivalent of) virtual functions, so it's got to know the runtime type to know if the substitution is valid. Once it's that late, it'll often be faster to execute the requested function than work out if it could execute something faster instead. Even with type hints, it's possible that a subclass with overridden methods could be passed in, so it's not safe to do anything until the real runtime type is known.

Once there's a JIT involved, there's an opportunity to detect the common types passed to a function and call specialised implementations, but I don't think Python's JIT is clever enough for this. LuaJIT definitely does this kind of optimisation, though.

[–] Dark_Arc@social.packetloss.gg 1 points 4 weeks ago* (last edited 4 weeks ago)

Hm... I'll admit I wasn't awkward of the .__len__ function. ~~However, does this mean it's possible to write a len(x) == 0 that's diverges from not x?~~

~~If not, then the substitution is still valid (and not presumably also considers the same fundamental. If so, that's kind of silly.~~

EDIT: I missed the part of your comment about .__bool__ ... so yeah in theory you could have something where these two operations are not equivalent.

Arguably, you could just say that's pathological and invalid. Then, still have an optimized path to prefer not .__bool__() if .__len__() == 0 is the comparison you'd be making. Even with the extra interpreter check during evaluation, that would quite possibly be faster if the overhead is truly high.

EDIT 2: you'd probably need a little bit more overhead than a straight substitution anyways because you need to maintain the semantic of "if this thing is None it's not valid if the syntax was originally len(x)."

[–] Reptorian@programming.dev 1 points 4 weeks ago (1 children)

This. I rarely boot up Python for the tasks I need to do, and if they are, they are one of the following:

Assistant code for other coding language
Throwaway script
Prototype before using a faster language

[–] logging_strict@programming.dev 2 points 4 weeks ago

Assuming an equivalent package is produced, what's the maintenance cost (factoring in coder availability) difference between the Python vs faster language implementations?

^^ therein lies the rub

Reminds of the expression, premature optimization is the root of all evil

if not swimming in funding, might be a darwinic move to choose the faster language and have to code everything yourself from scratch

[–] Michal@programming.dev 7 points 4 weeks ago* (last edited 4 weeks ago)

Makes perfect sense. If you're checking if a collection is empty you don't need to know its exact size. Getting the size can be very inefficient in collections like linked lists or trees, if you have to follow all nodes. To check if it's empty, all you need fo know if at least one item exists. If one does, there's no point counting the rest.

People who don't understand the difference will probably not understand the difference between passing a list and passing an literator/generator to any() .

[–] Kissaki@programming.dev 5 points 1 month ago (1 children)

While the 2nd approach is not wrong, the first method is considered more Pythonic. Many people don’t agree, but I’ve already put forward my points in a previous article on that debate.

Does Pythonic mean best practice in the python community or "good python"?

If "many people don't agree", how can they claim it to be "pythonic"? Isn't that contradictory?

[–] sugar_in_your_tea@sh.itjust.works 5 points 4 weeks ago* (last edited 4 weeks ago)

"Many" isn't the same as "most," though I don't think there's any way to know what "most" is.

But here's my reason for agreeing w/ the OP:

not x checks both None and emptiness, which is usually desired
len(x) == 0 will raise an exception if x is null
with type hinting, those should be the only two reasonable options

It's nice that it's slightly faster, though performance has absolutely nothing to do w/ my preference, though it does have something to do with my preference for avoiding exceptions for non-exceptional cases.

[–] MadhuGururajan@programming.dev 3 points 4 weeks ago

lol this whole article and this thread is a bunch of bikeshedding I haven't had the privilege of enduring in some weeks.

[–] lb_o@lemmy.world 2 points 4 weeks ago

One more ridiculous fact about the Python to know Thank you for sharing.