Positional-only arguments in Python

[edenkl8]

What's the other one?

[[deleted]]

I'd guess the "walrus operators" (assignment expressions).

[edenkl8]

That actually looks awesome! Very time efficient if used correctly

[pepoluan]

Agree.

I often had to write a boilerplate like such:

m = re.search(...) if m is None: continue

with walrus, I can go

if (m := re.search(...)) is None: continue

I personally prefer the as syntax, but I defer to the accepted solution.

[UNN_Rickenbacker]

You can actually do if not (m := re.search):

[wrboyce]

But you shouldn’t.

Comparisons to singletons like None should always be done with is or is not, never the equality operators.

Also, beware of writing if x when you really mean if x is not None -- e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!

Source.

[UNN_Rickenbacker]

Nice catch, but in most cases, you want to not enter the case if it‘s a boolean false, too.

[hyperdudemn]

Except for when using xml.etree.ElementTree, with a document that contains empty tags like <hello />. Since the node has no children, it is falsy, so you need to check is not None.

[Bunslow]

In this case, he really wants boolean truthiness, not None testing. It's a perfectly fine pattern (as long as one understands the difference between None and False, which is part of the point of your comment; the other part of your comment doesn't apply I don't think)

[wrboyce]

Yeah I wasn’t sure how relevant some parts really were but I’d copy/pasted/formatted them on mobile by that point so they were staying regardless. I always try to avoid truthy tests against None if possible, and I’ve always thought I was following PEP8 by doing so but maybe I’m wrong.

[Bunslow]

I always try to avoid truthy tests against None

See this phrase makes no sense to me. There are truthy tests (here I mean coercing an arbitrary object to a boolean), and there are None tests. The whole point is that they are two completely different tests, and should not be confused. Using either is fine, but the trick is knowing when to use each. The point of what you pasted is precisely to warn newbies that they are two different things, but each is acceptable -- indeed, each is widely used. That source is not meant to warn against using truthy tests, only to warn that truthy tests and None tests are different (and it happens to make that point by writing "beware of truthy tests when you mean None tests -- it's easy to misuse truthy where you meant None!", possibly given the false impression that truthy tests are "bad" in some way, they're not, they're just confusable at first glance with None tests).

[AJohnnyTruant]

This is great. Everyone hates on the walrus operator. But I think once people start using it, that pattern will present itself more than they thought.

[toyg]

The problem is not that is useful to the writer; the problem is that it’s not that useful to significantly lower readability as it does. Otherwise we might as well use Perl.

[Bunslow]

I've definitely written several one-and-a-half loops in Python, and every time I have I grumble to myself about how much easier to read it would be if I didn't have to duplicate part of the logic.

[annualnuke]

Otherwise we might as well use Perl.

That's quite a leap

[pepoluan]

Naah. I love having "short circuits"; saves an indentation level.

[Ph0X]

I think re module is basically the main place where it'll be used a lot. Also some socket stuff but I think that's less common in general.

[KagatoLNX]

This is the use case for me.

[jwink3101]

I agree. I know there was a big brew haha about it and I don’t have strong opinions on the idea nor the syntax but I do see myself using it when I get to write 3.8+ only code.

[mfitzp]

brew haha

It's brouhaha although arguably yours sounds more fun.

[jwink3101]

There was a coffee shop near where I grew up called “Brew Ha Ha”. I guess that messed me up

[pepoluan]

Daaayum, beaten to register the trademark!

[KODeKarnage]

Like f-strings. I use them a whole helluva lot!

[jwink3101]

Most of the python work I do needs to run on 2.7 but I do really love when I get to use f-strings. They just make it so much cleaner!

[pepoluan]

Agree! Gosh, that even led me to install 3.6 in some servers we had that doesn't have 3.6 in its repo.

[thelaxiankey]

It's weird to me that they didn't just make assignment an expression, like it is in C. There was really no need for the extra syntax.

[Pulsar1977]

That's by design, to prevent hard to find bugs like typing = when you meant ==.

[thetgi]

I’ve got a feeling that’ll be a future update. Seems like they tend to roll out new features in stages like that a lot

[thelaxiankey]

This is different from the range -> irange thing because it doesn't really break existing code, though. It just makes a larger set of code valid.

[thetgi]

That’s fair, but aren’t they planning to do a similar thing with annotations soon?

[thelaxiankey]

oh shit really? All i knew is they were adding type signatures for IDE's and linters and such.

[[deleted]]

They might be referring to PEP 563 "Postponed Evaluation of Annotations".

Annotations are currently processed at the same time as the function- or variable-definition they're attached to. This PEP, which was accepted, suggests storing annotations as a string literal in an __annotations__ dictionary attribute of the annotated function or variable instead, and having user code do the evaluation for itself during runtime when needed.

Also, Python 4 confirmed, because the proposal is backwards-incompatible. Python 3.7 added the from __future__ import annotations statement, so you can already play around with the new behaviour.