[issue33528] os.getentropy support

STINNER Victor added the comment: I know two main use cases for random numbers: * security: use os.urandom(), secrets and random.SystemRandom * not security: use the random module Exposing os.getentropy() seems like a new non-portable function for the first use case, security. What does it ad

[issue21145] Add the @cached_property decorator

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue26819] _ProactorReadPipeTransport pause_reading()/resume_reading() broken if called before any read is perfored

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue33501] split existing optimization levels into granular options

STINNER Victor added the comment: I'm not sure that the bug tracker is the best place to propose such idea. Maybe start a new thread on python-ideas? -- ___ Python tracker ___

[issue33341] python3 fails to build if directory or sysroot contains "*icc*" string

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue28584] ICC compiler check is too permissive

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue33341] python3 fails to build if directory or sysroot contains "*icc*" string

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue33531] test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI

STINNER Victor added the comment: Terry: " The Travis retest (for 3.7 backport) just failed with the same errors. Why can't we disable this tests. It now takes hours to do a merge with two backports." Usually, I prefer to try to understand a bug before disabling, even temporarely, a test.

[issue33565] strange tracemalloc results

STINNER Victor added the comment: Once you found and fixed your memory leak, any documentation enhancement is welcome :-) -- ___ Python tracker ___ ___

[issue33565] strange tracemalloc results

STINNER Victor added the comment: tracemalloc doesn't track memory leaks. It tracks memory allocations. I'm not sure that you are using tracemalloc properly. I suggest you to enable tracemalloc as soon as possible, take snapshot frequently (eg. at each iteration) and write them on disk, and l

[issue20104] expose posix_spawn(p)

STINNER Victor added the comment: > I originally removed it from the configure script in PR6794 but it was > reintroduced in commit 57009526f6a405e0ffe8c16012cce509b62cb577. Check the PR > for Greg's rationale. Oh ok. -- ___ Python tracker

[issue19950] Document that unittest.TestCase.__init__ is called once per test

Gregory P. Smith added the comment: New changeset a5f33a899f6450de96f5e4cd154de4486d50bdd7 by Gregory P. Smith (Miss Islington (bot)) in branch '3.6': bpo-19950: Clarify unittest TestCase instance use. (GH-6875) (GH-6939) https://github.com/python/cpython/commit/a5f33a899f6450de96f5e4cd154de44

[issue19950] Document that unittest.TestCase.__init__ is called once per test

Gregory P. Smith added the comment: New changeset 436972e295f5057fe7cdd7312f543c2fa884705d by Gregory P. Smith (Miss Islington (bot)) in branch '3.7': bpo-19950: Clarify unittest TestCase instance use. (GH-6875) (GH-6938) https://github.com/python/cpython/commit/436972e295f5057fe7cdd7312f543c2

[issue19950] Document that unittest.TestCase.__init__ is called once per test

Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> commit review status: open -> closed ___ Python tracker ___

[issue1621] Do not assume signed integer overflow behavior

Martin Panter added the comment: Sorry I haven’t made a PR for ctypes_v2.patch, but I don’t mind if someone else takes over. I understand the HAVE_LONG_LONG check may no longer necessary for newer Python versions. -- ___ Python tracker

[issue33321] Add a Linux clang ubsan undefined behavior sanitizer buildbot

Martin Panter added the comment: Perhaps your “ctypes” problems may be helped by my ctypes_v2.patch in Issue 1621. Or perhaps they are already documented in Issue 15119 and/or Issue 28169. -- nosy: +martin.panter ___ Python tracker

[issue20941] pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'

Martin Panter added the comment: Maybe worth checking if this is fixed due to the changes in Issue 31373 for 3.6+. -- nosy: +martin.panter resolution: -> out of date superseder: -> demoting floating float values to unrepresentable types is undefined behavior ___

[issue20941] pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'

STINNER Victor added the comment: "resolution: out of date" Is this issue fixed or not? It's still open. -- ___ Python tracker ___

[issue20941] pytime.c:184 and pytime.c:218: runtime error, outside the range of representable values of type 'long'

