[issue31325] req_rate is a namedtuple type rather than instance

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31325] req_rate is a namedtuple type rather than instance

Raymond Hettinger added the comment: New changeset ff847d1ac7e6a8ee1fb6f8883cfb4aec4b4a9b03 by Raymond Hettinger (Miss Islington (bot)) in branch '3.6': bpo-31325: Fix usage of namedtuple in RobotFileParser.parse() (GH-4529) (#4533)

[issue31325] req_rate is a namedtuple type rather than instance

Raymond Hettinger added the comment: New changeset 3df02dbc8e197053105f9dffeae40b04ec66766e by Raymond Hettinger (Berker Peksag) in branch 'master': bpo-31325: Fix usage of namedtuple in RobotFileParser.parse() (#4529)

[issue31325] req_rate is a namedtuple type rather than instance

Change by Roundup Robot : -- pull_requests: +4469 ___ Python tracker ___

[issue31325] req_rate is a namedtuple type rather than instance

Change by Berker Peksag : -- keywords: +patch pull_requests: +4465 ___ Python tracker ___

[issue31325] req_rate is a namedtuple type rather than instance

Raymond Hettinger added the comment: 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. -- ___ Python tracker

[issue31325] req_rate is a namedtuple type rather than instance

Serhiy Storchaka added the comment: 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]. -- ___ Python tracker

[issue31325] req_rate is a namedtuple type rather than instance

Raymond Hettinger added the comment: > 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

[issue31325] req_rate is a namedtuple type rather than instance

Serhiy Storchaka added the comment: What is a reason of making req_rate a named tuple? -- ___ Python tracker ___

[issue31325] req_rate is a namedtuple type rather than instance

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue31325] req_rate is a namedtuple type rather than instance

Raymond Hettinger added the comment: There was a typo in my previous message. The instantiation code should be: entry.req_rate = RequestRate(int(numbers[0]), int(numbers[1])) -- ___ Python tracker

[issue31325] req_rate is a namedtuple type rather than instance

Berker Peksag added the comment: 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: * Please follow our commit style at https://devguide.python.org/committing/#commit-messages * We need a

[issue31325] req_rate is a namedtuple type rather than instance

Raymond Hettinger added the comment: * The named tuple class should begin with a capital letter and be fully self-documenting: "RequestRate". * The creation of the named tuple class should be done only once, not on every call. Instead only a new instance should be creating on every call:

[issue31325] req_rate is a namedtuple type rather than instance

Changes by Raymond Hettinger : -- versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker ___

[issue31325] req_rate is a namedtuple type rather than instance

New submission from Robin: > Finally, urllib/robotparser.py appears to contain a bug in the > following: > > req_rate = collections.namedtuple('req_rate', >'requests seconds') > entry.req_rate = req_rate > entry.req_rate.requests = int(numbers[0]) >