[issue44733] Feature request: maxtasksperchild for ProcessPoolExecutor
Ram Rachum added the comment: Oh that sucks. Logan and Antoine worked on this feature for so long. Thanks for reporting Greg. -- ___ Python tracker <https://bugs.python.org/issue44733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46081] Document the msg argument for assertRaises
Ram Rachum added the comment: I disagree but I guess I'm in the minority here, so I'll close this issue. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46081] Document the msg argument for assertRaises
Ram Rachum added the comment: I'd include that same message you quoted, minus the list of functions, on each and every one of the functions that have this argument. -- ___ Python tracker <https://bugs.python.org/issue46081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46081] Document the msg argument for assertRaises
Ram Rachum added the comment: Thanks, but people looking at a specific function might not guess that the documentation for one of its arguments is hiding somewhere on the long page. This is especially relevant with a confusing argument like `msg`, since it's tempting to think that this would be the message of the expected exception. -- ___ Python tracker <https://bugs.python.org/issue46081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46081] Document the msg argument for assertRaises
New submission from Ram Rachum : The `msg` argument to the `assertRaises` function isn't documented. The documentation should say what this argument does. -- assignee: docs@python components: Documentation messages: 408587 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: Document the msg argument for assertRaises versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45990] Exception notes need more documentation
New submission from Ram Rachum : The new __note__ feature for exception could be useful, but the documentation (and the section in "What's new") aren't good enough: "__note__: A mutable field which is :const:`None` by default and can be set to a string. If it is not :const:`None`, it is included in the traceback. This field can be used to enrich exceptions after they have been caught." This is more of a definition than an explanation. If this is solving a problem, there should be an explanation that starts from the problem being solved, hopefully with 2-3 examples where this is useful. If people start using this feature without some guidance, they might put things in the note that should have been in the message. -- assignee: docs@python components: Documentation messages: 407722 nosy: cool-RR, docs@python, iritkatriel priority: normal severity: normal status: open title: Exception notes need more documentation versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28953] Use `raise from` when raising new IncompleteRead
Ram Rachum added the comment: Okay, works for me. -- ___ Python tracker <https://bugs.python.org/issue28953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28953] Use `raise from` when raising new IncompleteRead
Ram Rachum added the comment: This might work here, but you'd need to be sure there isn't any important code that looks at the IncompleteRead exception and expects the data to be in its message. Also I hope that various tools like IDEs would learn quickly that they need to display the note in their traceback views, otherwise all of these notes would be hidden from many people. -- ___ Python tracker <https://bugs.python.org/issue28953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28953] Use `raise from` when raising new IncompleteRead
Ram Rachum added the comment: Interesting feature Irit, thank you Two things: 1. Is there better documentation for that feature than what was in the CL of the issue you linked to? Because that documentation was more lawyery than explanatory. 2. If I understand correctly, the note is meant for things that don't exactly fit in the exception message for some reason or another. (A better documentation with examples would have given me a clearer understanding of your use cases.) I'm not sure why the message included here should be relegated to a note. -- ___ Python tracker <https://bugs.python.org/issue28953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12653] Provide accelerators for all buttons in Windows installers
Ram Rachum added the comment: I confirmed now in the 3.10 installer on Windows that accelerators are working. Thank you! -- resolution: out of date -> fixed ___ Python tracker <https://bugs.python.org/issue12653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44733] Feature request: maxtasksperchild for ProcessPoolExecutor
Ram Rachum added the comment: Awesome. You can link to experimental code here. Even if it were not accepted to Python, it could be useful for me and for other people who might see this issue. -- ___ Python tracker <https://bugs.python.org/issue44733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44733] Feature request: maxtasksperchild for ProcessPoolExecutor
New submission from Ram Rachum : I love `concurrent.futures`, and I'd like to use it wherever I can. There's a feature in `multiprocessing.Pool` that I wish would also be available in `ProcessPoolExecutor`: The `maxtasksperchild` argument. Documentation: "maxtasksperchild is the number of tasks a worker process can complete before it will exit and be replaced with a fresh worker process, to enable unused resources to be freed. The default maxtasksperchild is None, which means worker processes will live as long as the pool." I want to be able to set it to 1, so each process will only execute one task and then be replaced with a fresh process. -- components: Library (Lib) messages: 398143 nosy: cool-RR, pitrou priority: normal severity: normal status: open title: Feature request: maxtasksperchild for ProcessPoolExecutor type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43002] Exception chaining accepts exception classes
Ram Rachum added the comment: People barely know how to use the right form of this feature. Providing them with a wrong form that's confusingly similar to the right form and fails silently is an unfortunate choice. "Or just don't do anything. A `raise exception` inside an except block will be automatically chained with the current exception [...]" With the wrong message, yes. -- ___ Python tracker <https://bugs.python.org/issue43002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43002] Exception chaining accepts exception classes
New submission from Ram Rachum : I saw this line of code today: https://github.com/hyperledger/sawtooth-sdk-python/commit/c27b962541c9ae68fd1e6dc691ddee883234f112#diff-eb008203eae2160c5e14c42e5fd2eee164709a93bf5136fa79cc256d4e46eaffR92 I was about to tell this guy that his code is bad since the part after the `from` should be a specific exception, not just an exception class. I thought I should double-check myself first. Lo and behold: ``` $ cat x.py def f(): raise TypeError try: f() except TypeError: raise ValueError from TypeError $ python x.py TypeError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "x.py", line 7, in raise ValueError from TypeError ValueError ``` The line doesn't fail, but it silently trims away the stacktrace of the previous exception. (Normally the stacktrace would include what's inside the `f` function.) I'm not sure whether this is intended behavior or not. The documentation does say "the second expression must be another exception class or instance" but (a) it's not clear what the use case is when it's a class and (b) I doubt that the person who wrote the code above, and any other person who writes such code, would be aware that their traceback got snipped until it's too late and they're stuck with a bug report with incomplete information. -- components: Interpreter Core messages: 385499 nosy: cool-RR priority: normal severity: normal status: open title: Exception chaining accepts exception classes type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42391] Clarify documentation of TestCase.assertIs
Change by Ram Rachum : -- keywords: +patch pull_requests: +22241 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23348 ___ Python tracker <https://bugs.python.org/issue42391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42391] Clarify documentation of TestCase.assertIs
New submission from Ram Rachum : Writing the patch now. -- assignee: docs@python components: Documentation messages: 381263 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: Clarify documentation of TestCase.assertIs type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Change by Ram Rachum : -- keywords: +patch pull_requests: +21470 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/22441 ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Ram Rachum added the comment: Sounds good, I'm on it. -- ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41867] Include options for timespec in docstrings of isoformat
Change by Ram Rachum : -- keywords: +patch pull_requests: +21455 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22418 ___ Python tracker <https://bugs.python.org/issue41867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41867] Include options for timespec in docstrings of isoformat
New submission from Ram Rachum : Writing the patch now. -- components: Library (Lib) messages: 377534 nosy: cool-RR priority: normal severity: normal status: open title: Include options for timespec in docstrings of isoformat type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Ram Rachum added the comment: Thanks for your time, and I accept your decision here. I'd appreciate it though if you wouldn't use the term "made up issue" on something that happened to me a couple of days ago. Our opposing positions each have their pros and cons, and it makes sense to me that your approach has more pros than mine. Ease up on the "It's time for this one die now" though. -- ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Ram Rachum added the comment: Yes, but the docs say that the weights are assumed to be nonnegative. I'm assuming the check is done on total because it'd be expensive to do it on each item. A user reading that error message could understand that it's okay for weights to be negative as long as the total isn't, which as far as I understand isn't true. -- ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Ram Rachum added the comment: Speaking of that check, the error message is 'Total of weights must be greater than zero', which is a bit misleading. 'All weights must be positive or zero' would be more accurate. Would you like a PR for that? -- ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Ram Rachum added the comment: I disagree, especially the bit about slowing down the function, since you're checking the total, not every element. Like the check for negative numbers that you do on line 493. But it's your call. -- ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
New submission from Ram Rachum : I was recently tripped up by a bug caused by passing infinite weights to random.choices. I toyed around with that function, and it seemed that when it's given weights that include infinity or NaN, it selects a specific element, always without being random. That's regardless of whether multiple items have infinity weights. It chooses a different specific item if the infinity is negative. The specific item isn't always the one that has the infinite weight. I don't know whether that's the intended behavior for some reason, or whether it's even possible to define a logical behavior for infinite weights. If it's not possible, then maybe this function should raise an errors when given weights that include infinity or nan. I see that the documentation states that the weights must be non-negative; maybe we should have a check for that too. -- components: Library (Lib) messages: 376802 nosy: cool-RR priority: normal severity: normal status: open title: Clarify handling of infinity and nan in random.choices type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41773] Clarify handling of infinity and nan in random.choices
Change by Ram Rachum : -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue41773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41475] __future__.annotations set to become default in Python 4.0?
Ram Rachum added the comment: Thanks for linking that, YoStealth. Unless I'm missing anything, it looks like there's agreement that the right answer is 3.10, and my PR fixes a spot which was omitted in the PR from the previous issues. Agreed? -- ___ Python tracker <https://bugs.python.org/issue41475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41475] __future__.annotations set to become default in Python 4.0?
Ram Rachum added the comment: If you'd like me to patch that too, let me know. Also, I'll need a decision on whether it should be on a separate PR and if so, to which versions it should be backported. -- ___ Python tracker <https://bugs.python.org/issue41475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41475] Fix mistake in "What's new in Python 3.7"
Change by Ram Rachum : -- type: -> crash versions: +Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41475] Fix mistake in "What's new in Python 3.7"
Change by Ram Rachum : -- keywords: +patch pull_requests: +20878 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21733 ___ Python tracker <https://bugs.python.org/issue41475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41475] Fix mistake in "What's new in Python 3.7"
New submission from Ram Rachum : Writing the patch now. -- assignee: docs@python components: Documentation messages: 374814 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: Fix mistake in "What's new in Python 3.7" versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue41475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41457] Implement random.shuffled
Change by Ram Rachum : -- keywords: +patch pull_requests: +20848 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21704 ___ Python tracker <https://bugs.python.org/issue41457> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41457] Implement random.shuffled
New submission from Ram Rachum : Writing the patch now. Thread: https://mail.python.org/archives/list/python-id...@python.org/thread/OHLXVKIBMNSQO6BCFK6LEHSYNXDB6OQJ/ -- components: Library (Lib) messages: 374683 nosy: cool-RR priority: normal severity: normal status: open title: Implement random.shuffled type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41457> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Change by Ram Rachum : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40636] Provide a strict form of zip (PEP-618) requiring same length inputs
Ram Rachum added the comment: I'll fix that typo. -- ___ Python tracker <https://bugs.python.org/issue40636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41065] Use zip-strict in zoneinfo
Change by Ram Rachum : -- keywords: +patch pull_requests: +20202 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21031 ___ Python tracker <https://bugs.python.org/issue41065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41065] Use zip-strict in zoneinfo
New submission from Ram Rachum : Writing the PR now. -- components: Library (Lib) messages: 371997 nosy: brandtbucher, cool-RR priority: normal severity: normal status: open title: Use zip-strict in zoneinfo type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40636] Provide a strict form of zip (PEP-618) requiring same length inputs
Change by Ram Rachum : -- pull_requests: +20140 pull_request: https://github.com/python/cpython/pull/20961 ___ Python tracker <https://bugs.python.org/issue40636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40976] Clarify motivation for `chain.from_iterable`
Change by Ram Rachum : -- keywords: +patch pull_requests: +20060 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20871 ___ Python tracker <https://bugs.python.org/issue40976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40976] Clarify motivation for `chain.from_iterable`
Change by Ram Rachum : -- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Clarify motivation for `chain.from_iterable` type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40876] Clarify error message in csv module
Change by Ram Rachum : -- keywords: +patch pull_requests: +19873 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20653 ___ Python tracker <https://bugs.python.org/issue40876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40876] Clarify error message in csv module
New submission from Ram Rachum : I was working with the csv module, and I vaguely remembered that you should open files in binary mode. So I did. Then I saw this error message: _csv.Error: iterator should return strings, not bytes (did you open the file in text mode?) I read the end and thought "I didn't open it in text mode, what does it want from me?!" It took a careful reading to figure out that I was *supposed to* open it in text mode. I'm going to open a PR to slightly change the text to: _csv.Error: iterator should return strings, not bytes (the file should be opened in text mode) -- components: Library (Lib) messages: 370769 nosy: cool-RR priority: normal severity: normal status: open title: Clarify error message in csv module type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40875] Implement __repr__ for classes in csv module
New submission from Ram Rachum : Why see this: When you can see this: It could show columns=? if they weren't read yet. Any other info would be good too. This applies to all classes in the csv module. -- components: Library (Lib) messages: 370768 nosy: cool-RR priority: normal severity: normal status: open title: Implement __repr__ for classes in csv module type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40833] Clarify docstring of Path.rename
Change by Ram Rachum : -- keywords: +patch pull_requests: +19797 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20554 ___ Python tracker <https://bugs.python.org/issue40833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40833] Clarify docstring of Path.rename
New submission from Ram Rachum : Writing the PR now. -- assignee: docs@python components: Documentation messages: 370459 nosy: brandtbucher, cool-RR, docs@python priority: normal severity: normal status: open title: Clarify docstring of Path.rename type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22250] unittest lowercase methods
Ram Rachum added the comment: I see it's been 6 years since the last comment here. I think it's important to revisit these kind of decisions once in a while. Maybe now the time is ripe for a change? We could do it backward compatibility with a long deprecation schedule. Ezio: You said this was proposed and rejected. Can you link to the discussion? I couldn't find it. -- nosy: +cool-RR ___ Python tracker <https://bugs.python.org/issue22250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40753] Remove Python 2 compatibility code from pathlib
Ram Rachum added the comment: Brett: Oh well, I understand. Looking at the devguide, I can't find where this is written. I'm interested in seeing how it's phrased, because I do think that tiny, incremental changes are important. I would want to know why, for example, my change https://github.com/python/cpython/pull/17929 was accepted and this one wasn't. Or maybe there isn't a clear cut rule, and it's somewhat random? -- ___ Python tracker <https://bugs.python.org/issue40753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20002] Cleanup and microoptimize pathlib
Ram Rachum added the comment: Antoine: Serhiy linked me to this issue when I opened #40753 . Do you think that this patch by Serhiy could now be merged? -- nosy: +cool-RR ___ Python tracker <https://bugs.python.org/issue20002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40752] Implement PurePath.__len__
Ram Rachum added the comment: I understand your argument. I think it relies on your earlier statement: "The fact the the path is stored as a string is an implementation detail." This statement reminds me of the term "architecture astronaut". Pathlib builds a cool architecture over the concept of paths. But landing back in reality, all paths are strings, aren't they? On any OS, even looking at esoteric things such as UNC paths on Windows, they're all eventually strings and are treated by most tools as just strings. If I'm missing any edge cases, let me know. But otherwise I think it's okay to look at `Path` as a string with bells and whistles. -- ___ Python tracker <https://bugs.python.org/issue40752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40753] Remove Python 2 compatibility code from pathlib
Change by Ram Rachum : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue40753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40752] Implement PurePath.__len__
Ram Rachum added the comment: Remi: Your use case is taken care of by `len(path.parts)`. Serhiy: "If it is not iterable, the length does not make sense." I'm not sure this is a rule. I do see that the `collections.abc.Sized` class does not require an `__iter__` method to be defined. -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue40752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40753] Remove Python 2 compatibility code from pathlib
Ram Rachum added the comment: "We usually do not accept such pure cosmetic changes." Is this an axiom or is the reasoning written down somewhere? I'd think we all like to remove cruft that's no longer necessary. -- ___ Python tracker <https://bugs.python.org/issue40753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40753] Remove Python 2 compatibility code from pathlib
Change by Ram Rachum : -- keywords: +patch pull_requests: +19612 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20349 ___ Python tracker <https://bugs.python.org/issue40753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40753] Remove Python 2 compatibility code from pathlib
New submission from Ram Rachum : No need to inherit from object. I'm writing the patch now. -- components: Library (Lib) messages: 369770 nosy: cool-RR priority: normal severity: normal status: open title: Remove Python 2 compatibility code from pathlib type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40752] Implement PurePath.__len__
Ram Rachum added the comment: Just return len(str(path)). I put the use case on the PR on GitHub. -- ___ Python tracker <https://bugs.python.org/issue40752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40752] Implement PurePath.__len__
Change by Ram Rachum : -- keywords: +patch pull_requests: +19611 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20348 ___ Python tracker <https://bugs.python.org/issue40752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40752] Implement PurePath.__len__
New submission from Ram Rachum : I'm writing the patch now. -- components: Library (Lib) messages: 369767 nosy: cool-RR priority: normal severity: normal status: open title: Implement PurePath.__len__ type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40678] Full list of Python lexical rules
Ram Rachum added the comment: I understand, thank you. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40678] Full list of Python lexical rules
Ram Rachum added the comment: Hmm, I feel this isn't right, because I still feel like there should be one place where one can see the full Python syntax specification, lexing and parsing and all. But I'm underqualified to argue because I don't understand the details. Is someone more knowledgeable interested in arguing this point? -- ___ Python tracker <https://bugs.python.org/issue40678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40678] Full list of Python lexical rules
New submission from Ram Rachum : I'm a noob on parsing, learning about it, so it's possible I've made a mistake somewhere. I know there's this page: https://docs.python.org/3/reference/grammar.html Which is a full listing of Python's grammar. However, looking at this page: https://docs.python.org/3/reference/lexical_analysis.html I see rules that aren't written there, like longstringitem. I'm guessing that's because these are lexing rules, while the former was a list of parsing rules? If that's the case, shouldn't there also be a full, authoritative list of Python's lexical rules? Possibly alongside the parsing rules? -- assignee: docs@python components: Documentation messages: 369320 nosy: cool-RR, docs@python, georg.brandl, gvanrossum priority: normal severity: normal status: open title: Full list of Python lexical rules type: enhancement versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40353] Add an optional "strict" check to zip
Ram Rachum added the comment: Here are the tests I made: https://github.com/cool-RR/cpython/commit/766409748a107f290997b0cfab5aa19d0c2888e5 -- ___ Python tracker <https://bugs.python.org/issue40353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
Ram Rachum added the comment: I updated my PR to match. -- ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
Ram Rachum added the comment: I'm gonna look past the rudeness, and I'll just say that if I was tripped up by this, after 11 years of working with Python and the re module, then people in a beginner or intermediate level could be tripped up by this as well. Here's another, simpler suggestion for preventing confusion. Replace this line in the docstring: (?aiLmsux) Set the A, I, L, M, S, U, or X flag for the RE (see below). With this line: (?aiLmsux) Apply flags to the entire pattern, allowing small tweaks to the matching logic (details below). There's no reason to mention the letters there because they're already mentioned. And it's helpful to add a short explanation, like the other entries in that list. -- ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
Ram Rachum added the comment: Oops, my mistake. Any other idea how to solve this discrepancy? -- ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
Ram Rachum added the comment: Well, these aren't the textbook case of a constant, since they're enums, and not defined in the global namespace. -- ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
Ram Rachum added the comment: As you can see I left the old uppercase enums defined, to avoid breaking backward compatibility. We could make them trigger a DeprecationWarning. -- ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
Change by Ram Rachum : -- keywords: +patch pull_requests: +18434 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19078 ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40016] Clarify flag case in `re` module
New submission from Ram Rachum : Today I was tripped up by an inconsistency in the `re` docstring. I wanted to use DOTALL as a flag inside my regex, rather than as an argument to the `compile` function. Here are two lines from the docstring: (?aiLmsux) Set the A, I, L, M, S, U, or X flag for the RE (see below). ... S DOTALL "." matches any character at all, including the newline. The DOTALL flag appears as an uppercase S in 2 places, and as a lowercase s in one place. This is confusing, and I initially tried using the uppercase S only to get an error. I'm attaching a PR to this ticket. -- components: Library (Lib) messages: 364617 nosy: cool-RR priority: normal severity: normal status: open title: Clarify flag case in `re` module type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40006] enum: Add documentation for _create_pseudo_member_ and composite members
New submission from Ram Rachum : Looking at the enum source code, there's a method `_create_pseudo_member_` that's used in a bunch of places. Its docstring says "Create a composite member iff value contains only members", which would have been useful if I had any idea what "composite member" meant. It would be good if the documentation for the enum module would include more information about these two concepts. -- assignee: docs@python components: Documentation messages: 364561 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: enum: Add documentation for _create_pseudo_member_ and composite members type: enhancement versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39717] Fix exception causes in tarfile module
Ram Rachum added the comment: I understand. I've closed my PR and I'll let someone else implement this ticket-- I don't want to be the reason that someone didn't get the information they wanted in an error report. Thanks anyway for your time. -- ___ Python tracker <https://bugs.python.org/issue39717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39717] Fix exception causes in tarfile module
Ram Rachum added the comment: Ethan, got a verdict? -- ___ Python tracker <https://bugs.python.org/issue39717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39717] Fix exception causes in tarfile module
Ram Rachum added the comment: Ethan, did we successfully convince you not to use `from None`? -- ___ Python tracker <https://bugs.python.org/issue39717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39717] Fix exception causes in tarfile module
Ram Rachum added the comment: I'm also strongly against using `from None`. When I'm debugging, I'm like a man who got lost in the desert and is about to die of thirst. Any possible insight into what happened is like an oasis, even if there are just a few drops of water there. Also, some tools like Django and Sentry show you all the local variables for your stacktraces, which is a godsend. These often have important information that sheds light on what went wrong, and if you remove the traceback they'll be gone. -- ___ Python tracker <https://bugs.python.org/issue39717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39717] Fix exception causes in tarfile module
Ram Rachum added the comment: > What do you think it is necessary to switch from implicit chaining to > explicit chaining? I didn't say it's necessary, but I think it's beneficial. I find that message between exceptions useful when I'm debugging and I'd like to keep it accurate in as many places as I can. I think that the more accurate it is, the more people will learn to trust that it has meaning and understand it. > If anyone is currently relying on __context__ vs __cause__, this patch will > break their code. I think that the standard you're setting for backward compatibility is unreasonably high. The only code I can think of that inspects `__context__` and `__cause__` is code that formats exceptions to be shown to the user, such as Django's debug page, Wing IDE's Exceptions pane, whatever's going on in PyCharm etc. That kind of code is responsible for checking for both `__context__` and `__cause__` and showing the correct message. If you've seen code outside of the category above that uses `__context__`, I'd be curious to see it. Fortunately, this point is moot since using `raise foo from bar` sets the `__context__ = __cause__ = bar`, so the `__context__` will not be changed. -- ___ Python tracker <https://bugs.python.org/issue39717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39715] Implement __repr__ methods for AST classes
Ram Rachum added the comment: I understand that we have to be really careful in including information that could have unlimited size. But I think we have lots of information that isn't that way. For example, for ClassDef and FunctionDef objects, we could include the name. For Assign, we could include the lhs. For Import, we could include the module name, etc. And for all objects, we could include the number of descendants that they have, so people could more easily understand which are tiny and which are huge. -- ___ Python tracker <https://bugs.python.org/issue39715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39717] Fix exception causes in tarfile module
Change by Ram Rachum : -- components: Library (Lib) nosy: cool-RR priority: normal pull_requests: 17962 severity: normal status: open title: Fix exception causes in tarfile module type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39715] Implement __repr__ methods for AST classes
New submission from Ram Rachum : I was playing with the `ast` library today, and it's frustrating to see objects like these: [<_ast.Import object at 0x033FB048>, <_ast.Import object at 0x033FB0F0>, <_ast.ImportFrom object at 0x033FB160>, <_ast.Import object at 0x033FB1D0>, <_ast.Assign object at 0x033FB240>, <_ast.If object at 0x033FB630>] A little bit more information about each object in the `__repr__` would make this module much easier to work with. -- components: Library (Lib) messages: 362419 nosy: cool-RR priority: normal severity: normal status: open title: Implement __repr__ methods for AST classes type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Ram Rachum added the comment: Hi guys, Can we please have a decision on whether we want to move forward with this issue or not? I have a patch in the PR, and I'll be happy to continue working on it, or close this issue if that's the decision. Thanks, Ram. -- ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
Ram Rachum added the comment: Hey Victor, adding you here. This ticket is a continuation of the thread on the Python security mailing list. I see that there isn't a consensus here for changing from \d to [0-9]. Can you make a decision on whether to go ahead with this issue or not? Otherwise we can close it, and the corresponding PR. -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
Ram Rachum added the comment: My approach is that any input that's unexpected by the developer but accepted by the program could cause either a bug or a security problem, and should be rejected by the program. I don't have a specific example for this case. If you think I need to come up with a specific example where this can be misused, or show that there are no computers in the world that willingly use the version number with non-Ascii digits, I'll let this issue go. -- ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Ram Rachum added the comment: Okay, since it seems like I'm the only one who wants this change, I'll let it go. Thanks for your input. -- ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Ram Rachum added the comment: > To me, this seems like a pretty thin justification for calling this a > security vulnerability. I know that lots of exploits were made because of bugs in Python's URL parsing, and security releases of Python were made because of that. It's possible that similar exploits could be done for bugs in parsing datetimes. It's different, and it's a thin justification, I agree, so if it's treated as a non-security bug, I'm okay with that. > ISO 8601 specifies dozens of ways to represent the same datetime Yes, but not within the same format. If someone were to choose the format '2014-04-10T24:00:00', they would have a reasonable expectation that there is only one unique string that corresponds with that datetime. > As far as the inconsistency, I think that's an argument for being less > strict, not more, and allowing non-ASCII digits in more places not just the > first. Why shouldn't (let's say) a Bengali user specify the day of the month > using Bengali digits? That's an interesting direction. It might be a good thing to allow users in different locales to specify datetime with their native digits. But, if we were to go in that direction, we would have to: 1. Define that use case more rigorously, consider whether it has any effects we need to consider, like clashes with how the local culture expresses dates. Maybe we accept the year 2020 in Elbonian digits, but the Elbonian people count their years from the birth of Saint Elbon, and for them the year 2020 in Elbonian digits means -1553 BC for us? 2. Enable it in other fields except year. 3. Add tests for it. Since we're not going to do that ever, I don't think there's a point in leaving a 10% implementation of non-Ascii datetime parsing. -- ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
Change by Ram Rachum : -- keywords: +patch pull_requests: +17337 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17931 ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
Change by Ram Rachum : -- pull_requests: +17336 pull_request: https://github.com/python/cpython/pull/17931 ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39280] Don't allow datetime parsing to accept non-Ascii digits
New submission from Ram Rachum : I've been doing some research into the use of `\d` in regular expressions in CPython, and any security vulnerabilities that might happen as a result of the fact that it accepts non-Ascii digits like ٢ and ５. In most places in the CPython codebase, the `re.ASCII` flag is used for such cases, thus ensuring the `re` module prohibits these non-Ascii digits. Personally, my preference is to never use `\d` and always use `[0-9]`. I think that it's rule that's more easy to enforce and less likely to result in a slipup, but that's a matter of personal taste. I found a few places where we don't use the `re.ASCII` flag and we do accept non-Ascii digits. The first and less interesting place is platform.py, where we define patterns used for detecting versions of PyPy and IronPython. I don't know how anyone would exploit that, but personally I'd change that to a [0-9] just to be safe. I've opened bpo-39279 for that. The more sensitive place is the `datetime` module. Happily, the `datetime.datetime.fromisoformat` function rejects non-Ascii digits. But the `datetime.datetime.strptime` function does not: from datetime import datetime time_format = '%Y-%m-%d' parse = lambda s: datetime.strptime(s, time_format) x = '٢019-12-22' y = '2019-12-22' assert x != y assert parse(x) == parse(y) print(parse(x)) # Output: 2019-12-22 00:00:00 If user code were to check for uniqueness of a datetime by comparing it as a string, this is where an attacker could fool this logic, by using a non-Ascii digit. Two more interesting points about this: 1. If you'd try the same trick, but you'd insert ٢ in the day section instead of the year section, Python would reject that. So we definitely have inconsistent behavior. 2. In the documentation for `strptime`, we're referencing the 1989 C standard. Since the first version of Unicode was published in 1991, it's reasonable not to expect the standard to support digits that were introduced in Unicode. If you'd scroll down in that documentation, you'll see that we also implement the less-known ISO 8601 standard, where `%G-%V-%u` represents a year, week number, and day of week. The `%G` is vulnerable: from datetime import datetime time_format = '%G-%V-%u' parse = lambda s: datetime.strptime(s, time_format) x = '٢019-53-4' y = '2019-53-4' assert x != y assert parse(x) == parse(y) print(parse(x)) # Output: 2020-01-02 00:00:00 I looked at the ISO 8601:2004 document, and under the "Fundamental principles" chapter, it says: This International Standard gives a set of rules for the representation of time points time intervals recurring time intervals. Both accurate and approximate representations can be identified by means of unique and unambiguous expressions specifying the relevant dates, times of day and durations. Note the "unique and unambiguous". By accepting non-Ascii digits, we're breaking the uniqueness requirement of ISO 8601. -- components: Library (Lib) messages: 359695 nosy: cool-RR priority: normal severity: normal status: open title: Don't allow datetime parsing to accept non-Ascii digits type: security versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
Change by Ram Rachum : -- keywords: +patch pull_requests: +17335 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17928 ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39279] Don't allow non-Ascii digits in platform.py
New submission from Ram Rachum : The platform.py module takes non-Ascii digits in regexes in places it shouldn't. e.g. digits like ٢ and ５ and accepted, when only the Ascii digits between 0-9 should be accepted. -- components: Library (Lib) messages: 359694 nosy: cool-RR priority: normal severity: normal status: open title: Don't allow non-Ascii digits in platform.py type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39212] Show qualified function name when giving arguments error
Ram Rachum added the comment: > But I *did* get that text. I'm asking how you got the *different* text > which you gave in your initial request. Oh, right. Looking back, turns out Wing IDE did that for me. Didn't notice, sorry. > So in my opinion, and I recognise that you may disagree, this is only of > benefit in a minority of cases. For the majority of cases, it will only > be additional noise in the message that adds nothing that wasn't already > obvious from the source line. I understand your perspective. One correction though regarding adding noise to the error. You gave this example: builtins.TypeError: package.some_module.MyClass.__init__ takes 1 positional argument but 2 were given While actually it'll be: TypeError: MyClass.__init__ takes 1 positional argument but 2 were given Since __qualname__ only includes the class, not its module. So it's quite a bit shorter. -- ___ Python tracker <https://bugs.python.org/issue39212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39212] Show qualified function name when giving arguments error
Ram Rachum added the comment: Here is a short IPython session: In [1]: class Foo: ...: def __init__(self, x): ...: pass ...: In [2]: Foo(7, 8) --- TypeError Traceback (most recent call last) in > 1 Foo(7, 8) TypeError: __init__() takes 2 positional arguments but 3 were given As you can see, it's pretty simple to get this exception text, so I'm not sure why you didn't get that text. This is on Python 3.8.1. Regarding you saying it's more annoying than useful: Especially for methods such as `__init__`, it's often difficult to understand which class is being instantiated, especially in a complex codebase. It happened to me last week at work, and even with a debugger and being an experienced Python developer, it took me a few minutes to figure out which `__init__` method was being called. -- ___ Python tracker <https://bugs.python.org/issue39212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39212] Show qualified function name when giving arguments error
New submission from Ram Rachum : I recently got this familiar error: builtins.TypeError: __init__() takes 1 positional argument but 2 were given It was annoying that I didn't know which `__init__` method was under discussion. I wish that Python used the `__qualname__` of the function to show this error message (and maybe others?) so it'll show like this: builtins.TypeError: FooBar.__init__() takes 1 positional argument but 2 were given If I'm not mistaken, the implementation of this error is in getargs.c in the function vgetargs1_impl. -- components: Interpreter Core messages: 359302 nosy: cool-RR priority: normal severity: normal status: open title: Show qualified function name when giving arguments error type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38724] Implement subprocess.Popen.__repr__
Change by Ram Rachum : -- nosy: +taleinat ___ Python tracker <https://bugs.python.org/issue38724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38724] Implement subprocess.Popen.__repr__
New submission from Ram Rachum : I was working with a Popen object recently in the shell and it was annoying to see the `` display. It would be nice to get some kind of minimal detail about the Popen, for example its args and return code, if finished. -- components: Library (Lib) messages: 356149 nosy: cool-RR, pitrou priority: normal severity: normal status: open title: Implement subprocess.Popen.__repr__ type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38422] Clarify docstrings of pathlib suffix(es)
Change by Ram Rachum : -- keywords: +patch pull_requests: +16264 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16679 ___ Python tracker <https://bugs.python.org/issue38422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38422] Clarify docstrings of pathlib suffix(es)
New submission from Ram Rachum : I'm writing a PR for this right now. -- components: Library (Lib) messages: 354279 nosy: cool-RR priority: normal severity: normal status: open title: Clarify docstrings of pathlib suffix(es) versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs.
Ram Rachum added the comment: Serhiy: I confirmed what you're saying and corrected the documentation. Could you please review? -- ___ Python tracker <https://bugs.python.org/issue37937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs.
Change by Ram Rachum : -- assignee: docs@python components: Documentation nosy: cool-RR, docs@python priority: normal pull_requests: 15149 severity: normal status: open title: Mention ``frame.f_trace`` in :func:`sys.settrace` docs. type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22377] %Z in strptime doesn't match EST and others
Change by Ram Rachum : -- nosy: -cool-RR ___ Python tracker <https://bugs.python.org/issue22377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
Ram Rachum added the comment: thautwarm, your suggestions look good. I'm not sure why you used `entire_contents`, do you want to show the entire content there? Because I saw that the sample you used had truncation. It might be unsafe to show the entire mmap, because it could be huge. I'd truncate in some way or other. (Either show just the beginning, or just the beginning and the end.) -- ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
Ram Rachum added the comment: There are a few ways we can go with this, depending on how verbose we want to be and how willing we are to make calls to the data. Here are a few pieces of information we could expose: - Length - Whether it's a file or anonymous memory - The entire contents - The clipped contents - Whether it's opened or closed - The access type So here's an example: And another: I don't know whether we're able to include the file name on there, that would be nice. -- ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34953] Implement `mmap.mmap.__repr__`
Change by Ram Rachum : -- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Implement `mmap.mmap.__repr__` type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
