[issue38668] Update os.path documentation regarding recommended types
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 2.0 -> 3.0 pull_requests: +30304 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32232 ___ Python tracker <https://bugs.python.org/issue38668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32658] Metacharacter (\) documentation suggestion
Jack DeVries added the comment: Did you run ``make venv`` to setup your virtual environment? Sphynx themes are usually pip dependencies, so if you're getting a "missing theme" error, it sounds like your virtual environment is not setup right. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45799] Fix confusing wording in Doc/library/__main__.rst
Change by Jack DeVries : -- keywords: +patch pull_requests: +27795 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29546 ___ Python tracker <https://bugs.python.org/issue45799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45799] Fix confusing wording in Doc/library/__main__.rst
New submission from Jack DeVries : I was reading this bit last night and thought it was a typo. In the light of day, I realized it wasn't *technically* a typo, but definitely confusing wording. This PR fixes the confusing sentence. -- assignee: docs@python components: Documentation messages: 406279 nosy: docs@python, jack__d priority: normal severity: normal status: open title: Fix confusing wording in Doc/library/__main__.rst type: enhancement versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue45799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Jack DeVries added the comment: Hey all, I'm putting a ping on this issue. I think my fix is ready to merge, see GH-27434. Thanks for all the feedback on the PR so far! -- ___ Python tracker <https://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39452] Improve the __main__ module documentation
Jack DeVries added the comment: > Your docs seem to promote the second, whereas I've usually preferred the > former. Was this a considered choice on your part? First and foremost, stupid GitHub is not letting the permalink load for some reason, but yes; this was discussed in the conversation with @graingert on June 29th – it was his suggestion. Later, @pradyunsg from PyPa added some suggestions about how the document described console script entrypoints, and the documentation around this issue changed a bit again. As far as my perspective, I also never personally use the sys.exit idiom myself. After all, an exception is going to cause a non-zero exit code, and a traceback is always going to have a lot more value than an exit code. I was, however, surprised to learn how pip treats console script entry points in the course of working on this document. Specifically, it generates an executable script that does wrap the function in sys.exit.I definitely think that the way the document communicates this fact while teaching the idiom is a good thing, so I think that whole "Idiomatic Usage" section is good. I do think we can tweak the document slightly to make it less prescriptive, though, because in reality a lot of people _don't_ use this idiom, so presenting it as a de-facto standard is misleading. Plus, it's not Pythonic to dole out prescriptive boilerplate. I attached a diff that steers in that direction. What do you all think? It is a pretty slight change, but I think it better strikes a balance. -- Added file: https://bugs.python.org/file50249/less_prescriptive.diff ___ Python tracker <https://bugs.python.org/issue39452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24632] Improve documentation about __main__.py
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 11.0 -> 12.0 pull_requests: +26357 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/26883 ___ Python tracker <https://bugs.python.org/issue24632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17359] Mention "__main__.py" explicitly in command line docs
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 8.0 -> 9.0 pull_requests: +26356 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26883 ___ Python tracker <https://bugs.python.org/issue17359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: @terry.reedy ok, a PR to restore the docs with the new link is open. -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Change by Jack DeVries : -- pull_requests: +26283 pull_request: https://github.com/python/cpython/pull/27818 ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: All right, consider the needle in the haystack officially found. This page has the same content as the missing page: https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html Thank you @buhtz for opening an issue with Mozilla; they are eventually going to deploy a redirect to the link above from the old link: https://github.com/mdn/content/issues/8036 So, we could go ahead and insert the link above which contains the same content as before. Or, we can keep the call open for a new document. What does everyone think? -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39039] zlib.error with tarfile.open
Jack DeVries added the comment: @jvoisin I am able to reproduce the problem when I download your script, but I am having a hard time reproducing it by passing corrupt archives to `tarfile.open`. How exactly was this file corrupted? I am trying to figure out if there are any similar implementation leaks / poor error messages in similar scenarios so I can do my best to patch them all. You can see the reproduction scripts I am using here to get a better idea of what I have been trying. Be forewarned, they are pretty gnarly! https://gist.github.com/jdevries3133/acbb5ba2a19093d3bcc214733ef85e5a -- ___ Python tracker <https://bugs.python.org/issue39039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: I am pretty sure that Mozilla moved to a new content management system and they've been refreshing a lot of content on their site. I would assume that any lingering presence of this article is just growing pains and it'll all be removed in due time. I might be wrong, though. I suppose we could submit a bug report to Mozilla to find out if we can ever figure out how to write a bug report again, that is! On Mon, Aug 16, 2021 at 10:43:16PM +, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > https://support.mozilla.org/en-US/kb/contributors-guide-writing-good-bug > still has a link to > https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines > but the fact that they moved the latter to > > https://github.com/mdn/archived-content/blob/main/files/en-us/mozilla/qa/bug_writing_guidelines/index.html > does not think highly of it now. The github archived document says last > modified in 2013. The Wayback copy has an additional box saying last > modified a year ago by 'MDM contributors'. I don't know what that means, > even after clicking the link. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue44830> > ___ -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: > If Jack wants to pick this up, I'd merge it. I might be interested but I'm not sure if I will have the time. I'm not "calling dibs" if anyone else wants to go ahead with this solution. -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: I agree that linking to the wayback machine is clunky. I just sent a message out to the python-ideas mailing list to solicit more suggestions. The discourse thread didn't get much response. I guess that at some point, if there is no consensus, it wouldn't be a bad idea to ask the python-dev mailing list. I would think that core devs would be the most opinionated when it comes to how people should write bug reports! I don't want to ping that mailing list unnecessarily, though. -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44921] dict subclassing is slow
Jack DeVries added the comment: There was a thorough discussion about the concerns associated with supporting dict subclasses in general here: bpo-32615 If I understand correctly, allowing dict subclasses to inherit __contains__ and __getitem__ will be a step towards supporting dict subclasses in a more broad context, like being able to use them as namespaces passed to exec. Ultimately, dictionaries are at the very heart of Cpython's implementation. I think it is reasonable to say that it is not possible or reasonable to support users in creating custom dict implantation with their own behavior. There is no good real world use case for it (please tell me if anyone has one), and it opens the door to enormous unnecessary complexity. Also related to dict subclassing: bpo-15099 bpo-27561 Marco, I hope that the discussions I've linked will at least make it clear why cpython behaves this way, and what the concerns are especially around supporting user subclasses of dict. I noticed you tagged this bpo as performance, but there are significant negative performance implications around dict subclasses that you'll see in past discussions. With this additional context in mind, what changes do you propose? -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39039] zlib.error with tarfile.open
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 3.0 -> 4.0 pull_requests: +26242 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27766 ___ Python tracker <https://bugs.python.org/issue39039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42649] RecursionError when parsing unwieldy expression (regression from 2.7 -> 3.x)
Jack DeVries added the comment: edit; typo: **This document is the **closest** I can find -- ___ Python tracker <https://bugs.python.org/issue42649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42649] RecursionError when parsing unwieldy expression (regression from 2.7 -> 3.x)
Jack DeVries added the comment: I spent some time experimenting with making the expression bigger and the recursion limit lower in python2. It seems like in python2, the depth that the compiler will recurse is unrelated to sys.recursionlimit. Then, I lowered resource limits on stack and heap by ~1000x and increased the size of the expression by 10,000x, which caused a segmentation fault. Not only that, but the interpreter won't even respond to KeyboardInterrupt while it is doing the compiling. I believe that the recursion depth of the 2.x compiler is simply unbound, which seems like a bug to me. As I tinkered with these things, I build out a reproduction script, which I've attached. I think that documenting this change is more pragmatic than thinking about "fixing" it (not sure it can truly be fixed, as that would mean re-incorporating a bug). I don't know where such a note would belong, though. This document is the closed I can find, but it's too high-level for a detail like this to belong:: https://docs.python.org/3/howto/pyporting.html -- nosy: +jack__d Added file: https://bugs.python.org/file50215/repro.py ___ Python tracker <https://bugs.python.org/issue42649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44902] [Doc] Changing 'Mac OS X'/'OS X' to 'macOS'
Jack DeVries added the comment: Oh yeah, sorry, it looks like this can be closed as duplicate. -- ___ Python tracker <https://bugs.python.org/issue44902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44902] [Doc] Changing 'Mac OS X'/'OS X' to 'macOS'
Jack DeVries added the comment: Ok, that was no help... I'll just upload the diff. -- keywords: +patch Added file: https://bugs.python.org/file50211/os_x_to_macos_fix.diff ___ Python tracker <https://bugs.python.org/issue44902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44902] [Doc] Changing 'Mac OS X'/'OS X' to 'macOS'
Jack DeVries added the comment: I've done it. See the changes here: https://github.com/python/cpython/compare/main...jdevries3133:bpo-44902-macOS I'll hold off on a PR pending some feedback on whether this change is desirable. Also, I did not make changes to whatsnew documents, because they were presumably referring to OS X accurately at the time they were written. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44902] [Doc] Changing 'Mac OS X'/'OS X' to 'macOS'
Jack DeVries added the comment: oops, the link was mutilated... maybe this will help:: ``<https://github.com/python/cpython/compare/main...jdevries3133:bpo-44902-macOS>`` -- ___ Python tracker <https://bugs.python.org/issue44902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44877] Python > 3.7 build fails with IBM XL compiler
Jack DeVries added the comment: Woah, oops, nevermind! I was confusing this with a different bpo in my head. Sorry for the noise! -- ___ Python tracker <https://bugs.python.org/issue44877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44877] Python > 3.7 build fails with IBM XL compiler
Jack DeVries added the comment: I'm sure you are aware of this, but also note that the issue could be in pandas or ibm-db, which include C extensions. I'm pretty sure those are the only two dependencies you listed there that have C dependencies. -- ___ Python tracker <https://bugs.python.org/issue44877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44877] Python > 3.7 build fails with IBM XL compiler
Jack DeVries added the comment: There is a related failure message in the file name ".9" in the tarball (line 175): ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Fatal Python error: _PyMem_DebugMalloc: Python memory allocator called without holding the GIL Python runtime state: preinitialized Current thread 0x20045fe0 (most recent call first): /bin/sh: line 5: 122035 Aborted (core dumped) ./python -E -S -m sysconfig --generate-posix-vars generate-posix-vars failed -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39452] Improve the __main__ module documentation
Jack DeVries added the comment: Hi All, I'm pinging everyone here on the bpo because my GitHub PR has been through a lot of revision and review. Maybe it's close to being ready to merge (I hope)! Feel free to take a look if you are interested: https://github.com/python/cpython/pull/26883 -- ___ Python tracker <https://bugs.python.org/issue39452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: I'm pretty much a novice, Senthil, so I don't know how much a review from me is worth but removing the broken link seems best! -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: @mark.dickinson, Steven D'Aprano suggested just linking to the wayback machine on discuss.python.org. What do you think of that? https://discuss.python.org/t/alternate-article-for-how-to-wite-good-bug-report/10040/2?u=jdevries3133 -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: I created a discourse thread for people to propose alternatives:: https://discuss.python.org/t/alternate-article-for-how-to-wite-good-bug-report/10040 It's be a good idea to merge @orsenthil's PR which just removes the broken link right away. Then, we can keep this bpo open until we have consensus on an alternative. -- ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33140] shutil.chown should not be defined in Windows
Jack DeVries added the comment: Yes, I definitely get that, but that's what the deprecation cycle is for. Certainly hold off on a PR until we see what @steve.dower thinks. I personally feel that having a function that can be introspected with ``dir`` but which should not be used is confusing, and rightfully pointed out as a wrinkle in the API. -- ___ Python tracker <https://bugs.python.org/issue33140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33140] shutil.chown should not be defined in Windows
Jack DeVries added the comment: I'm pretty sure the 3.11 dev cycle started since this conversation, right? Can we introduce the deprecation warning now? Maybe something like what is in the attached diff? @andrei.avk, if it turns out that the time has come, you can go ahead and take the PR if you wish! -- nosy: +jack__d Added file: https://bugs.python.org/file50203/roughly_add_depr_warning.diff ___ Python tracker <https://bugs.python.org/issue33140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44679] unittest.mock.sentinel documentation typo
Jack DeVries added the comment: @gaydayav I agree. -- ___ Python tracker <https://bugs.python.org/issue44679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44679] unittest.mock.sentinel documentation typo
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 2.0 -> 3.0 pull_requests: +26112 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27618 ___ Python tracker <https://bugs.python.org/issue44679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44697] Memory leak when asyncio.open_connection raise
Change by Jack DeVries : -- pull_requests: -26111 ___ Python tracker <https://bugs.python.org/issue44697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44697] Memory leak when asyncio.open_connection raise
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 6.0 -> 7.0 pull_requests: +26111 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27617 ___ Python tracker <https://bugs.python.org/issue44697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44830] Broken Mozilla devguide link in "Dealing with Bugs" doc section
Jack DeVries added the comment: For reference, it looks like Wayback Machine has a snapshot of the old article for reference: https://web.archive.org/web/20210613191914/https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines @mark.dickinson, do you feel like that new article is a good drop-in replacement for the old one? It is a bit different. I can open up a PR if so! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41946] Add concrete examples to os.path documentation
Jack DeVries added the comment: > Some examples were added since this issue was created See bpo-35183 -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue41946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44819] assertSequenceEqual does not use _getAssertEqualityFunc
Jack DeVries added the comment: Brian, can you be more specific about what problem is caused by the fact that assertSequenceEqual does not use _getAssertEqualityFunc? Also, I'm not sure what your example is trying to demonstrate. Can you provide a minimal example that shows the problem, but also defines what ``MyObject``, etc. are? Let me know if I'm missing something. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"
Jack DeVries added the comment: Actually, I tested out that idea (https://github.com/python/cpython/compare/main...jdevries3133:bpo-44756-doc-make), and I don't think its as nice of a solution. I think it is valuable for new contributors to be able to type "make html" and have it work. Look at how much the change simplifies the README for new contributors to setup their documentation build toolchain. Then, look at how many ``docs@python`` open issues there are. We need documentation contributors, and there is value in simplifying the process for them. Additionally, this is the extent of the "downloading code from the internet and running it" that occurs:: pip install -U pip setuptools pip install sphynx blurb python-docs-theme If running that is ever unsafe, we have big problems! -- ___ Python tracker <https://bugs.python.org/issue44756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"
Jack DeVries added the comment: @petr.viktorin a whatsnew entry was added, what more notice could have been provided? I have an idea for an alternative that might be better. What if ``make clean`` deletes and restores the venv only if it already existed in the first place? -- ___ Python tracker <https://bugs.python.org/issue44756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44790] Recursion causes Crash
Jack DeVries added the comment: Also, see related: bpo-44393 -- ___ Python tracker <https://bugs.python.org/issue44790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44790] Recursion causes Crash
Jack DeVries added the comment: The default recursion limit is 1,000; you're increasing it by a factor of 10. It is documented that raising the recursion limit can cause crashes. What kind of crash are you seeing? Segmentation fault or stack overflow? Also, provide more details about your system: what OS and more importantly in this case, how much RAM? It's possible that this is not a bug. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44788] Possibility to specify port in __init__ of ftplib.FTP
Jack DeVries added the comment: > user might typically want to explicitly handle them in most cases. *Explicitly handle exceptions -- ___ Python tracker <https://bugs.python.org/issue44788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44788] Possibility to specify port in __init__ of ftplib.FTP
Jack DeVries added the comment: The only thing to consider is that connections are flakey, and the user might typically want to explicitly handle them in most cases. Therefore, it's a better API if the .connect() call appears in the user's code. If anything, it might be better to create a new context manager called Auto FTP connection or something, and include default error handling behavior. Have you discussed this idea in python- ideas? -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44658] No ValueError for duplicate key value in mapping patern when lengths do not match
Jack DeVries added the comment: @brandtbucher yeah, you can close it, this was a silly idea. -- ___ Python tracker <https://bugs.python.org/issue44658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44393] segfault with sys.setrecursionlimit
Jack DeVries added the comment:
What about low recursion limits? This program causes a segfault for me::
import sys
sys.setrecursionlimit(4)
print('goodbye, world')
--
nosy: +jack__d
___
Python tracker
<https://bugs.python.org/issue44393>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43548] RecursionError depth exceptions break pdb's interactive tracing.
Jack DeVries added the comment:
@behindthebrain, I noticed that this script behaves weirdly when I try to set
breakpoints at various places. However, the problem goes away when I raise the
recursion limit. Things in python will not work right if you set the recursion
limit to a low value. For example, this hello, world program does not run at a
recursion depth of four::
import sys
sys.setrecursionlimit(4)
print('hello, world')
--
nosy: +jack__d
___
Python tracker
<https://bugs.python.org/issue43548>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Change by Jack DeVries : -- pull_requests: +25963 pull_request: https://github.com/python/cpython/pull/27434 ___ Python tracker <https://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Jack DeVries added the comment: I'm going to go ahead and submit my PR under the assumption that Lukasz will probably prefer to actually be able to review it when he takes a look at this, and additionally we haven't heard from @eamanu. @eamanu, I'll close it if you would like to continue; just let me know! -- ___ Python tracker <https://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44752] Tab completion executes @property getter function
Change by Jack DeVries : -- pull_requests: +25962 pull_request: https://github.com/python/cpython/pull/27433 ___ Python tracker <https://bugs.python.org/issue44752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44763] "width defaults to 70." in textwrap.wrap documentation is repetitive.
Change by Jack DeVries : -- pull_requests: +25952 pull_request: https://github.com/python/cpython/pull/26999 ___ Python tracker <https://bugs.python.org/issue44763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44763] "width defaults to 70." in textwrap.wrap documentation is repetitive.
Change by Jack DeVries : -- keywords: +patch pull_requests: +25951 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27423 ___ Python tracker <https://bugs.python.org/issue44763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44763] "width defaults to 70." in textwrap.wrap documentation is repetitive.
New submission from Jack DeVries : The phrase "width defaults to 70." in the documentation for textwrap.wrap is repetitive, because that information is already communicated in the function signature. The desire to fix this came up this discussion around this PR: https://github.com/python/cpython/pull/26999#discussion_r678322870 I will attach a PR momentarily. -- assignee: docs@python components: Documentation messages: 398392 nosy: docs@python, jack__d priority: normal severity: normal status: open title: "width defaults to 70." in textwrap.wrap documentation is repetitive. type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"
Change by Jack DeVries : -- keywords: +patch pull_requests: +25936 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27403 ___ Python tracker <https://bugs.python.org/issue44756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"
New submission from Jack DeVries : In Doc/Makefile, all of the build rules should be dependent on the existence of a virtual environment. I could see this being controversial, because folks who have these tools installed elsewhere might prefer not to have a venv made for them, but my personal workflow is to strive to keep my system site-packages folder as empty as possible and to use virtual environments frequently. In any case, I'm interested to hear what we think. Momentarily, I will attach a PR where I went ahead and made these changes. Here is a summary of the changes: - venv rule is now conditional, and only does anything if $VENVDIR does not exist - add rule "clean-venv". This can be removed – what do you all think? - build rule is dependent on venv - as a result, rules dependent on build are dependent on venv - html - latex - etc. - update Doc/README.rst appropriately. Now users only need to type ``make html`` – nice! Let me know what you think. I may have a blind spot to others' workflows! Also, I'm not a Windows user, so I have no insight as to whether ``make.bat`` needs to be updated as well. -- assignee: docs@python components: Demos and Tools, Documentation messages: 398344 nosy: docs@python, jack__d priority: normal severity: normal status: open title: In ./Doc, "make html" and "make build" should depend on "make venv" type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44752] Tab completion executes @property getter function
Jack DeVries added the comment: > Now that I see hasattr() uses getattr(), it looks like the tab completion > issue might not stem from line 155, but from line 180 > (https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/Lib/rlcompleter.py#L180) > where it calls getattr(). That is correct! I was able to fix the undesirable behavior by adding an early exit condition if we appear to have a property object. I checked for the existence of a property object like this: class Foo: @property def bar(self): return 'baz' def is_property(object, attr): return isinstance(getattr(type(object), attr, None), property) assert is_property(Foo(), 'bar') The code that follows line 180 in the loop just checks if ``object.attribute`` is callable, and whether the callable takes arguments in order to determine whether to add parenthesis to the completion. In my opinion, we never really want to add parenthesis when providing completion for a property attribute anyway, so there's no reason to go through that code block if we are dealing with a property. I opened a GitHub PR. Let me know what you think! -- ___ Python tracker <https://bugs.python.org/issue44752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44752] Tab completion executes @property getter function
Change by Jack DeVries : -- keywords: +patch pull_requests: +25934 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27401 ___ Python tracker <https://bugs.python.org/issue44752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44752] Tab completion executes @property getter function
Jack DeVries added the comment: Woah, til the python shell has tab completion! This does seem like undesirable behavior. I'd like to work on a fix for this if that's all right, assuming that this behavior should not occur. I haven't exactly found where the tab autocomplete is implemented, but I'm assuming I'll find in one of the functions I see in the backtrace when I pause python at the interpreter prompt; maybe one of these? (my best quick guesses by function name). - _PyRun_InteractiveLoopObject - PyRun_InteractiveOneObjectEx - interactive_rule - statement_newline_rule If anyone can point me in the right direction, that'd be great, and I think I can work on this one tomorrow if that's all right! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39812] Avoid daemon threads in concurrent.futures
Jack DeVries added the comment: The regression that @janfrederik.konopka points out also has it's own open issue: bpo-43944. I'm trying to work on a fix for this regression. Slowly but surely. Now I've finally found these threads, this information will be a big help! Any tips are appreciated. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue39812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43944] Processes in Python 3.9 exiting with code 1 when It's created inside a ThreadPoolExecutor
Jack DeVries added the comment: The first bad commit was a fix for bpo-39812. -- ___ Python tracker <https://bugs.python.org/issue43944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43944] Processes in Python 3.9 exiting with code 1 when It's created inside a ThreadPoolExecutor
Jack DeVries added the comment: I've identified the first bad commit with git-bisect: commit b61b818d916942aad1f8f3e33181801c4a1ed14b Author: Kyle Stanley Date: Fri Mar 27 15:31:22 2020 -0400 bpo-39812: Remove daemon threads in concurrent.futures (GH-19149) Remove daemon threads from :mod:`concurrent.futures` by adding an internal `threading._register_atexit()`, which calls registered functions prior to joining all non-daemon threads. This allows for compatibility with subinterpreters, which don't support daemon threads. -- ___ Python tracker <https://bugs.python.org/issue43944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43944] Processes in Python 3.9 exiting with code 1 when It's created inside a ThreadPoolExecutor
Jack DeVries added the comment: Ah never mind. @Genarito, the ThreadPoolExecutor is supposed to be used as a context manager. In your current code, the script ends and Python starts tearing itself down while `execute_error` is still running in a subprocess. If you simply use the ThreadPoolExecutor to a context manager, the error goes away:: ```python from multiprocessing import Process from concurrent.futures import ThreadPoolExecutor def some_task(): pass def execute_error(): p = Process(target=some_task) p.start() p.join() print(p.exitcode) # This is always 1 on a ThreadPoolExecutor!!! # THIS IS THE IMPORTANT CHANGE with ThreadPoolExecutor(max_workers=4) as executor: executor.submit(execute_error) ``` -- ___ Python tracker <https://bugs.python.org/issue43944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43944] Processes in Python 3.9 exiting with code 1 when It's created inside a ThreadPoolExecutor
Jack DeVries added the comment: I am working on a fix for this bug. I'm a beginner cpython contributor, so if anyone recognizes this as a fool's errand, please let me know! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue43944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41256] activate script created by venv is not smart enough
Jack DeVries added the comment: *please disregard the typo in the shebang line!* -- ___ Python tracker <https://bugs.python.org/issue41256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41256] activate script created by venv is not smart enough
Jack DeVries added the comment: What do you think about this as an entrypoint? ```sh #!/usr/bin/env # this becomes venv/bin/activate # the old venv/bin/activate is now venv/bin/activate.sh # Try to execute a `return` statement, # but do it in a sub-shell and catch the results. # If this script isn't sourced, that will raise an error. $(return >/dev/null 2>&1) # What exit code did that give? if [ "$?" -ne "0" ] then echo "Warning: this script must be sourced, not run in a subshell." echo "Try \"source /path/to/activate\" on unix-like systems." fi # dispatch to shell-specific activate scripts # *ignore proper path construction for the sake of demonstration...* [ $BASH_VERSION ] || [ $ZSH_VERSION ] && . ./activate.sh [ $FISH_VERSION ] && . ./activate.fish [ $csh_version ] && . ./activate.csh ``` The try-to-return trick was shamelessly taken from here: https://stackoverflow.com/a/34642589/13262536 I am a shell scripting novice, so I am certain that there are many unaddressed edge cases here. I know that reliably detecting whether a script has been sourced or "ran" is essentially impossible to do in a cross-platform way. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue41256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29555] Update Python Software Foundation Copyright Year
Jack DeVries added the comment: Hi, Found while sleuthing random issues. Can we close this? -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue29555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44050] [subinterpreters] _PyImport_FixupExtensionObject() regression in Python 3.9
Jack DeVries added the comment: I just took a look at this, and I'm getting an output of "no data" (just one time) on 3.9.6. Has this been fixed? -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44050> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44713] subprocess.rst typo ``"shell=True"`` => ``shell=True``
Change by Jack DeVries : -- keywords: +patch pull_requests: +25840 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27297 ___ Python tracker <https://bugs.python.org/issue44713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44713] subprocess.rst typo ``"shell=True"`` => ``shell=True``
New submission from Jack DeVries : Good feedback from @merwork just missed the merge, but he is right: it should be ``shell=True``, not ``"shell=True"``. https://github.com/python/cpython/pull/26755#discussion_r675128438 I'll be attaching a PR in just a moment. -- messages: 398010 nosy: jack__d priority: normal severity: normal status: open title: subprocess.rst typo ``"shell=True"`` => ``shell=True`` ___ Python tracker <https://bugs.python.org/issue44713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Jack DeVries added the comment: Hi all! @eamanu, I went ahead and picked up where you left off. I stopped short of opening up a PR, because I don't want to step on any toes, but I definitely want to do what I can to give this bpo one final shove over the finish line. Despite not creating a PR, you can see the changes here: https://github.com/python/cpython/compare/main...jdevries3133:bpo-19217-slow-assertEq @eamanu, if you prefer, you can probably just merge this branch into `eamanu:fix_bpo-19217`, and the conversation can move forward on GH-11204. Also, below is a summary of what I've done: Revert Change to difflib Link to the original thread where this change was discussed a bit: https://github.com/python/cpython/pull/11204#discussion_r242369775 I assume this was a performance improvement. It's not clear to me why we are not interested in this part of the diff when the input is a list or tuple. I'm sure someone will help to explain, but this is why I reverted this change: 1. It is not an issue with unittest, and reaches beyond the scope of this bpo 2. The performance problem at the root of this bpo is solved without this change. 3. Reverting this change fixes most of the cascading failures throughout other parts of the test suite. It better constrains this fix to improving the implementation's performance issues while limiting changes to behavior. Obviously, I don't have knowledge of the reasoning behind this change sufficient to write a new bpo, but I think that this small change does deserve its own bpo with an independent explaination of what it does and why it should be done. It's definitely possible that I'm missing something here, so let me know if that's the case! Add Regression Test === The regression test basically attempts to reproduce the problem and asserts that the code will complete within one second. It's a pretty rough approach, but I think that it will catch a future regression. If anyone has any better ideas, I'm all ears. Misc I also fixed the one failing test in unittest's own test case, and added a blurb. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35183] os.path.splitext documentation needs typical example
Jack DeVries added the comment: @jstockwin, the process usually goes like this: 1. You open a PR 2. The discussion continues over there. non-core-dev volunteers review your PR and get it into a polished state. 3. A core dev will quickly take a look, provide feedback if necessary, or just merge if not. There's no need to credit anyone – if Shaun wanted credit, he could have included a PR with his bug report! Plus, the commit will include this bpo#, so future onlookers can always trace the commit back to this thread. Follow the dev guide as you go and don't hesitate to post any questions you have right here! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue35183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44435] There is no description of PY_SSIZE_T_CLEAN in docs
Jack DeVries added the comment: Looking back at this issue, I can see that there is documentation for this in the 'note' block. I'm just going to close this issue. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)
Jack DeVries added the comment: UGH I was experimenting with installing / compilingi gdb and had accidentally installed a different version of `ar` :/ -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)
Jack DeVries added the comment: I'm also getting this warning: ld: warning: object file (Programs/python.o) was built for newer macOS version (11.5) than being linked (11.0) -- ___ Python tracker <https://bugs.python.org/issue44700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)
Change by Jack DeVries : -- type: -> compile error versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue44700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44700] Python fails to build (aarch64-apple-darwin20.5.0)
New submission from Jack DeVries : I believe this is a problem with my machine because I've tried checking out to known good commits (which worked on my machine before) and have the same issue, but I've tried everything and don't really know what to do next. I'm hoping someone can help me, and who knows – maybe it is a bug! This is the command that fails:: gcc -Wl,-stack_size,100 -framework CoreFoundation \ -o Programs/_testembed Programs/_testembed.o libpython3.11d.a -ldl \ -framework CoreFoundation The linker is ignoring `libpython3.11d.a`, providing the following warning:: ignoring file libpython3.11d.a, building for macOS-arm64 but attempting to link with file built for macOS-arm64 Of course, what follows is a ton of undefined symbol errors; no surprises there. I don't understand how to fix the error, why it is happening, or how this issue could have possibly cropped up overnight. These are the things I've tried to fix it: 1. Run autoconf to regenerate the configure script. 2. Delete everything. Reconfigure and rebuild from a clean slate. 3. Comment out `.zshenv`, `.zshrc`, and `.zprofile` 4. Try configuring and compiling on bash and sh instead of zsh -- components: Build messages: 397957 nosy: jack__d priority: normal severity: normal status: open title: Python fails to build (aarch64-apple-darwin20.5.0) ___ Python tracker <https://bugs.python.org/issue44700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44681] time.sleep(0.001) not working properly
Jack DeVries added the comment: This is not a bug. See the docs: The precision of the various real-time functions may be less than suggested by the units in which their value or argument is expressed. E.g. on most Unix systems, the clock “ticks” only 50 or 100 times a second. On the other hand, the precision of time() and sleep() is better than their Unix equivalents: times are expressed as floating point numbers, time() returns the most accurate time available (using Unix gettimeofday() where available), and sleep() will accept a time with a nonzero fraction (Unix select() is used to implement this, where available). Assuming a clock speed of 50x/second as the documentation names, the cpu only cycles every 0.02 seconds. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44651] An unclear definition in Doc/glossary.rst
Jack DeVries added the comment: @StevenHsuYL yes, you can go ahead and create a PR for this if you'd like! Just follow the directions in the dev guide (link in sidebar). I can't really tell for sure because I'm on my phone right now, but it looks like this might be your first time contributing to cpython; welcome! If you have any questions about the process, feel free to put them here. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44664] builtins.chr and the 'c' format flag raise different errors
Change by Jack DeVries : -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44600] match/case statements trace incorrectly in 3.10.0b4
Jack DeVries added the comment: @brandtbucher, is anyone working on this yet? I'd like to take a crack at it this week if it's still available! -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44589] Pattern Matching - duplicate keys in mapping patterns
Jack DeVries added the comment: The PR and backport to 3.10 have both been merged, so I think this issue can be closed. -- ___ Python tracker <https://bugs.python.org/issue44589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44658] No ValueError for duplicate key value in mapping patern when lengths do not match
Jack DeVries added the comment: Another option if this problem is isolated to mapping patterns, we could introduce a new op-code: BUILD_MATCH_MAP, which is essentially a wrapper around BUILD_MAP that disallows duplicate key values. -- ___ Python tracker <https://bugs.python.org/issue44658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44658] No ValueError for duplicate key value in mapping patern when lengths do not match
New submission from Jack DeVries :
Consider the following code:
class A:
a = 'a'
# runs without error
match {'a': 1}:
case {'a': 1, A.a: 1}:
pass
# raises ValueError
match {'a': 1, 'b': 1}:
case {'a': 1, A.a: 1}:
pass
In both cases, the mapping pattern is the same (and both are not valid due to
duplicate key values). However, the pattern is only evaluated in the second
case. This is because a key-length optimization provides a shortcut around
pattern evaluation. The docs gives users a hint that things like this might
happen, which is a good thing:
> Users should generally never rely on a pattern being evaluated. Depending on
> > implementation, the interpreter may cache values or use other optimizations
> > which skip repeated evaluations.
> https://docs.python.org/3.10/reference/compound_stmts.html#overview
However, I can't help but think that these ergonomics are strange. Consider if
some other code is mutating the value of `A.a`. This could create some very
strange and flaky bugs where the state of `A.a` can change and make the pattern
invalid, but nonetheless not cause an exception until much later, or not at all.
There is mapping pattern validation code in the `match_keys` function in
ceval.c. I haven't looked, but I assume there is some other runtime validation
for other match case types. I propose factoring Exception-raising validation
into a separate procedure that is called before any optimization jumps occur.
This trades speed for consistent behavior, and I'm interested to hear what
others think!
--
components: Interpreter Core
messages: 397662
nosy: jack__d
priority: normal
severity: normal
status: open
title: No ValueError for duplicate key value in mapping patern when lengths do
not match
type: behavior
versions: Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue44658>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44638] zipfile.ZipFile is closed when zipfile.Path is closed
Jack DeVries added the comment:
I'm not able to reproduce this on my machine; the script runs without any issue.
> the `TestClass` instance is being closed
What do you mean by this statement? You aren't doing anything to TestClass or
its instance ("test") in this script. They remain in scope, so they will always
be referenced.
--
nosy: +jack__d
___
Python tracker
<https://bugs.python.org/issue44638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44473] logging.handlers.QueueHandler acts unexpected
Jack DeVries added the comment: I have another question about the docstring in the source beneath logging.handlers.QueueHandler.prepare. It says: > The object returned by this method is enqueued. But, the prepare method doesn't do the enqueuing operation, it just prepares the record and returns it back, so it seems like this statement is not accurate? -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44639] [sqlite3] Confusing typo "transation"
Jack DeVries added the comment: To my understanding, it's supposed to say "transaction". The source code is here: https://github.com/python/cpython/blob/a158b20019b50e3ece6e4743ec4e6ae8d818b690/Modules/_sqlite/connection.c#L1434-L1467 I've opened a PR to fix the typo. -- ___ Python tracker <https://bugs.python.org/issue44639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44639] [sqlite3] Confusing typo "transation"
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 3.0 -> 4.0 pull_requests: +25687 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27145 ___ Python tracker <https://bugs.python.org/issue44639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44640] Typos in error messages of isinstance() & issubclass()
Jack DeVries added the comment: The current string is correct. The word "union" is actually an exception to the "a/an" rule. Here is more detail: https://english.stackexchange.com/questions/266309/why-is-union-an-exception-to-the-a-an-rule -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44589] Pattern Matching - duplicate keys in mapping patterns
Jack DeVries added the comment: @brandtbucher, I'm sorry for the miscommunication. I started working on this patch at the beginning of the week after message 397215... I'm a new contributor too, and I wasn't sure if I would be able to make something that worked, so I just kept my mouth shut. Then, all of a sudden, it came together and I had a (mostly) working patch. I'm going to incorporate your review now; thank you for the feedback, and I'm very sorry for any toes I may have stepped on. -- ___ Python tracker <https://bugs.python.org/issue44589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()
Jack DeVries added the comment: I wonder if the middle ground here is to let it be a teachable moment, and to inform the user by having the string returned by __repr__ be a bit more descriptive. Currently, it is: > Use exit() or Ctrl-Z plus Return to exit I propose: > exit is the function that closes Python when called. To call a Python > function, add parenthesis! For example, "exit()". To share a personal anecdote, Python was my first programming language. I can remember this specific case of REPL-stubbornness being instrumental in teaching me about referencing versus calling a function. Special cases cause confusion, and a shortcut that removes two characters at the expense of skirting past an essential understanding is not the right choice. The place we should be *most* careful about breaking language idioms are in the spots that are exposed to beginners and newcomers to the language. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44589] Pattern Matching - duplicate keys in mapping patterns
Jack DeVries added the comment: @brandtbucher, I think that my PR implements the solution you've described here. What do you think? -- ___ Python tracker <https://bugs.python.org/issue44589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44589] Pattern Matching - duplicate keys in mapping patterns
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 3.0 -> 4.0 pull_requests: +25674 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27131 ___ Python tracker <https://bugs.python.org/issue44589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44534] unittest.mock.Mock.unsafe doc is garbled
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 2.0 -> 3.0 pull_requests: +25560 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27000 ___ Python tracker <https://bugs.python.org/issue44534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44552] incomplete documentation of __main__.py
Jack DeVries added the comment: This is documented in Doc/library/runpy.rst. Specifically, here: > For a simple script, the specified code is simply executed in a fresh module > namespace. For a valid sys.path entry (typically a zipfile or directory), the > entry is first added to the beginning of sys.path. The function then looks > for and executes a __main__ module using the updated path. Note that there is > no special protection against invoking an existing __main__ entry located > elsewhere on sys.path if there is no such module at the specified location. https://docs.python.org/3/library/runpy.html#runpy.run_path However, I fully agree that Doc/library/__main__.rst is severely lacking; that's why I've rewritten it! Please consider providing your feedback on the open PR, and see bpo-39452 https://github.com/python/cpython/pull/26883 Note that the new docs in __main__.rst does explicitly reference runpy, so once merged, it'll guide people looking for this information in __main__.rst to the right place. -- nosy: +jack__d ___ Python tracker <https://bugs.python.org/issue44552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44544] Add full list of possible args to textwrap: wrap, fill, shorten
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 2.0 -> 3.0 pull_requests: +25559 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26999 ___ Python tracker <https://bugs.python.org/issue44544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44543] Remove depreciated logging.warn() method
Jack DeVries added the comment: I'm not sure if there will be interest in merging this PR since it hasn't happened in all this time, but then again we've been emitting deprecation warnings from these functions and methods for a *decade* now. If the decision at this point is still not to move forward with removal, we should just remove the deprecation warnings and document it as a supported and bona-fide alias. Should that be the case, I'll close the PR I just created and get started with that work instead. -- ___ Python tracker <https://bugs.python.org/issue44543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44543] Remove depreciated logging.warn() method
Change by Jack DeVries : -- keywords: +patch nosy: +jack__d nosy_count: 2.0 -> 3.0 pull_requests: +25544 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26982 ___ Python tracker <https://bugs.python.org/issue44543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44490] PEP 604 Union (int | str) doesn't have __parameters__
Jack DeVries added the comment:
mypy does not support __parameters__:
(venv) ➜ cpython git:(main) cat repro.py
from typing import TypeVar
T = TypeVar('T')
(int | list[T]).__parameters__
(venv) ➜ cpython git:(main) mypy --version
mypy 0.920+dev.cae5d3c8b5f14d0796914aa6a113473ca3ffc38e
(venv) ➜ cpython git:(main) python --version
Python 3.11.0a0
(venv) ➜ cpython git:(main) mypy repro.py
repro.py:4: error: "types.Union" has no attribute "__parameters__"
Found 1 error in 1 file (checked 1 source file)
(venv) ➜ cpython git:(main)
mypy also does not support __getitem__
(venv) ➜ cpython git:(main) cat repro.py
from typing import TypeVar
T = TypeVar('T')
(int | list[T]).__getitem__
(venv) ➜ cpython git:(main) mypy --version
./mypy 0.920+dev.cae5d3c8b5f14d0796914aa6a113473ca3ffc38e
(venv) ➜ cpython git:(main) python --version
Python 3.11.0a0
(venv) ➜ cpython git:(main) mypy repro.py
repro.py:4: error: Value of type "types.Union" is not indexable
Found 1 error in 1 file (checked 1 source file)
(venv) ➜ cpython git:(main)
--
nosy: +jack__d
___
Python tracker
<https://bugs.python.org/issue44490>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44526] Doc typo in "What’s New In Python 3.10" (x/y-axis)
Jack DeVries added the comment: @serif2 nice catch! -- ___ Python tracker <https://bugs.python.org/issue44526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
