Parts of requests has been adopted into stdlib: https://docs.python.org/3/library/urllib.request.html

People mostly defer to requests because they do not track language development closely and because we are creatures of habit.

I try to avoid non-stdlib packages when stdlib will do a good job, but I received negative feedback from people who aren't aware of the updates and couldn't foresee supply-chain attacks.

The current standard library urllib is a refactoring of previous attempts from the 2.x standard library, and urllib.request is just a sub-package. It does not represent adoption of requests; requests builds on urllib3, which was created to fill in gaps in what the standard library provided, and named like that because the 2.x standard library had both a `urllib` and a `urllib2` as they struggled to figure it out.

For the same reason GP posted and half the stdlib is written in C: Python is a language that is almost always good enough, but never really the best (and especially when it comes to performance of complex algorithms).

A few confounding factors come up right away: one of professors removed final project which increased grades; due to less appealing CS career, you do not get the best students anymore: another professor is not a fan of curving so perhaps he just accidentally gave harder tests; math prep for CS courses happened over the last 15 years not last 2 where LLMs have become ubiquitous; many failed because they were caught using LLMs when not allowed...

So really, two professors' gut feel about what the reasons are and not backed by much.

Not at my laptop to check with inspector, but does it at least use next/prev type "Link" headers (even if no browser would consume them)?

As said already: readability and maintainability of the code (closely related) are two most important values a code review can get you.

I have seen many a PR where it is obvious it is an exploratory work: eg. figuring out how to use an external dependency that is imperfectly or incorrectly documented, etc. (You can claim this should be done ahead of time, but experience tells me you need to code it to learn it)

The emotional toll there is real, but this is exactly the moment when you expose the knowledge of that external dependency to the unbiased party that is the reviewer.

I like combining approvals to satisfy the urge for completion and closure, with a request for fast-follow refactor to better match the newly discovered model of interaction. (The worst code review experience I have seen is when a reviewer accepts it as-is and does a fast follow refactor themselves, depriving the author of the opportunity to learn and remain an expert in that area)

A discussion ahead of the implementation can also bias the two parties to that discussion and have them overlook the same implementation issue: many things you only understand once you start implementing.

If you have these parties review each other's code, I agree that rarely brings much value.

I think the best way to understand our experience with reviews is to stop and say: in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious)

> in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious)

From my perspective, there are three sorts of PRs:

- One is very close to the final form of a particular change, and any feedback you get at that late stage is indicative of holes in your process.

- Another is one where someone throws something up and says "hey, this is an experiment, can I get feedback on the approach". This is great, the parameters are clear, not much to say about these.

- The 3rd sort is someone making a trivial 5-line patch to a makefile/cargo.toml/github workflow/etc. These add basically no value to anyone.

Of those only the 2nd type really brings much value, and those are the ones that folks would keep posting even if you didn't require PRs (since they have an actual question, or a cool thing to show off).

I'll also note that this only really negatively impacts small remote teams, because on a sufficiently large, co-located team, you just ask your buddy one desk over to rubber stamp all the trivial commits...

On the first category, what is a process you use which has no "holes" in it?

Does everybody produce completely readable, tested code every time? Perhaps that's just "style" to you when it is "maintainability" to me?

> Does everybody produce completely readable, tested code every time?

Do your coworkers not reliably produce readable, tested code?

That's kind of the minimum bar for a software engineer in my book

I like to invert that to: do I produce code I am perfectly happy with in regards to readability and maintainability or would I benefit from another pair of eyes?

Every question I get (when my code is reviewed) is a signal that code could be more self-explanatory, unless it is a complex algorithm itself, and that my — by now deep — exposure to the problem is keeping me misguided about what is and isn't "obvious" or "clear". A reviewer can take a step back and help ensure both them and I will be able to easily grasp the same code 3 or 24 months later.

Note that one of the best advice I got early in my career about doing a good code review is that you "just" need to ask good questions: the point is not for a reviewer to show how much smarter they are, but for both to develop a shared understanding and ensure code can be interpreted as quickly as possible.

I agree about how you can reciprocate for a good code review, but I'd just add that for me, code review is also fun — when done for a fellow human who I might be teaching.

It is definitely very grunt-like for an LLM.

How many teams did you see?

On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.

I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.

> your process ought to catch both of those well before the PR stage

We have multiple points where mistakes of any sort can be caught, and code review is one of them.

Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.

This is only a problem if you mostly catch architecture issues at code review phase.

You seem to be talking about how one can expand information into useless babbling, whereas you are responding to a comment about condensing information into true essence.

This is about human attention and what is worth getting it. Both points are very important and valid.