Am I the only one who is not particularly impressed by any of these links? Maybe I should see it as exemplatory examples, but they would not make it through a Code Review.

-> Currently serving as Application Architect for a medium sized Python application.

For the purposes of discussion, it'd probably be helpful to describe the issues you would identify during review

I’ve just found one. Shortening “input” to “inp” [0] is a big no.

[0] https://github.com/dabeaz/blog/blob/main/2023/three-problems...

Guess it's pretty decent code when the point of contention is about a single variable name being abbreviated.

This was the first and most obvious problem I found upon looking for a few seconds. I don't know if this is the only issue with the code.

The symbol "input" is a Python built-in.

Don't shadow. Just don't. We've got enough variable names in the universe. :)

Strong agree. To clarify, I wouldn't shadow. I wouldn't use “inp” either.

One fairly common convention is to suffix with `_` to avoid shadowing, e.g. `input_`

shadowing is what instantly would have me reject a peer review. there is literally no excuse.

inp is just standard in python, along with uin (user input), or sometimes also raw or iraw.

You cannot win this battle. There is nothing wrong with 'inp'

Please don't shadow ever :(

Man..

That’s seriously the glaring issue you’ve found? It’s a tutorial ffs. Have you actually done code reviews professionally?

I didn't say it was a glaring issue. But, unnecessary cognitive burden on the reader is unacceptable.

> Have you actually done code reviews professionally?

Yes, I did.

That's the silliest thing for you to bikeshed about.

In a serious code review, that isn't even a starter of an issue, if you have context surrounding that variable. Furthermore `input` is an actual Python function, and shortening an example for learning purposes is not the same as asking other people do the same in production code.

haha you should see the code review comments at my <current job>. Random people spend hours bickering over variable names, while completely overlooking real issues in the code and rubberstamping their friends. It's like a friggin cult.

'written by the same author' -- thought it's dbeazley, it's somebody else in fact.

Fixed it, i meant that both of the books mentioned are written by Harry Percival (and the 2nd was written as a sequel) .

damn, I feel really dumb trying to follow the logic of all those function compositions in the three problems post

You shouldn't. Author seems pretty tongue-in-cheek about it:

> lambda has the benefit of making the code compact and foreboding. Plus, it prevents people from trying to add meaningful names, documentation or type-hints to the thing that is about to unfold.

Disclaimer, I did not read the entire post.

Python isn't the best language for exploring this sort of thing, by the author's own admission.