New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
req_rate is a namedtuple type rather than instance #75506
Comments
Ref: https://news.ycombinator.com/item?id=15136961 They are mistaken in the nature of the bug, which is that req_rate is |
entry.req_rate = req_rate(RequestRate)
|
Good catch and thank you for turning the bug report in the HN thread to a pull request! I agree with all of Raymond's comments. I have two more comments:
|
There was a typo in my previous message. The instantiation code should be: entry.req_rate = RequestRate(int(numbers[0]), int(numbers[1])) |
What is a reason of making req_rate a named tuple? |
I don't know the original reason but it seems like a normal use of named tuples to make the data more self-describing to help with debugging and also to support field access by name, rr.requests or rr.seconds is clearer than rr[0] or rr[1]. |
This is a normal use of named tuples for adding access by name to tuple results. But req_rate never was a tuple. Nobody used rr[0]. |
There is no rule that something had to be a tuple at some point in its history before becoming a named tuple. This use seems perfectly reasonable to me. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: