[issue13355] random.triangular error when low = mode
New submission from Mark :
When low and mode are the same in random.triangular it gives the following
error:
: float division
args = ('float division',)
message = 'float division'
When high and mode are the same there is no problem.
--
components: Extension Modules
messages: 147148
nosy: mark108
priority: normal
severity: normal
status: open
title: random.triangular error when low = mode
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue13355>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13355] random.triangular error when low = mode
Mark added the comment: Many thanks, Mark. I'm very new to python so apologies for my obvious mistake (you were absolutely right, I was feeding the high and mode in back to front). As a separate aside, it would be convenient if low=high=mode returned low (or mode or high) rather than error but it's a minor point really and easy to work around as is. Many thanks for your help. -- ___ Python tracker <http://bugs.python.org/issue13355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3437] robotparser.py missing one line
New submission from mARK <[EMAIL PROTECTED]>: RobotFileParser.parse() contains the lines elif line[0] == "disallow": if state != 0: entry.rulelines.append(RuleLine(line[1], False)) state = 2 elif line[0] == "allow": if state != 0: entry.rulelines.append(RuleLine(line[1], True)) with no 'state = 2' in the 'allow' part. This causes different behaviour depending on whether the file ends with 'allow' or 'disallow', or an empty line. Those lines were taken from revision 65118. My Python 2.5 sources are similar. I have not checked others. -- components: Library (Lib) messages: 70209 nosy: mbloore severity: normal status: open title: robotparser.py missing one line type: behavior versions: Python 2.5, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urllib.urlparse mishandles novel schemes
New submission from mARK :
urlparse.urlsplit('s3://example/files/photos/161565.jpg')
returns
('s3', '', '//example/files/photos/161565.jpg', '', '')
instead of
('s3', 'example', '/files/photos/161565.jpg', '', '')
according to rfc 3986 's3' is a valid scheme name, so the '://' indicates a URL
with netloc and path parts.
--
components: Extension Modules
messages: 99181
nosy: mbloore
severity: normal
status: open
title: urllib.urlparse mishandles novel schemes
type: behavior
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/issue7904>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urllib.urlparse mishandles novel schemes
mARK added the comment: it's not actually necessary to have a list of known schemes. any url that has a double slash after the colon is expected to follow that with an authority section (what urlparse calls "netloc"), optionally followed by a path, which starts with a slash. there are various defined schemes with their own syntax within the URL framework, but one is free to invent new ones with the general form scheme://netloc/path -- ___ Python tracker <http://bugs.python.org/issue7904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urlparse.urlsplit mishandles novel schemes
mARK added the comment: i have attached an svn diff of my (very simple!) fix and added unit test for python 2.7. -- title: urllib.urlparse mishandles novel schemes -> urlparse.urlsplit mishandles novel schemes Added file: http://bugs.python.org/file16212/fix7904.txt ___ Python tracker <http://bugs.python.org/issue7904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urlparse.urlsplit mishandles novel schemes
mARK added the comment: The case which prompted this issue was a purely private set of URLs, sent to me by a client but never sent to Amazon or anywhere else outside our systems (though I'm sure many others have invented this particular scheme for their own use). It would have been convenient if urlparse had handled it properly. That is true for any scheme one may invent at need. On second thought it does make sense to enforce the use of :// for the schemes in uses_netloc, but still not to ignore its meaning for other schemes. It also makes sense to add s3 to uses_netloc despite the fact that it is not (afaik) registered, since it is an obvious invention. I'll make another patch, but I don't have time to do it just now. -- components: +Extension Modules -Library (Lib) versions: -Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urlparse.urlsplit mishandles novel schemes
Changes by mARK : -- components: +Library (Lib) -Extension Modules versions: +Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7904] urlparse.urlsplit mishandles novel schemes
mARK added the comment: Doing a fallback test for // would look like if scheme in uses_netloc and url[:2] == '//' or url[:2] == '//': but this is equivalent to if url[:2] == '//': i.e., an authority appears if and only if there is a // after the scheme. This still allows a uses_netloc scheme to appear without //. I have attached a patch against Python 2.7, svn revision 78212. It adds s3 to netloc. -- Added file: http://bugs.python.org/file16246/fix7904-2.txt ___ Python tracker <http://bugs.python.org/issue7904> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38741] Definition of multiple ']' in header configparser
New submission from Mark : in example header is "[i love [python] lang]" parse as "i love [python", only up to the first character ']'. now saving works correctly, but reading does not -- messages: 356225 nosy: @mark99i priority: normal severity: normal status: open title: Definition of multiple ']' in header configparser type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45134] Protocol dealloc not called if Server is closed
New submission from Mark : If I create_server server_coro = loop.create_server( lambda: self._protocol_factory(self), sock=sock, ssl=ssl) server = loop.run_until_complete(server_coro) Then connect and disconnect a client the protocol connection lost and dealloc are called. If however I close the server with existing connections then protocol dealloc is never called and I leak memory due to a malloc in my protocol.c init. server.close() loop.run_until_complete(server.wait_closed()) -- components: asyncio messages: 401349 nosy: MarkReedZ, asvetlov, yselivanov priority: normal severity: normal status: open title: Protocol dealloc not called if Server is closed type: resource usage versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue45134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45134] Protocol dealloc not called if Server is closed
Change by Mark : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29926] time.sleep ignores keyboard interrupt in IDLE
New submission from Mark: Consider the following code, typed interactively: >>> import time >>> time.sleep(1e6) This will sleep for a bit over one and a half weeks. If this was typed in error, you may want to interrupt it. If using the command line, this is easy: just use Ctrl-C. If using IDLE, Ctrl-C has no effect. One could attempt to restart the shell with Ctrl-F6, which seems to work, but in fact the process remains in the background, hung until the timeout expires. There are two obvious workarounds: one is to sleep in a separate thread, so as to avoid blocking the main thread, and the other is to use a loop with smaller sleep increments: for ii in range(1e5): sleep(10) Now it only takes 10 seconds to interrupt a sleep. But these are both clumsy workarounds. They're so clumsy that I think I'm not going to use IDLE for this particular program and just use python -I. Would be nice if this were fixed. -- assignee: terry.reedy components: IDLE messages: 290663 nosy: Mark, terry.reedy priority: normal severity: normal status: open title: time.sleep ignores keyboard interrupt in IDLE versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue29926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32362] multiprocessing.connection.Connection misdocumented as multiprocessing.Connection
New submission from Mark : https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Connection purports to document the multiprocessing.Connection class. There's no such thing: Python 3.6.1 (v3.6.1:69c0db5050, Mar 21 2017, 01:21:04) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing >>> multiprocessing.Connection Traceback (most recent call last): File "", line 1, in AttributeError: module 'multiprocessing' has no attribute 'Connection' I think it should be multiprocessing.connection.Connection? -- assignee: docs@python components: Documentation messages: 308539 nosy: Amery, docs@python priority: normal severity: normal status: open title: multiprocessing.connection.Connection misdocumented as multiprocessing.Connection versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15262] Idle does not show traceback in other threads
New submission from Mark : Consider the following code: from thread import start_new def f(): typo #there is no variable called typo start_new(f, ()) If run from the command line, this produces a traceback. If run from IDLE, it does not. I suspect this is not by design. This caused me endless grief in debugging until one happy day I discovered the traceback module. I now write: from thread import start_new from traceback import print_exc def f(): try: typo except: print_exc() start_new(f, ()) this works, but I wish I didn't need it. -- components: IDLE messages: 164718 nosy: Mark priority: normal severity: normal status: open title: Idle does not show traceback in other threads type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue15262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15262] Idle does not show traceback in other threads
Mark added the comment: So, I should not hold my breath in the hope of this being fixed in 2.7? -- ___ Python tracker <http://bugs.python.org/issue15262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15262] Idle does not show traceback in other threads
Mark added the comment: Yay! I can't wait :) -- ___ Python tracker <http://bugs.python.org/issue15262> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4108] robotparser.py fail when more than one User-Agent: * is present
mARK added the comment: this looks like a good fix. i've put it into my own copy. -- nosy: +mbloore ___ Python tracker <http://bugs.python.org/issue4108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29317] test_copyxattr_symlinks fails
New submission from mark: == ERROR: test_copyxattr_symlinks (test.test_shutil.TestShutil) -- Traceback (most recent call last): File "/opt/Python-3.6.0/Lib/test/test_shutil.py", line 505, in test_copyxattr_symlinks os.setxattr(src, 'trusted.foo', b'42') PermissionError: [Errno 1] Operation not permitted: '/tmp/tmpvlu10qdm/foo' -- The problem is that "trusted" attributes (in this case trusted.foo) are visible and accessible only to processes that have the CAP_SYS_ADMIN capability. The current "skipUnless" guard is wrong: being root (UID 0) doesn't necessarely imply you have CAP_SYS_ADMIN. For instance this test (and thus "make test") will always fail in a Docker container unless it's started with "--cap-add SYS_ADMIN" (which, in general, is not the best thing to do). -- components: Tests messages: 285764 nosy: marktay priority: normal severity: normal status: open title: test_copyxattr_symlinks fails versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue29317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27324] Error when building Python extension
New submission from Mark: I'd like to build a C++ extension for Python. I took a simple C file from a tutorial and wrote the setup.py file. But when I run the command: python setup.py build_ext --inplace I get the following error: error: Unable to find vcvarsall.bat This file is located in "c:\Program Files (x86)\Microsoft Visual Studio 12.0\vc\vcvarsall.bat" but even when I run it and set all environment variables, python.exe still tries to find it. I added this path to the PATH but it didn't solve the issue. -- components: Distutils messages: 268612 nosy: Mark53, dstufft, eric.araujo priority: normal severity: normal status: open title: Error when building Python extension type: compile error versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27324] Error when building Python extension
Mark added the comment: Hi Zach, Well, the strange thing is that other members of my team have successfully built C++ Python extensions with Visual Studio 13, but they compiled and built the pyd file with CMake (one used SWIG). So, it is possible. I just wanted to do it in a simpler way. Regards, Mark Message d'origine De : Zachary Ware À : tib...@netcourrier.com Objet : [issue27324] Error when building Python extension Date : 15/06/2016 15:42:36 CEST Zachary Ware added the comment: Hi Mark, To build Python extensions on Windows, you need to have a compiler that can link to the same C runtime used by the Python interpreter. For 3.5, that means you need VS2015; VS2013 won't work. -- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue27324> ___ -- ___ Python tracker <http://bugs.python.org/issue27324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27324] Error when building Python extension
Mark added the comment: The problem is that I don't have the choice, the compiler we use for the project is VS13. Anyway, my colleagues are aware of this limitation but they could build their extensions all the same. I set the variables as you recommended, and the obj files have been created. But the link fails with the following error: LINK : fatal error LNK1181: impossible to open the input file 'ucrt.lib' This library does not exist in my VS13 environment. Message d'origine De : Zachary Ware À : tib...@netcourrier.com Objet : [issue27324] Error when building Python extension Date : 15/06/2016 18:54:39 CEST Zachary Ware added the comment: Using the wrong compiler, you may wind up with an extension that appears to work, and you may never have a problem with it if conditions are just right. This article[1] looks like a pretty good explanation of why you don't want to do it, though (note: I've only skimmed the article). If you really want to shoot yourself in the foot, you can try running vcvarsall.bat yourself, then make sure MSsdk is set (distutils doesn't care what it's set to, just that it's set), and set DISTUTILS_USE_SDK (again, doesn't matter to what). Also, note that this problem should be a thing of the past with Python 3.5+ and VS2015+. [1] http://siomsystems.com/mixing-visual-studio-versions/ -- ___ Python tracker <http://bugs.python.org/issue27324> ___ -- ___ Python tracker <http://bugs.python.org/issue27324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package
Mark added the comment: I have the same problem on a standard installation of Python 3.5 (on OS X via Homebrew). This bug is almost a year old, and it is a doozy: it utterly defeats the purpose of --system-site-packages. In the hope of getting some momentum going, I tried out the option suggested by dstufft: adding --ignore-installed in ensurepip's bootstrap() does seem to fix the problem. I've never contributed a patch to Python before so I've probably screwed this up, but I'm attaching a patch that applies against latest python 3.5 on github (1b279c2). Sorry, I don't know what the equivalent Hg hash is, but this is a pretty minimal patch so it should be easy to apply. -- keywords: +patch nosy: +mehaase versions: +Python 3.5 Added file: http://bugs.python.org/file43880/0001-Fix-issue-24875.patch ___ Python tracker <http://bugs.python.org/issue24875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds
Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46039] Break up the YIELD_FROM instruction.
New submission from Mark Shannon : The YIELD_FROM instruction does three things: * It sends a value to the sub-iterator * It yields the value from the sub-iterator back up to its caller * Loops back on itself So we should implement this as: SEND<--+ YIELD_VALUE| JUMP_ABSOLUTE -+ Doing so would allow us to simplify gen.send and gen.throw as they wouldn't need all the special cases for 'yield from'. Zero cost exception handling allows us to handle throw in the bytecode with no runtime overhead: while True: SEND -> exit try: YIELD_VALUE except BaseException as ex: sub_iterator.throw(ex) exit: -- assignee: Mark.Shannon components: Interpreter Core messages: 408232 nosy: Mark.Shannon priority: normal severity: normal status: open title: Break up the YIELD_FROM instruction. versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46039] Break up the YIELD_FROM instruction.
Change by Mark Shannon : -- keywords: +patch pull_requests: +28260 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30035 ___ Python tracker <https://bugs.python.org/issue46039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
New submission from Mark Shannon : By "stats" I mean the internal numbers gathered by the VM for performance and debugging. This has nothing to do with any statistics module. Currently various parts of the VM gather stats: the GC, dicts, the bytecode interpreter, type lookup cache, etc. These stats have various compile time flags to turn them on and off. They have differing ways to display the stats, and no unified way to gather stats across different runs. For the specialization stats we dump stats, which we can parse to collate stats across runs. We should: 1. Add a --with-pystats config flag (like with-pydebug) to turn on stat gathering at build time. 2. Convert the other stats to the format used by the specialization stats, so all stats can be parsed and collated. -- messages: 408543 nosy: Mark.Shannon priority: normal severity: normal status: open title: Unify handling of stats in the CPython VM ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Mark Shannon added the comment: New changeset 9f8f45144b6f0ad481e80570538cce89b414f7f9 by Mark Shannon in branch 'main': bpo-44525: Split calls into PRECALL and CALL (GH-30011) https://github.com/python/cpython/commit/9f8f45144b6f0ad481e80570538cce89b414f7f9 -- ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Change by Mark Shannon : -- pull_requests: +28329 pull_request: https://github.com/python/cpython/pull/30107 ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45292] Implement PEP 654: Exception Groups
Mark Shannon added the comment: PR 29581 resulted in a 1% slowdown, which is not terrible, but code not using except* should not be slowed down at all. IMO, the way to avoid the slowdown is to implement except* using the existing instruction set (perhaps with a few minor additions) We already implement try-finally, named except blocks and with statements without any complex bytecodes (except perhaps WITH_EXCEPT_START). These used to involve a lot of state and more complex bytecodes. So it is possible to make these simplifications, but it does take work. There are a number of techniques we can use: If any state is needed, push it to the stack as we do with `ctx.__exit__` in the with statement, and when pushing f_lasti in exception handlers. Duplicate code paths when the semantics differ in different cases, as we do for finally blocks. If anything is too complex to handle on the stack, put it in a temporary variable. Be liberal in your use of virtual try-excepts (SETUP_FINALLY, POP_FINALLY pairs), as zero-cost exception handling should keep the cost down. It may be too late for this advice, but if I were writing the `except*` implementation from scratch, I would: 1. Sketch out the pseudo Python that a try-except* would map to. This is a good opportunity to discover any design bugs that might result in undesirable behavior for corner cases. 2. Implement the translation in the compiler, not worrying about any redundancy or inefficiency, just correctness. 3. Look to improve the above, either in the compiler front-end, or by replacing inefficient code patterns in the back-end. Handling the optimization in the backend has the advantage that other code might benefit as well. -- ___ Python tracker <https://bugs.python.org/issue45292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46039] Break up the YIELD_FROM instruction.
Mark Shannon added the comment: New changeset 0b50a4f0cdee41a18fb4ba6e75569f9cfaceb39e by Mark Shannon in branch 'main': bpo-46039: Split yield from in two (GH-30035) https://github.com/python/cpython/commit/0b50a4f0cdee41a18fb4ba6e75569f9cfaceb39e -- ___ Python tracker <https://bugs.python.org/issue46039> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Change by Mark Shannon : -- keywords: +patch pull_requests: +28338 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30116 ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Mark Shannon added the comment: New changeset 3a60bfef49b3324660a615a8e6d10710e5f669d9 by Mark Shannon in branch 'main': bpo-44525: Specialize for calls to type and other builtin classes with 1 argument. (GH-29942) https://github.com/python/cpython/commit/3a60bfef49b3324660a615a8e6d10710e5f669d9 -- ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Mark Shannon added the comment: New changeset 342b93f9f28746abb7b221a61d5a9b26ccbb395a by Mark Shannon in branch 'main': bpo-46072: Add --with-pystats configure option to simplify gathering of VM stats (GH-30116) https://github.com/python/cpython/commit/342b93f9f28746abb7b221a61d5a9b26ccbb395a -- ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46006] [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subinterpreters
Mark Shannon added the comment: The problem here is that different sub-interpreters have different strings for the same Python string. Unless sub-interpreters are fully independent, and they cannot be due to limitations imposed by the stable API, then all sub-interpreters must share the same poll of strings. Since the only object reachable from a string is the `str` object (which is a static global object `PyUnicode_Type`), then the invariant that no object that is unique to one sub-interpreter can be reached from another sub-interpreter remains valid if strings are shared. I.e. there is no reason not to share strings. As Victor points out, there is no bug in 3.9 because interned strings are common across all interpreter. We should revert that behavior. -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/issue46006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46097] Split function versions into 1-0xffff and 0x1000+ regions
New submission from Mark Shannon : Because functions are mutable, specifically because the __code__ attribute is mutable, we need to version functions when specializing. However, some specializations (for special methods mainly) only have space for 16 bit versions. It is likely that programs will have more than 2**16 functions versions, but it is much less likely that they will have more than 2**16 versions of special methods. We should partition the version space into 1-0x for use by special methods and 0x1000+ for use by other methods. See https://github.com/python/cpython/pull/30129 for an example of why this is needed. -- components: Interpreter Core messages: 408686 nosy: Mark.Shannon, brandtbucher priority: normal severity: normal status: open title: Split function versions into 1-0x and 0x1000+ regions type: performance versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45829] Remove C stack use by specializing BINARY_SUBSCR, STORE_SUBSCR, LOAD_ATTR, and STORE_ATTR
Mark Shannon added the comment: New changeset 62a8a0c5223f750e22ee381d3cfbdb718cf1cc93 by Brandt Bucher in branch 'main': bpo-45829: Check `__getitem__`'s version for overflow before specializing (GH-30129) https://github.com/python/cpython/commit/62a8a0c5223f750e22ee381d3cfbdb718cf1cc93 -- ___ Python tracker <https://bugs.python.org/issue45829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Change by Mark Shannon : -- pull_requests: +28357 pull_request: https://github.com/python/cpython/pull/30139 ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Mark Shannon added the comment: New changeset 4506bbede1644e985991884964b43afa7ee6f609 by Mark Shannon in branch 'main': bpo-46072: Document --enable-stats option. (GH-30139) https://github.com/python/cpython/commit/4506bbede1644e985991884964b43afa7ee6f609 -- ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Mark Shannon added the comment: The --enable-stats option is for CPython development and shouldn't be turned on for a release version, so I'm not really concerned about people attacking their own machines. -- ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Change by Mark Shannon : -- pull_requests: +28363 pull_request: https://github.com/python/cpython/pull/30145 ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Mark Dickinson added the comment: > "The mean is strongly affected by outliers and is not necessarily a typical > example of the data points. For a more robust, although less efficient, > measure of central tendency, see median()" That wording sounds fine to me. I don't think we can reasonably expect to hear from Jake again, but from my understanding of his post, this addresses his concerns. FWIW, I share those concerns. My brain can't parse "robust estimator for central location", because the term "estimator" has a precise and well-defined meaning in (frequentist) statistics, and what I expect to see after "estimator for" is a description of a parameter of a statistical model - as in for example "estimator for the population mean", or "estimator for the Weibull shape parameter". "central location" doesn't really fit in that slot. > How do we feel about linking to Wikipedia? I can't think of any good reason not to. We have plenty of other external links in the docs, and the Wikipedia links are probably at lower risk of becoming stale than most of the others. -- ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Change by Mark Shannon : -- pull_requests: +28386 pull_request: https://github.com/python/cpython/pull/30169 ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45711] Simplify the interpreter's (type, val, tb) exception representation
Mark Shannon added the comment: New changeset 396b58345f81d4c8c5a52546d2288e666a1b9b8b by Irit Katriel in branch 'main': bpo-45711: Remove type and traceback from exc_info (GH-30122) https://github.com/python/cpython/commit/396b58345f81d4c8c5a52546d2288e666a1b9b8b -- ___ Python tracker <https://bugs.python.org/issue45711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46072] Unify handling of stats in the CPython VM
Mark Shannon added the comment: New changeset efd6236d36b292c2c43540132c87cf8425e8d627 by Mark Shannon in branch 'main': bpo-46072: Add top level stats struct (GH-30169) https://github.com/python/cpython/commit/efd6236d36b292c2c43540132c87cf8425e8d627 -- ___ Python tracker <https://bugs.python.org/issue46072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Change by Mark Dickinson : -- pull_requests: +28390 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30174 ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Mark Dickinson added the comment: Steven: I've made a PR at https://github.com/python/cpython/pull/30174. Does this match what you had in mind? -- ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45995] string formatting: normalize negative zero
Change by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker <https://bugs.python.org/issue45995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45995] string formatting: normalize negative zero
Mark Dickinson added the comment: Thanks, John. I should have time to review within the next week or so. -- ___ Python tracker <https://bugs.python.org/issue45995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: > we can get faster code by using a small (3Kb) table of factorial logarithms The problem here is that C gives no guarantees about accuracy of either log2 or exp2, so we'd be playing a guessing game about how far we can go before the calculation becomes unsafe (in the sense of the `round` operation potentially giving the wrong answer). I think it would be better to stick to integer-only arithmetic. -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment:
One approach that avoids the use of floating-point arithmetic is to precompute
the odd part of the factorial of n modulo 2**64, for all small n. If we also
precompute the inverses, then three lookups and two 64x64->64 unsigned integer
multiplications gets us the odd part of the combinations modulo 2**64, hence
for small enough n and k gets us the actual odd part of the combinations.
Then a shift by a suitable amount gives comb(n, k).
Here's what that looks like in Python. The "% 2**64" operation obviously
wouldn't be needed in C: we'd just do the computation with uint64_t and rely on
the normal wrapping semantics. We could also precompute the bit_count values if
that's faster.
import math
# Max n to compute comb(n, k) for.
Nmax = 67
# Precomputation
def factorial_odd_part(n):
f = math.factorial(n)
return f // (f & -f)
F = [factorial_odd_part(n) % 2**64 for n in range(Nmax+1)]
Finv = [pow(f, -1, 2**64) for f in F]
PC = [n.bit_count() for n in range(Nmax+1)]
# Fast comb for small values.
def comb_small(n, k):
if not 0 <= k <= n <= Nmax:
raise ValueError("k or n out of range")
return (F[n] * Finv[k] * Finv[n-k] % 2**64) << k.bit_count() +
(n-k).bit_count() - n.bit_count()
# Exhaustive test
for n in range(Nmax+1):
for k in range(0, n+1):
assert comb_small(n, k) == math.comb(n, k)
--
___
Python tracker
<https://bugs.python.org/issue37295>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46144] math.log() returns improper output
Mark Dickinson added the comment: Yes, confirmed that this is not a bug, but just one of the many consequences of approximating real numbers by floating-point numbers. You may be interested in math.log2 and/or int.bit_length. math.log2(x) *may* give you more accurate results than math.log(x, 2) when x is a power of two, but there are no guarantees - we're at the mercy of the C math library here. -- nosy: +mark.dickinson resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue46144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: That computation of the shift can be simplified to require only one popcount operation. With F and Finv as before: def comb_small(n, k): assert 0 <= k <= n <= Nmax return (F[n] * Finv[k] * Finv[n-k] % 2**64) << (k ^ n ^ (n-k)).bit_count() -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Change by Mark Dickinson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: [Tim] > The justification for the shift count isn't self-evident, and > appears to me to be an instance of the generalization of Kummer's > theorem to multinomial coefficients. Not sure there's any generalisation here: I think it *is* just Kummer's theorem. Though I confess I wasn't aware that this was a named theorem - I was working directly from what I now discover is called [Legendre's formula](https://en.wikipedia.org/wiki/Legendre%27s_formula), which I originally learned from "Concrete Mathematics" by Knuth et. al., where they also didn't mention any particular names. It's equation 4.24 in my edition; it may have a different number in the 2nd edition. Kummer's theorem says that the 2-valuation of n-choose-k is the number of carries when k is added to n-k in binary. Notation: write `bit(x, i)` for the bit at position `i` of `x` - i.e., `(x >> i) & 1` In the absence of carries when adding `k` to `n-k`, `bit(n, i) = bit(k, i) ^ bit(n-k, i)`. We have an incoming carry whenever `bit(n, i) != bit(k, i) ^ bit(n-k, i)`; i.e., whenever `bit(n ^ k ^ (n-k), i)` is `1`. So the number of carries is the population count of `n ^ k ^ (n-k)`. > I think it would be clearer at first sight to rely instead on that 2**i/(2**j > * 2**k) = 2**(i-j-k), which is shallow. Sounds fine to me, especially if it makes little performance difference. -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC
Mark Dickinson added the comment: > This should probably be a separate issue, Specifically, issue 45569. -- ___ Python tracker <https://bugs.python.org/issue35037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20369] concurrent.futures.wait() blocks forever when given duplicate Futures
Change by Mark Dickinson : -- nosy: -mark.dickinson ___ Python tracker <https://bugs.python.org/issue20369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46055] Speed up binary shifting operators
Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker <https://bugs.python.org/issue46055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46055] Speed up binary shifting operators
Change by Mark Dickinson : -- keywords: +patch pull_requests: +28464 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30243 ___ Python tracker <https://bugs.python.org/issue46055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: Raymond: how do you want to proceed on this? Should I code up my suggestion in a PR, or are you already working on it? -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46173] float(x) with large x not raise OverflowError
Mark Dickinson added the comment: Yes, exactly: Python's intentionally following the normal IEEE 754 rules for rounding a value to the binary64 format using the round-ties-to-even rounding rule, as formalised in section 7.4 of IEEE 754-2019 (and quoted by @cykerway). These are the exact same rules that are followed for conversion from str to float (where we return `inf` rather than raise `OverflowError` for large values, but the overflow boundary is the same), or conversion from Fraction to float, or conversion from Decimal to float, etc. > the python float doc might better say "If the *rounded* argument is > outside..." Docs are hard. I think there's a danger that that word "rounded" would cause more confusion than it alleviates - to me, it suggests that there's some kind of rounding going on *before* conversion to float, rather than *as part of* the conversion to float. This isn't a language specification document, so it's not reasonable to give a perfectly accurate description of what happens - the actual meaning would be lost in the mass of details. (In this case, it would also be rather hard to be precise, given that we have to allow for platforms that aren't using IEEE 754.) I'm not seeing an obvious way to improve the docs here. -- ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46173] float(x) with large x not raise OverflowError
Mark Dickinson added the comment: If we wanted to make a change, I think the part of the docs that I'd target would be this sentence: > a floating point number with the same value (within Python’s floating point > precision) is returned It's that "same value (within Python's floating point precision)" bit that I'd consider changing. We could consider replacing it with something along the lines that "an integer argument is rounded to the nearest float", possibly with an additional note that under the assumption of IEEE 754 binary64 format, we follow the usual IEEE 754 rules. -- ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46173] float(x) with large x not raise OverflowError
Change by Mark Dickinson : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46173] Clarify conditions under which float(x) with large x raises OverflowError
Mark Dickinson added the comment: Changing to a documentation issue. -- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python resolution: not a bug -> title: float(x) with large x not raise OverflowError -> Clarify conditions under which float(x) with large x raises OverflowError versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Change by Mark Dickinson : -- pull_requests: +28490 pull_request: https://github.com/python/cpython/pull/30275 ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46055] Speed up binary shifting operators
Mark Dickinson added the comment: New changeset 360fedc2d2ce6ccb0dab554ef45fe83f7aea1862 by Mark Dickinson in branch 'main': bpo-46055: Streamline inner loop for right shifts (#30243) https://github.com/python/cpython/commit/360fedc2d2ce6ccb0dab554ef45fe83f7aea1862 -- ___ Python tracker <https://bugs.python.org/issue46055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46055] Speed up binary shifting operators
Mark Dickinson added the comment: New changeset 3581c7abbe15bad6ae08fc38887e5948f8f39e08 by Xinhang Xu in branch 'main': bpo-46055: Speed up binary shifting operators (GH-30044) https://github.com/python/cpython/commit/3581c7abbe15bad6ae08fc38887e5948f8f39e08 -- ___ Python tracker <https://bugs.python.org/issue46055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46055] Speed up binary shifting operators
Mark Dickinson added the comment: Two separate significant improvements have been pushed: thanks, Xinhang Xu! The original PR also contained a reworking of the general case for right-shifting a negative integer. The current code (in main) for that case does involve some extra allocations, and it ought to be possible to write something that doesn't need to allocate temporary PyLongs. -- ___ Python tracker <https://bugs.python.org/issue46055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Mark Dickinson added the comment: FWIW, when this need has turned up for me (which it has, a couple of times), I've used this: def risqrt(n): return (isqrt(n<<2) + 1) >> 1 But I'll admit that that's a bit non-obvious. -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46055] Speed up binary shifting operators
Change by Mark Dickinson : -- pull_requests: +28493 pull_request: https://github.com/python/cpython/pull/30277 ___ Python tracker <https://bugs.python.org/issue46055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: New changeset 02b5417f1107415abaf81acab7522f9aa84269ea by Mark Dickinson in branch 'main': bpo-37295: Speed up math.comb(n, k) for 0 <= k <= n <= 67 (GH-30275) https://github.com/python/cpython/commit/02b5417f1107415abaf81acab7522f9aa84269ea -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46203] Add timeout for Windows build steps
New submission from Mark Dickinson : Recently there was an upstream issue with GitHub Actions that caused the Windows build steps in build.yml to hang. No output for the step was displayed in the build logs until the entire job was eventually cancelled, after the default step timeout of 6 hours. I don't know how to fix the "no output" problem, but we can mitigate the 6 hour wait by adding a timeout for the build step. Some external discussion suggested that a conservative timeout of 30 minutes would be appropriate; looking at recent PRs, the build usually completes in around 5 minutes. The (soon-to-be-)attached PR adds that timeout. Here's the log from one of the failed jobs: https://github.com/python/cpython/runs/4641823914?check_suite_focus=true (note that this link will probably eventually become invalid). Here's the relevant GitHub incident: https://www.githubstatus.com/incidents/gh0vvxtlj5v7 -- messages: 409359 nosy: christian.heimes, mark.dickinson, steve.dower priority: normal severity: normal status: open title: Add timeout for Windows build steps versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46203] Add timeout for Windows build steps
Change by Mark Dickinson : -- keywords: +patch pull_requests: +28513 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30301 ___ Python tracker <https://bugs.python.org/issue46203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: > So which of xor-popcount and add-up-up-trailing-zero-counts is faster may > well depend on platform. I ran some timings for comb(k, 67) on my macOS / Intel MacBook Pro, using timeit to time calls to a function that looked like this: def f(comb): for k in range(68): for _ in range(256): comb(k, 67) comb(k, 67) ... # 64 repetitions of comb(k, 67) in all Based on 200 timings of this script with each of the popcount approach and the uint8_t-table-of-trailing-zero-counts approach (interleaved), the popcount approach won, but just barely, at around 1.3% faster. The result was statistically significant (SciPy gave me a result of Ttest_indResult(statistic=19.929941828072433, pvalue=8.570975609117687e-62)). Interestingly, the default build on macOS/Intel is _not_ using the dedicated POPCNT instruction that arrived with the Nehalem architecture, presumably because it wants to produce builds that will still be useable on pre-Nehalem machines. It uses Clang's __builtin_popcount, but that gets translated to the same SIMD-within-a-register approach that we have already in pycore_bitutils.h. If I recompile with -msse4.2, then the POPCNT instruction *is* used, and I get an even more marginal improvement: a 1.7% speedup over the lookup-table-based version. -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Mark Dickinson added the comment: > did you invent this? The idea is no more than: "compute an extra bit, then use that extra bit to determine which way to round". More generally, for any real number x, the nearest integer to x (rounding ties towards +infinity) is `⌊(⌊2x⌋ + 1) / 2⌋`. Now put x = √n, then ⌊2x⌋ is ⌊√(4n)⌋, and the rest follows. -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Mark Dickinson added the comment: > I'd be happy to see recipes added to the docs for rounded and ceiling flavors > of isqrt, but am dubious about the value of building them in. I'd similarly prefer to see recipes in the docs. We already have such a recipe for ceil(√n). -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45569] Drop support for 15-bit PyLong digits?
Mark Dickinson added the comment: I posted a request for information on usage of 15-bit digits to python-dev: https://mail.python.org/archives/list/python-...@python.org/thread/ZICIMX5VFCX4IOFH5NUPVHCUJCQ4Q7QM/ -- ___ Python tracker <https://bugs.python.org/issue45569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: > I'm assuming you meant to write comb(67, k) instead Aargh! That is of course what I meant, but not in fact what I timed. :-( I'll redo the timings. Please disregard the previous message. -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: Thanks Tim for spotting the stupid mistake. The reworked timings are a bit more ... plausible. tl;dr: On my machine, Raymond's suggestion gives a 2.2% speedup in the case where POPCNT is not available, and a 0.45% slowdown in the case that it _is_ available. Given that, and the fact that a single-instruction population count is not as readily available as I thought it was, I'd be happy to change the implementation to use the trailing zero counts as suggested. I'll attach the scripts I used for timing and analysis. There are two of them: "timecomb.py" produces a single timing. "driver.py" repeatedly switches branches, re-runs make, runs "timecomb.py", then assembles the results. I ran the driver.py script twice: once with a regular `./configure` step, and once with `./configure CFLAGS="-march=haswell"`. Below, "base" refers to the code currently in master; "alt" is the branch with Raymond's suggested change on it. Output from the script for the normal ./configure Mean time for base: 40.130ns Mean for alt: 39.268ns Speedup: 2.19% Ttest_indResult(statistic=7.9929245698581415, pvalue=1.4418376402220854e-14) Output for CFLAGS="-march=haswell": Mean time for base: 39.612ns Mean for alt: 39.791ns Speedup: -0.45% Ttest_indResult(statistic=-6.75385578636895, pvalue=5.119724894191512e-11) -- Added file: https://bugs.python.org/file50530/timecomb.py ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Change by Mark Dickinson : Added file: https://bugs.python.org/file50531/driver.py ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45569] Drop support for 15-bit PyLong digits?
Change by Mark Dickinson : -- keywords: +patch pull_requests: +28519 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30306 ___ Python tracker <https://bugs.python.org/issue45569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45569] Drop support for 15-bit PyLong digits?
Mark Dickinson added the comment: Terry: > create a fake test file test/test_xintperf [...] Sounds reasonable, though I'm not sure I know what exact timings I'd want to try. Maybe some of the stock integer-heavy Python benchmarks (pidigits, etc.). I realised that I have no idea whether any of the buildbots actually use 15-bit digits. I've created PR GH-30306 to find out. -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue45569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45569] Drop support for 15-bit PyLong digits?
Mark Dickinson added the comment: > I've created PR GH-30306 to find out. Results: we have two Gentoo/x86 buildbots, and a 32-bit Windows build in GitHub Actions: those machines use 15-bit digits, as a result of the logic in pyport.h that chooses 15-bit digits if SIZEOF_VOID_P < 8. Everything else seems to be using 30-bit digits. GPS pointed out in the python-dev discussion that the other platform we should be thinking about is 32-bit ARM. -- ___ Python tracker <https://bugs.python.org/issue45569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Change by Mark Dickinson : -- pull_requests: +28529 pull_request: https://github.com/python/cpython/pull/30313 ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: > I'd be happy to change the implementation to use the trailing zero counts as > suggested. Done in GH-30313 (though this will conflict with Serhiy's PR). -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Mark Dickinson added the comment: A new function isqrt_rem seems like a reasonably natural addition. (Though I'd call it "isqrtrem", partly by analogy with "divmod", and partly because the math module isn't very good at doing underscores.) -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46187] Optionally support rounding for math.isqrt()
Mark Dickinson added the comment: > Mark didn't mention his use case for rounded isqrt Mainly for emulation of floating-point sqrt. But the number of times I've needed rounded integer square root is small compared with the number of times I've needed rounded integer division. -- ___ Python tracker <https://bugs.python.org/issue46187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Mark Dickinson added the comment: New changeset 0b58bac3e7877d722bdbd3c38913dba2cb212f13 by Mark Dickinson in branch 'main': bpo-37295: More direct computation of power-of-two factor in math.comb (GH-30313) https://github.com/python/cpython/commit/0b58bac3e7877d722bdbd3c38913dba2cb212f13 -- ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46199] Calculation influenced by print
Mark Dickinson added the comment: When you do: FINUB = np.empty(len(close)) FINLB = np.empty(len(close)) you're creating two *uninitialised* arrays of values. (See the NumPy documentation at https://numpy.org/doc/stable/reference/generated/numpy.empty.html.) When you then do FINUB[i] = UB[i] if UB[i] < FINUB[i-1] \ and close[i-1] > FINUB[i] else FINUB[i-1] on the first iteration of the loop (i = 1), you make use of the (undefined) value in FINUB[0] to compute FINUB[1]. In other words, this is a bug in your code, rather than in Python or NumPy. -- nosy: +mark.dickinson resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46020] Optimize long_pow for the common case
Change by Mark Dickinson : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue46020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45923] Improve performance of sys.settracing based tools.
Change by Mark Shannon : -- keywords: +patch pull_requests: +28578 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30364 ___ Python tracker <https://bugs.python.org/issue45923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46202] remove opcode POP_EXCEPT_AND_RERAISE
Mark Shannon added the comment: New changeset a94461d7189d7f1147ab304a332c8684263dc17e by Irit Katriel in branch 'main': bpo-46202: Remove opcode POP_EXCEPT_AND_RERAISE (GH-30302) https://github.com/python/cpython/commit/a94461d7189d7f1147ab304a332c8684263dc17e -- nosy: +Mark.Shannon ___ Python tracker <https://bugs.python.org/issue46202> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46258] Minor algorithmic improvements for math.isqrt
New submission from Mark Dickinson : There are a couple of minor algorithmic improvements possible for the math.isqrt fast path (which is used for nonnegative integers smaller than 2**64). On my machine those improvements produce a little over a 10% speedup. The current algorithm for values under 2**64 involves exactly four division instructions, corresponding to four Newton steps. The proposal is to: - 1. Replace the first division with a table lookup. The necessary table is extremely small: 12 entries at one byte per entry. - 2. Arrange for the return type of the _approximate_sqrt helper function to be uint32_t rather than uint64_t. That means that the correction step only involves a 32-bit-by-32-bit multiplication, not a 64-bit-by-64-bit multiplication. The second part is a bit subtle: the input to _approximate_sqrt is a 64-bit integer `n` in the range [2**62, 2**64). Barring any overflow, the output `u` is guaranteed to satisfy `(u-1)**2 < n < (u+1)**2`. That implies that `(u-1)**2 < 2**64`, from which it follows that `u <= 2**32`. So the only possible case where `u` might overflow a `uint32_t` is when `u == 2**32`. But from the earlier inequality, that can only happen if `n > (2**32 - 1)**2`, and in that case the top 31 bits of `n` are completely determined and since the first steps of the algorithm only depend on the topmost bits of `n`, it's easy to follow through the algorithm and see that it's not possible for `u` to be `2**32` in that case. (We always get `u = 128` from the lookup, followed by `u = 255` after the first division, then `u = 65536` after the second.) -- components: Extension Modules messages: 409693 nosy: mark.dickinson priority: normal severity: normal stage: commit review status: open title: Minor algorithmic improvements for math.isqrt type: performance versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46258] Minor algorithmic improvements for math.isqrt
Change by Mark Dickinson : -- keywords: +patch pull_requests: +28612 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/30333 ___ Python tracker <https://bugs.python.org/issue46258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45609] Specialize STORE_SUBSCR
Mark Shannon added the comment: New changeset 7537f6008704b20e2d04a7ef1c0cfa34121cc5eb by Dennis Sweeney in branch 'main': bpo-45609: More specialization stats for STORE_SUBSCR (GH-30193) https://github.com/python/cpython/commit/7537f6008704b20e2d04a7ef1c0cfa34121cc5eb -- ___ Python tracker <https://bugs.python.org/issue45609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Change by Mark Shannon : -- pull_requests: +28621 pull_request: https://github.com/python/cpython/pull/30415 ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43683] Handle generator (and coroutine) state in the bytecode.
Mark Shannon added the comment: Yes, most of it :) We haven't implemented points 2 and 3, yet. I'm in no hurry to implement 3. It would clean up `gen.throw` a lot, and break the dependency between that code and the interpreter, but it isn't urgent. 2 is more urgent. I think we need it to allow specialization of `FOR_ITER` for generators, so it should happen in the next few weeks. -- ___ Python tracker <https://bugs.python.org/issue43683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45256] Remove the usage of the C stack in Python to Python calls
Mark Shannon added the comment: New changeset 332e6b972567debfa9d8f3f9a4a966c7ad15eec9 by Brandt Bucher in branch 'main': bpo-45256: Don't track the exact depth of each `InterpreterFrame` (GH-30372) https://github.com/python/cpython/commit/332e6b972567debfa9d8f3f9a4a966c7ad15eec9 -- ___ Python tracker <https://bugs.python.org/issue45256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Mark Shannon added the comment: See https://github.com/faster-cpython/ideas/discussions/210 -- ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