Martin Panter added the comment: I don’t know; I haven’t tested it. I was anticipating that it is fixed, but perhaps I should leave the resolution alone instead? -- ___ Python tracker ___

[issue33499] Environment variable to set alternate location for pycache tree

Carl Meyer added the comment: Cool, thanks for the pointer on -X. PR is updated with `-X bytecode_path=PATH`; don't think it's critical to have it, but it wasn't that hard to add. -- ___ Python tracker _

[issue33575] Python relies on C undefined behavior float-cast-overflow

Benjamin Peterson added the comment: You might want to have a look at #20941. Arguably ubsan is too pendantic in some of these cases. -- nosy: +benjamin.peterson ___ Python tracker __

[issue33528] os.getentropy support

David Carlier added the comment: Those are valid points honestly. OpenBSD's getentropy works that way indeed (getentropy has also been implemented into FreeBSD in the CURRENT branch couple of months ago). So indeed os.urandom provides already a wrapping usage only this one gives the responsib

[issue19251] bitwise ops for bytes of equal length

Nick Coghlan added the comment: I think Antoine's right that another venue (such as python-ideas) might be a better venue for this discussion, but I'll still try to explain the potential analogy I see to bytes.upper()/.lower()/etc: those operations let you treat ASCII segments in otherwise bi

[issue21145] Add the @cached_property decorator

Change by Carl Meyer : -- pull_requests: +6636 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue21145] Add the @cached_property decorator

Carl Meyer added the comment: Sent a PR with the patch. Nick, I tried your `__set_name__` proposal to get an earlier error in case of an object with slots, but it has the downside that Python seems to always raise a new chained exception if `__set_name__` raises any exception. So instead of

[issue21145] Add the @cached_property decorator

Nick Coghlan added the comment: I think it would make sense to remove the exception wrapping from the __set_name__ calls - I don't think we're improving the ease of understanding the tracebacks by converting everything to a generic RuntimeError, and we're hurting the UX of descriptor validati

[issue33576] Remove exception wrapping from __set_name__ calls

New submission from Nick Coghlan : Type creation currently wraps all exceptions raised by __set_name__ calls with a generic RuntimeError: https://github.com/python/cpython/blob/master/Objects/typeobject.c#L7263 Unfortunately, this makes it difficult to use __set_name__ for descriptor validati

[issue21145] Add the @cached_property decorator

Nick Coghlan added the comment: I filed https://bugs.python.org/issue33576 to cover removing the exception wrapping from __set_name__ errors. -- ___ Python tracker ___ ___

[issue33577] remove wrapping of __set_name__ exceptions in RuntimeError

New submission from Carl Meyer : Per Nick Coghlan in discussion on issue21145: "I think it would make sense to remove the exception wrapping from the __set_name__ calls - I don't think we're improving the ease of understanding the tracebacks by converting everything to a generic RuntimeError,

[issue21145] Add the @cached_property decorator

Carl Meyer added the comment: Makes sense to me. Sounds like a separate issue and PR; I filed issue33577 and will work on a patch. -- ___ Python tracker ___ __

[issue33577] remove wrapping of __set_name__ exceptions in RuntimeError

Carl Meyer added the comment: Oops, duplicate of issue33576. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker ___

[issue21145] Add the @cached_property decorator

Carl Meyer added the comment: Oops, never mind; closed mine as dupe. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue33576] Remove exception wrapping from __set_name__ calls

Change by Carl Meyer : -- keywords: +patch pull_requests: +6637 stage: needs patch -> patch review ___ Python tracker ___ ___ Python-

[issue33576] Remove exception wrapping from __set_name__ calls

Carl Meyer added the comment: Nick, I think the reason this exception wrapping was added is because the stack trace for these exceptions is currently a bit lacking. The "caller" for the `__set_name__` function is the `class` line for the class containing the descriptors. For exceptions raise

[issue33565] strange tracemalloc results

Alexander Mohr added the comment: I realize it doesn't track leaks, it's a tool to help find leaks when used correctly :) This example should be similar to using the compare snapshots mechanism as I start tracking from a stable point (several iterations in after a gc), and then compare to an

<    1   2