[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
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: I did reply to that point above with some baseless speculation, but now I can back up my baseless speculation with unscientific data :) https://gist.github.com/oconnor663/aed7016c9dbe5507510fc50faceaaa07 According to whatever `powerstat -R` measures on my laptop, running hardware-accelerated SHA-256 in a loop for a minute or so takes 26.86 Watts on average. Doing the same with AVX-512 BLAKE3 takes 29.53 Watts, 10% more. Factoring in the 4.69x difference in throughput reported by those loops, the overall energy/byte for BLAKE3 is 4.27x lower than SHA-256. This is my first time running a power benchmark, so if this sounds implausible hopefully someone can catch my mistakes. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > Truncated sha512 (sha512-256) typically performs 40% faster than sha256 on > X86_64. Without hardware acceleration, yes. But because SHA-NI includes only SHA-1 and SHA-256, and not SHA-512, it's no longer a level playing field. OpenSSL's SHA-512 and SHA-512/256 both get about 797 MB/s on my machine. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > Hardware accelerated SHAs are likely faster than blake3 single core. Surprisingly, they're not. Here's a quick measurement on my recent ThinkPad laptop (64 KiB of input, single-threaded, TurboBoost left on), which supports both AVX-512 and the SHA extensions: OpenSSL SHA-256: 1816 MB/s OpenSSL SHA-1: 2103 MB/s BLAKE3 SSE2: 2109 MB/s BLAKE3 SSE4.1: 2474 MB/s BLAKE3 AVX2: 4898 MB/s BLAKE3 AVX-512: 8754 MB/s The main reason SHA-1 and SHA-256 don't do better is that they're fundamentally serial algorithms. Hardware acceleration can speed up a single instance of their compression functions, but there's just no way for it to run more than one instance per message at a time. In contrast, AES-CTR can easily parallelize its blocks, and hardware accelerated AES does beat BLAKE3. > And certainly more efficient in terms of watt-secs/byte. I don't have any experience measuring power myself, so take this with a grain of salt: I think the difference in throughput shown above is large enough that, even accounting for the famously high power draw of AVX-512, BLAKE3 comes out ahead in terms of energy/byte. Probably not on ARM though. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > maintaining a complicated build process in-tree For what it's worth, if you have any sort of "in a perfect world" vision for what the upstream BLAKE3 project could do to make it trivially easy for you to integrate, I'd be very interested in getting that done. Making integration easy would benefit all callers. We have some issues on the backburner about committing CMake build files, but I assume those would be useless for us here. Is there anything that would be more useful? If we provided autotools build files, could you call into them? Fundamentally, BLAKE3 wants to build some code on x86 and some other code on ARM, and also some code on Unix and some other code on Windows. Currently we just ask the caller to do that for us, for lack of a common standard. (And if we're building intrinsics rather than assembly, we also need the compiler flags that enable our intrinsics.) But maybe we could handle more of that upstream, using the preprocessor? If the build instructions said "compile this one giant file on all platforms and don't worry about what it does", would that be better? Or would that be gross? Is a header-only library the gold standard? Or too C++-ish? Has anyone ever done a really good job of this? -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Thanks Larry! Was any of the experimental C extension code under https://github.com/oconnor663/blake3-py/tree/master/c_impl useful to you? I was wondering if it could be possible to copy blake3module.c from there verbatim. The setup.py build there also has working Windows and NEON support. I've patched the blake3-py test suite (which both the production Rust-based extension and that experimental C-based extension currently pass) to invoke the new hashlib implementation from your branch. You can find the full test output, and the procedure I used to run the tests, in this Gist https://gist.github.com/oconnor663/533048580b1c0f4a01d1d55f57f92792. Here are some differences: - My derive_key_context parameter requires a string and refuses to accept bytes. This is consistent with our Rust and C APIs (though the C API does include a _raw version specifically for bindings, which we're using here). For a long discussion of why we prefer to do things this way, see https://github.com/BLAKE3-team/BLAKE3/issues/13. The short version is that any use case that requires arbitrary bytes for the context string is almost certainly violating the documented security requirement that the context string must be hardcoded. - I've included an `AUTO` constant that provides a special value (-1) for the `max_threads` argument, and I explicitly don't support `max_threads=0`. - I enforce that the `data` arguments are positional-only and that the other keyword arguments are keyword-only. I think this is consistent with the rest of hashlib. - I include a `.reset()` method. This isn't particularly useful in the default case, where you might as well create a new hasher. But when `max_threads` is greater than 1 in the Rust implementation, the hasher owns a thread pool, and `.reset()` is currently the only way to reuse that pool. (A BLAKE3 hasher is also ~2 KB, somewhat larger than other hashers, so callers who are pinching pennies with their allocator traffic might prefer to reuse the object.) - Unrelated to tests: I haven't made any attempt to zero memory in my `dealloc` function. But if that's what other hashlib functions do, then I'm certainly in favor of doing it here too. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Yes, everything in https://github.com/BLAKE3-team/BLAKE3 and https://github.com/oconnor663/blake3-py is public domain via CC0, and dual licensed under Apache for good measure. Hopefully that makes it easy to use it anywhere. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: What's the best way for me to help with the next steps of this? -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Change by Jack Nguyen : -- keywords: +patch pull_requests: +29432 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31267 ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
Jack Nguyen added the comment: As you say, which implementation performs better likely depends on the nature of the sets. I would suspect that using set.difference won't be substantially faster than using set.intersection in the best case, but it would be much slower if len(self) is much larger than len(self.intersection(other)) e.g. set(range(1_000_000)).issubset(range(10)). Overall I think that using set.intersection will have more well-rounded performance. -- ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46705] Memory optimization for set.issubset
New submission from Jack Nguyen : I noticed that the set.issubset cpython implementation casts its iterable argument to a set. In some cases, casting the whole iterable to a set is unnecessary (see https://bugs.python.org/issue18032). Although the latter suggestion is to perform early termination, my suggestion is to use the intersection instead. # PyAnySet_Check coming from the cpython source code. def issubset(self, other): # Intersection suggestion: if not PyAnySet_Check(other): return len(self.intersection(other)) == len(self) # Usual implementation for sets. else: return ... The main advantage that this implementation has is its memory performance, using only O(min(len(self), len(other))) memory, since it never stores elements it does not need. I'm assuming that set construction costs O(n) set.__contains__ calls. This implementation uses len(other) calls to self.__contains__ and tmp.__contains__, where tmp = set(other). The current implementation uses len(self) + len(other) calls to tmp.__contains__. Thus, I suspect the current implementation only has a chance at running noticeably faster when len(self) << len(other), where it performs fewer calls to set.__contains__. This is, however, also where the proposed implementation has significantly superior memory performance. -- components: Interpreter Core messages: 412966 nosy: panda1200 priority: normal severity: normal status: open title: Memory optimization for set.issubset type: performance versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Yeah by intrinsics I mean stuff like _mm256_add_epi32(). All of that stuff is in these vendored files: blake3_avx2.c blake3_avx512.c blake3_neon.c blake3_sse2.c blake3_sse41.c Also to Michał's question above, I'm not necessarily opposed to publishing something like "blake3-c" on PyPI once things stabilize. Even if we get BLAKE3 into hashlib in 3.11, PyPI modules will be useful to folks running older versions, and not everyone wants to install the Rust toolchain. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: > As a first pass I say we merge the reference C implementation. Do you mean portable-only C code, or portable + intrinsics? If the assembly files are out, I'd advocate for the latter. The intrinsics implementations are nearly as fast as the assembly code, and both of those are several times faster than the portable code. You can test this configuration with my current setup.py by setting the env var FORCE_INTRINSICS=1. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment:
I was about to say the only missing feature was docstrings, but then I realized
I hadn't included releasing the GIL. I've added that and pushed an update just
now. Fingers crossed there's nothing else I've missed. I think it's in
reasonably good shape, and I'd like to propose it for inclusion in 3.11.
However, I'm not very experienced with setup.py or the Python C API, so I might
not be the best judge of shape. Here are some highlights for reviewers, where I
think the implementation (mostly the build) could be shaky:
- Platform detection. In setup.py I assume that the target platform of the
build is the same as the current interpreter's platform. So for example, if the
current interpreter has sys.maxsize==2**31-1, I assume we're compiling for
32-bit. This clearly doesn't allow for any sort of cross-compilation, and in
general I need feedback about whether there's a more correct way to obtain the
target platform.
- Compiling assembly files. On Unix this is easy, because we can supply *.S
files as `extra_objects` and GCC/Clang will do the right thing. But on Windows
this isn't easy. Currently I shell out to vswhere.exe, ask it for the path to
the latest version of the ml64.exe assembler, and then shell out to that to
build .obj files. Then I pass those assembled .obj files as `extra_objects`.
This feels awfully manual, and there's a good chance I've missed some
better-supported way to do it. I assume we don't want to check in the .obj
files?
- Does Python support the GNU ABI on Windows? We have assembly files for this
in vendor/, but I'm not currently building them.
- Compiling intrinsics files for 32-bit x86. In this case, I create a
`ccompiler.new_compiler()` for each intrinsics file, so that I can set the
appropriate flags for each. This is relatively clean, but it leads to things
getting rebuilt every single time, rather than participating in `setup.py
build` caching. Maybe nobody cares about this, but again it makes me think
there might be a better-supported way to do it.
- blake3module.c contains an awful lot of gotos to handle allocation failure
cases. Is this still considered a best practice? These are bug-prone, and I'm
not sure how to test them.
- Existing hashlib implementations include an optimization where they avoid
allocating an internal mutex until they see a long input and want to release
the GIL. As a quirky side effect of this, they handle allocation failures for
that mutex by falling back to the do-not-release-the-GIL codepath. That feels
kind of complicated to me, and in my code I'm always allocating the mutex
during initialization. This doesn't seem to make much of a performance
difference when I measure it, but there might be use cases I haven't considered.
Here are some other API details that might be worth bikeshedding:
- The `max_threads` parameter is currently defined to take a special value,
`blake3.AUTO`, to indicate that the implementation may use as many threads as
it likes. (The C implementation doesn't include multithreading support, but
it's API-compatible with the Rust implementation.) `blake3.AUTO` is currently a
class attribute equal to -1. We may want to bikeshed this name or propose some
other representation.
- BLAKE3 has three modes: regular hashing, keyed hashing, and key derivation.
The keyed hashing mode takes a 32-byte key, and the key derivation mode takes a
context string. Calling the 32-byte key `key` seems good. Calling the context
string `context` seems less good. Larry has pointed out before that lots of
random things are called `context`, and readers might not understand what
they're seeing. I currently call it `derive_key_context` instead, but we could
bikeshed this.
- I check `itemsize` on input Py_buffers and throw an exception if it's
anything other than 1. My test suite exercises this, see
`test_int_array_fails`. However, some (all?) standard hashes don't do this
check. For example:
>>> from hashlib import sha256
>>> import array
>>> a = array.array("i", [255])
>>> sha256(a).hexdigest()
'81ff65efc4487853bdb4625559e69ab44f19e0f5efbd6d5b2af5e3ab267c8e06'
>>> sha256(bytes([0xff, 0, 0, 0])).hexdigest()
'81ff65efc4487853bdb4625559e69ab44f19e0f5efbd6d5b2af5e3ab267c8e06'
Here we can see sha256() hashing an array of int. On my machine, an int is 4
little-endian bytes, but of course this sort of thing isn't portable. The same
array will result in a different SHA-256 output on a big-endian machine, or on
a machine with ints of a different size. This seems undesirable, and I'm
surprised that hashlib allows it. However, if there's some known compatibility
reason why we have to allow it, I could remove this check.
--
versions: +Python 3.11 -Python 3.10
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Ah, good idea. I've published the new C implementation as: https://test.pypi.org/project/blake3-experimental-c/ You can install it with: pip install -i https://test.pypi.org/simple/ blake3-experimental-c Despite the package name change, the extension module is still "blake3", so we still "import blake3" to get at it. For example: $ pip install -i https://test.pypi.org/simple/ blake3-experimental-c $ python >>> from blake3 import blake3 >>> blake3(b"foo").hexdigest() '04e0bb39f30b1a3feb89f536c93be15055482df748674b00d26e5a7502e9' >>> blake3(b"foo", max_threads=blake3.AUTO).hexdigest() '04e0bb39f30b1a3feb89f536c93be15055482df748674b00d26e5a7502e9' To run the Rust implementation's test suite against this implementation, you could then: $ pip install pytest numpy $ git clone https://github.com/oconnor663/blake3-py $ python -m pytest blake3-py/tests/test_blake3.py = test session starts = platform linux -- Python 3.10.1, pytest-6.2.5, py-1.11.0, pluggy-0.13.1 rootdir: /tmp collected 24 items blake3-py/tests/test_blake3.py [100%] = 24 passed in 0.30s == -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Update: There is now a C version of the `blake3` Python module available at https://github.com/oconnor663/blake3-py/tree/master/c_impl. It's completely API-compatible with the Rust version, and it passes the same test suite. Multithreading (which is implemented in upstream Rust but not in upstream C) is exposed through a "max_threads" argument, as Larry Hastings suggested. The C implementation allows this argument but ignores it. Unlike my previous attempt, this setup.py build handles the full range of target platforms and optimized flavors: x86-64 assembly on Windows-MSVC and Unix, 32-bit x86 intrinsics on Windows-MSVC and Unix, NEON intrinsics on AArch64, and portable C for everyone else. I'm new to distutils/setuptools and not particular familiar with the MSVC toolchain either, so there's a good chance that others can suggest better/cleaner/more robust approaches than what I've got, but it's at least working on my machines and on GitHub CI. (I haven't tried to get any cross-compilation working though; is that a thing?) I haven't published this module to PyPI, partly to avoid confusion with the Rust-based implementation, which I think most applications should prefer. But if it would make a big difference to anyone who wants to review this code, we could certainly put it up as `experimental_blake3_c` or something? Let me know what's best. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals
Change by Jack Wong : -- nosy: +iforapsy ___ Python tracker <https://bugs.python.org/issue36906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31148] Can we get an MSI installer for something past 3.4.4?
David Jack added the comment: Thank you for the information. That will definitely be helpful. https://pcoptimizerpro.com/ -- ___ Python tracker <https://bugs.python.org/issue31148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31148] Can we get an MSI installer for something past 3.4.4?
David Jack added the comment: Thank you for the information. That will definitely be helpful. Also, thank you for being so detailed with your explanation. Thank you so much. my name is david. i am provide mac optimizer pro software your mac has been speed slow and malware attack and junk files & more issues solve any time. feel free to reach out at @ +1-866-252-2104 for instant and assured support for any queries regarding the mac optimizer pro Download best mac optimizer pc goto this link and download https://macoptimizerpro.com/ -- nosy: +macoptimizer ___ Python tracker <https://bugs.python.org/issue31148> ___ ___ 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
[issue29595] Expose max_queue_size in ThreadPoolExecutor
Change by Jack Wong : -- nosy: +iforapsy ___ Python tracker <https://bugs.python.org/issue29595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30782] Allow limiting the number of concurrent tasks in asyncio.as_completed
Change by Jack Wong : -- nosy: +iforapsy ___ Python tracker <https://bugs.python.org/issue30782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Jack O'Connor added the comment: Hi Michał, no I haven't done any more work on this since my comments back in April. If you wanted to get started on a PyPI implementation, I think that would be fantastic. I'd be happy to collaborate over email: oconnor...@gmail.com. The branches I linked are still up, but I'm not sure my code will be very useful to someone who actually knows what they're doing :) Larry also had several ideas about how multithreading could fit in (which would be API changes in the Rust case, and forward-looking design work in the C case), and if I get permission from Larry I'll forward those emails. -- ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ 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
[issue25782] CPython hangs on error __context__ set to the error itself
Change by Jack O'Connor : -- nosy: -oconnor663 ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ 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
[issue44745] Manual for python 3.9.6 will not let me search
Jack Humphries added the comment: This may be a build system problem. Building the v3.9.6 tag locally on Windows 10.0.19043 produces a help file that can properly search. On top of that locally built python396.chm file output is 3MB larger (around the same size as the 3.9.5 help file). -- nosy: +distroJack ___ Python tracker <https://bugs.python.org/issue44745> ___ ___ 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
