When there's a special syntax, that syntax is often more performant and more standard than a function call. A special syntax is often a hint that (per the Zen of Python) this is "the one obvious way".

Using the list literal syntax is faster is considered to be more idiomatic and more readable.

New Python programmers sometimes pick up a habit of calling "list()" to create an empty list, like this:

numbers = list()

This *does* technically work, but I recommend against this.

Use the "list literal" syntax instead:

numbers = []

Why?

Mostly because that's the way we do it.

But why...?

We usually prefer to rely on truthiness instead...

So instead of this:

if flag is True:
...

Do this:

if flag:
...

Instead of checking for True, False, and non-boolean values (to raise an exception), using truthiness allows others to provide non-boolean values as truthiness indicators.

Instead of checking for True and False with equality:

if flag == True:
...

We prefer to check for True and False with identity:

if flag is True:
...

This is for the same reason that we prefer to check for None with identity (PEP 8 recommends it).

But instead of True/False checks...

For more on this topic watch (or read):

• truthiness: pym.dev/truthiness/
• checking for an empty list: pym.dev/checking-for...

For practice with this topic, solve rotate_list through the final bonus: pym.dev/exercises/5d...

This only works well for objects that will be either None or a truthy object.

So be careful NOT to rely on truthiness for None checks if you need to distinguish between EMPTINESS and None.

For example this:
if name:
...

Would evaluate as false/falsey if name was None OR an empty string ("").

While you're at it, consider relying on truthiness for None and non-None checks as well.

So instead of this:
if match is not None:
...

You would write this:
if match:
...

It's common to see this convention used with regex utilities, often with a walrus operator: pym.dev/using-walrus...

While you don't strictly NEED to rely on truthiness to check emptiness, I would recommend it.

This pattern may seem odd, but it's very common.

Once you've seen this pattern enough, the "is this non-empty" question starts to feel more sensible than "does this list have more than 0 items in it?"

So truthiness can be used to check for non-emptiness.

That also means that falsiness can also be used to check for emptiness.

So for lists, this:
if not items:
...

Is equivalent to this:
if len(items) == 0:
...

For lists, strings, tuples, sets, dictionaries and pretty much all data structures (a.k.a. "collections"), a truthiness check is a non-emptiness check.

Meaning empty collections are falsey and non-empty ones are truthy.

When an object is used in a boolean context (like in an "if" or "while" condition) it's implicitly converted to a boolean. This is called a "truth value" test, though colloquially it's pretty much always called "truthiness".

Oh I'm 2 weeks advance in actually writing them. My brain dump ideas are all just one or try sentences (literally a many hundred bullet point list) of enough of a things that my future self can figure out the whole tip (I hope at least...)

I was worried whether I'd actually come up with a full 365, so I've been brain dumping.

I'm at 300 potential tips now and feel squeezed dry. Although I felt the same at 270... 🙃

I'm definitely getting into the "ooh this is a thing I said to a student once but have never publicly shared" territory.

I don't have a great argument for following this rule nor a good reason to break it, so I think consistency with all other Python code in the wild should win out.

Use identity checks with None because PEP 8 says so.

So instead of:
value == None

Do this:
value is None

But after the Introduction section in PEP 8, there's a section called "A Foolish Consistency is the Hobgoblin of Little Minds" which argues that style guides should occasionally be broken.

I would recommend breaking this style rule but... I don't have a very good reason to break this rule!

I'm also not convinced by the "it's faster" argument. We do SO many other slightly slower things for readability's sake in Python!

So... we should use identity checks because it was declared a good idea and made its way into PEP8, which the community largely embraces as Python's style guide.

For an equality check, an object could claim to be equal to None but identity can't be overloaded. So identity checks for one-and-only None object.

But in my opinion, that doesn't really matter... if an object wants to claim that it's equal to None, I don't see a good reason to stop it.

But... why use identity when checking for None?

Because that's what everyone else does, so seeing result == None looks weird.

Seriously. That's the real reason.

Well... there are 2 (less convincing) reasons:

1. It ensures that we're looking *only* for None
2. It's faster than an equality check