9 Comments

I disagree with some of these (the len bit most strongly) but I appreciate seeing people talk about them.

Expand full comment

I agree with most of these, but I don't like for/else. I rarely see it in the wild, and whenever I do, I have to pause and think about what it does. I think the flag pattern is clearer.

Expand full comment

Thanks. The one I tend to forget about is using 'else' with 'for' or 'while'.

Expand full comment

Nice article as always :)

Never knew for the history behind "# -*- coding: utf-8 -*-" Thanks a lot

Also when you say "The API contract is not the only thing that matters" I don't see the corollary of that ^^

Can you tell me?

Expand full comment

Well, some things can change drastically the behavior of a program but are not explicitly defined in the function signature:

- performances

- thread safety

- io reliability

- etc

Pretty much everything that is a side effect of function.

And my opinion is that if your function changes too much on those aspects, even keeping the same input and output params, types and names, I would consider it breaking compatibility.

E.G: if a function changes to suddenly takes 100 times more CPU for security reason, then one should bump the code to a new major version in SemVer, because the assumption of the code using it will change drastically.

Expand full comment

OK, I see. I've never thought of it that way.

Thanks for the explanatiion

Expand full comment

Hi

Thank you for the funny and interesting article. A question though: Is there not at "if" missing, like "if f.endswith('z')`"?

for f in flowers:

f.endswith('z'):

print('Found it!')

break

else:

print('Not found :(')

Best regards!

Expand full comment

Indeed lol. Thanks.

Expand full comment

With pleasure. I actually tiped the code snippet into a REPL, because I was not sure, whether this was an unknown Python syntax quirk ^^

Expand full comment