[issue8597] build out-of-line asm on Windows

Stefan Krah added the comment: I think this is a duplicate of issue 7546. -- nosy: +skrah type: behavior -> feature request ___ Python tracker <http://bugs.python.org/iss

[issue8583] Hardcoded namespace_separator in the cElementTree.XMLParser

Stefan Behnel added the comment: There is at least one valid use case: code that needs to deal with HTML and XHTML currently has to normalise the tag names in some way, which usually means that it will want to remove the namespaces from XHTML documents to make it look like plain HTML. It

[issue8613] Decimal module flags undetermined when a signal is trapped.

Stefan Krah added the comment: I agree that the spec is not unambiguous, but consider the Overflow and Underflow passages here: http://speleotrove.com/decimal/daexcep.html ==> Overflow ==> In all cases, Inexact and Rounded will also be raised. "Raise" here of course m

[issue7724] setup.py ignores SDK root on OSX

Stefan Krah added the comment: Just to save you some time investigating, it broke the build because of missing parentheses in setup.py: if sys.platform == 'darwin' and dir.startswith('/System') or dir.startswith('/usr') -- nosy: +skrah

[issue1481] test_uuid is warning about unreliable functions

Changes by Stefan Krah : -- status: pending -> closed ___ Python tracker <http://bugs.python.org/issue1481> ___ ___ Python-bugs-list mailing list Unsubscri

[issue6419] Broken test_kqueue.py on OpenBSD

Changes by Stefan Krah : -- nosy: +skrah ___ Python tracker <http://bugs.python.org/issue6419> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue7449] A number tests "crash" if python is compiled --without-threads

Stefan Krah added the comment: Victor, I think one more skip is required in test_socketserver. -- nosy: +skrah resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file17317/nothreads-socketserver-shutdown

[issue6419] Broken test_kqueue.py on OpenBSD

Stefan Krah added the comment: The same patch was applied to the Python port by OpenBSD developer Damien Miller: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.6/patches/patch-Lib_test_test_kqueue_py Mark, would it be ok in this situation to apply the patch even though personally

[issue8424] Test assumptions for test_itimer_virtual and test_itimer_prof

Stefan Krah added the comment: Luckily, the OpenBSD failures are caused by issues in libpthread. This means that some skips could be added (as for FreeBSD), but I'll open a separate issue for that. Thanks for the comments on the patch. I add two new patches that incorporate the s

[issue8424] Test assumptions for test_itimer_virtual and test_itimer_prof

Changes by Stefan Krah : Added file: http://bugs.python.org/file17335/issue8424-trunk-skiptest.patch ___ Python tracker <http://bugs.python.org/issue8424> ___ ___ Pytho

[issue8710] test_xpickle: compat tests: workaround for missing test_support

New submission from Stefan Krah : When the system python does not have the Lib/test directory, the compat tests are failing. == ERROR: test_attribute_name_interning (test.test_xpickle.CPicklePython26Compat

[issue3771] test_httpservers intermittent failure, test_post and EINTR

Stefan Krah added the comment: The EINTR issue should be fixed in trunk (issue1628205). Have you by any chance run the test suite on trunk in the meantime? -- nosy: +skrah ___ Python tracker <http://bugs.python.org/issue3

[issue8710] test_xpickle: compat tests: workaround for missing test_support

Stefan Krah added the comment: The compat tests check that pickling in the newly compiled Python version is compatible with pickling in installed Python versions. The installed versions may or may not have a test directory. For example, the 2.6 port in OpenBSD does not have the test directory

[issue8712] Skip libpthread related test failures on OpenBSD

New submission from Stefan Krah : [Added OpenBSD Python port maintainers to the nosy list.] I've identified a number of tests that all pass when Python is compiled without threads, but fail otherwise. The failures are probably caused by libpthread issues in OpenBSD, as described in this

[issue2041] __getslice__ still called

Stefan Seefeld added the comment: Mark, thanks for the quick follow-up. OK, i now understand the situation better. The documentation I had read originally didn't talk about special-casing built-in objects. (And since I want to extend a tuple, I do have to override __getslice__ since I

[issue2041] __getslice__ still called

New submission from Stefan Seefeld: The python documentation states that since python 2.0 __getslice__ is obsoleted by __getitem__. However, testing with python 2.3 as well as 2.5, I find the following surprising behavior: class Tuple(tuple): def __getitem__(self, i): print '__getitem_

[issue2072] SimpleXMLRPCServer documentation about rpc_paths might be wrong

New submission from Stefan Schwarzburg: In the documentation for SimpleXMLRPCServer (http://docs.python.org/lib/simple-xmlrpc-servers.html)it is said, that the SimpleXMLRPCServer object has an attribute "rpc_paths" that could be set to valid path portions. This would mean that ch

[issue2101] xml.dom documentation doesn't match implementation

New submission from Stefan Seefeld: The docs at http://docs.python.org/lib/dom-element-objects.html claim that removeAttribute(name) silently ignores the attempt to remove an unknown attribute. However, the current implementation in the minidom module (part of _xmlplus) raises an

[issue4244] ihooks incompatible with absolute_import feature

Stefan Behnel <[EMAIL PROTECTED]> added the comment: This is an (extended) duplicate of issue4152. -- nosy: +scoder ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue4242] Classify language vs. impl-detail tests, step 1

Stefan Behnel added the comment: I would definitely appreciate having a well-defined set of "required tests" that Cython should pass for compliance. However, something like sys.vm won't easily work for Cython: it runs within the CPython VM but only after converting the P

[issue4242] Classify language vs. impl-detail tests, step 1

Stefan Behnel added the comment: @Antoine: Cython already compiles a major part of CPython's test suite successfully (although we didn't actually try to compile the stdlib itself but only the tests). It's an announced goal for Cython 1.0 to compile 'all' Python code,

[issue4753] Faster opcode dispatch on gcc

Stefan Ring added the comment: Hi, I ported threadedceval6.patch to Python 2.5.4, in case anyone is interested... Note that you need to run autoconf and autoheader. -- nosy: +Ringding Added file: http://bugs.python.org/file12824/threadedceval6-py254.patch

[issue46955] The documentation mentions asyncio.Server. It does not exist.

New submission from Stefan Zabka : The asyncio documentation claims that there is a class [asyncio.Server](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.Server). However when looking in the sources I can only find [asyncio.base_events.Server](https://github.com/python

[issue46955] The documentation mentions asyncio.Server. It does not exist.

Change by Stefan Zabka : -- keywords: +patch pull_requests: +29872 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31760 ___ Python tracker <https://bugs.python.org/issu

[issue14465] xml.etree.ElementTree: add feature to prettify XML output

Stefan Behnel added the comment: New changeset b5d3ceea48c181b3e2c6c67424317afed606bd39 by Stefan Behnel in branch 'master': bpo-14465: Add an indent() function to xml.etree.ElementTree to pretty-print XML trees (GH-15200) https://github.com/python/cpyt

[issue14465] xml.etree.ElementTree: add feature to prettify XML output

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue37940] Add xml.tool to pretty print XML like json.tool

Stefan Behnel added the comment: Sounds like a good idea to add something like this. Have a look here for some more ideas: https://github.com/lxml/lxml/blob/master/tools/xpathgrep.py ElementTree should be able to provide most of these features as well these days. -- stage: -> ne

[issue23423] XPath Support in ElementTree doc omission

Stefan Behnel added the comment: Already fixed in later versions of the documentation: https://docs.python.org/3/library/xml.etree.elementtree.html#supported-xpath-syntax Note that Py3.4 is no longer maintained. -- resolution: -> out of date stage: -> resolved status

[issue37940] Add xml.tool to pretty print XML like json.tool

Stefan Behnel added the comment: I agree that formatting is not a use case by itself. I like the idea of XPath grepping, though, especially *without* pretty printing, i.e. one result per line. I admit that there is no strong reason for adding such a command line tool to the stdlib, though

[issue38011] xml.dom.pulldom splits text data at buffer size when parsing from file

Stefan Behnel added the comment: I don't see anything inherently wrong with having multiple text nodes. In fact, input with very large text content can be considered a security threat (c.f. compression bombs), so a tool like pulldom (which is designed for incremental processing) shoul

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: Let's just deprecate it directly (in Py3.9, I guess), given that it was never documented. -- ___ Python tracker <https://bugs.python.org/is

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32424] Synchronize copy methods between Python and C implementations of xml.etree.ElementTree.Element

Stefan Behnel added the comment: New changeset 7d952ded6813c896ea3f4234bb8db5247dcb5484 by Stefan Behnel (Gordon P. Hemsley) in branch 'master': bpo-32424: Deprecate xml.etree.ElementTree.Element.copy() in favor of copy.copy() (GH-12995) https://github.com/python/cpyt

[issue10108] ExpatError not property wrapped

Stefan Behnel added the comment: I agree that it's surprising to get a low-level parser error from a high-level library like xmlrpc. I think this can be changed without deprecation, because users must expect exceptions from the xmlrpc library in any case. Targeting to Py3.9, needs

[issue28237] In xml.etree.ElementTree bytes tag or attributes raises on serialization

Stefan Behnel added the comment: Arguably, writing out "b'x'" as attribute name instead of raising an exception isn't ideal. However, OTOH, I think it's reasonable to accept anything that is serialisable as a string, not just strings. That makes it difficult

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Change by Stefan Behnel : -- versions: +Python 3.9 -Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue33187> ___ ___ Python-bug

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Change by Stefan Behnel : -- versions: -Python 3.7 ___ Python tracker <https://bugs.python.org/issue33187> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Stefan Behnel added the comment: New changeset 97b817eae34b77be1ced382e15098a112f547848 by Stefan Behnel (Anjali Bansal) in branch 'master': bpo-33187: Document ElementInclude (XInclude) support in ElementTree (GH-8861) https://github.com/python/cpyt

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Stefan Behnel added the comment: New changeset 6cf0ba8a632b1c0bd3576ed33c971ca3778000de by Stefan Behnel (Miss Islington (bot)) in branch '3.8': bpo-33187: Document ElementInclude (XInclude) support in ElementTree (GH-8861) (GH-15958) https://github.com/python/cpyt

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Change by Stefan Behnel : -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue33187> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Stefan Behnel added the comment: New changeset 195dc142f84804ad9c8ce91414ab4a0bf9615f09 by Stefan Behnel (Miss Islington (bot)) in branch '3.7': bpo-33187: Document ElementInclude (XInclude) support in ElementTree (GH-8861) (GH-15972) https://github.com/python/cpyt

[issue38158] PyType_Spec docs list non-existant field "doc"

New submission from Stefan Behnel : The current documentation of the PyType_Spec struct lists a "doc" member which does not exist. It should be removed from the docs. https://docs.python.org/3.8/c-api/type.html#c.PyType_Spec -- assignee: docs@python components: Documentatio

[issue38158] PyType_Spec docs list non-existant field "doc"

Change by Stefan Behnel : -- stage: -> needs patch ___ Python tracker <https://bugs.python.org/issue38158> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue38158] PyType_Spec docs list non-existant field "doc"

Stefan Behnel added the comment: Absolutely, Tahia. It just needs a PR with a doc update. -- ___ Python tracker <https://bugs.python.org/issue38158> ___ ___

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

Stefan Behnel added the comment: I think access to the global module state is the most critical for an extension, probably by far. A direct pointer to the interpreter state from every type feels like an optimisation that may be premature at this point. Modules should have that reference

[issue38158] PyType_Spec docs list non-existant field "doc"

Stefan Behnel added the comment: New changeset b65be6cd3d9b6102227d27f4f35385f999a7dd7d by Stefan Behnel (Miss Islington (bot)) in branch '3.8': bpo-38158: Removing nonexistant member "doc" from PyType_Spec documentation (GH-16142) (GH-16154) https://github.com/p

[issue38158] PyType_Spec docs list non-existant field "doc"

Change by Stefan Behnel : -- keywords: -patch resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue38225] iscoroutinefunction broken with cython - allow tagging of functions as async?

Stefan Behnel added the comment: My usual first reaction is: "if you need to find out whether the return value of a callable will be an Awaitable or not, without calling it, then you're probably doing something wrong in your design". However, a) there is code that tries this

[issue38225] iscoroutinefunction broken with cython - allow tagging of functions as async?

Stefan Behnel added the comment: > along with the appropriate CO_COROUTINE flag set No, it never did that, for safety reasons. It's difficult to say if enabling these flags is the right thing to do, because it's unclear what assumptions code that tests for them would make. In C

[issue33187] Document ElementInclude (XInclude) support in ElementTree

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue43616] random.shuffle() crashes with Unhandled exception

Stefan Behnel added the comment: Almost certainly not a bug in CPython's stdlib. Possibly something worth investigating in lxml, although, as stated in issue 43618, random.shuffle() simply does not work on lxml.etree Elements. -- resolution: -> third party stage: -&g

[issue43618] random.shuffle loses most of the elements

Stefan Behnel added the comment: Yes, this is neither a bug in CPython (or its stdlib) nor in lxml. It's how things work. Don't use these two together. -- resolution: -> third party stage: -> resolved status: open -> closed ___

[issue43816] Missing 'extern "C"' for _Py_ctype_table

Stefan Behnel added the comment: These macros are a sort-of documented part of the C-API. At least, they were mentioned in a What's New document: https://docs.python.org/3/whatsnew/2.7.html?highlight=py_isspace#build-and-c-api-changes They were added here, for the Py2.7 release:

[issue40066] Enum: modify __repr__, __str__; update docs

Stefan Behnel added the comment: > why /shouldn't/ we make the change? It breaks doctests, and probably some other unit tests, too, e.g. for output formatting. What should we suggest users to do? Replace >>> get_flag(…) by >>> get_flag(…) == app_enu

[issue43816] Missing 'extern "C"' for _Py_ctype_table

Stefan Behnel added the comment: The macros were moved to "Includes/cpython/", not to "Includes/internal/". That suggests to me that they should use "extern C", so that C++ code that wants to make use of CPython internals can use them. Basically, the way I

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

Stefan Behnel added the comment: I support that there should be a simple way to do this from C. The way via importing the "gc" module and then looking up an attribute (possibly building a Unicode string) and calling a function in it involves several operations that can take som

[issue22079] Ensure in PyType_Ready() that base class of static type is static

Stefan Behnel added the comment: Coming back to this after a while. I would like to get rid of the work-around (read: huge hack) that we have in Cython for this check and thus would ask for the check to be removed in Py3.10. According to the discussion, no-one seemed to remember why it was

[issue43959] Improve documentation of PyContextVar C-API

New submission from Stefan Behnel : The documentation of the PyContextVar C-API is unclear in a couple of places. - It's not clear whether PyContextVar_Get() always returns an owned reference also for default values or only if a value was found. - It's not explicit that "opt

[issue43959] Improve documentation of PyContextVar C-API

Change by Stefan Behnel : -- keywords: +patch pull_requests: +24362 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25671 ___ Python tracker <https://bugs.python.org/issu

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

Change by Stefan Behnel : -- nosy: +scoder nosy_count: 3.0 -> 4.0 pull_requests: +24377 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25687 ___ Python tracker <https://bugs.python.org/i

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

Stefan Behnel added the comment: I just remembered that it's usually helpful to return the previous state, so that callers know whether they need to re-enable or disable the GC when they're done. I'll add that. Also, returning an "int" may allow us to add a &quo

[issue43959] Improve documentation of PyContextVar C-API

Stefan Behnel added the comment: New changeset fdb11897d7c8f9e6bdf96fcef802f784ef90f726 by Miss Islington (bot) in branch '3.9': bpo-43959: clarify the documentation of the PyContextVar C-API (GH-25671) (GH-25689) https://github.com/python/cpyt

[issue43959] Improve documentation of PyContextVar C-API

Stefan Behnel added the comment: New changeset ff7266efd0ef6b42dad30c9c0d210f843cc44f39 by Miss Islington (bot) in branch '3.8': bpo-43959: clarify the documentation of the PyContextVar C-API (GH-25671) (GH-25690) https://github.com/python/cpyt

[issue43959] Improve documentation of PyContextVar C-API

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44054] 2**53+1 != float(2**53+1)

New submission from Stefan Behnel : I'm not sure if I should consider this a bug, but I'd at least frown at the behaviour, so I thought I'd bring this up here. Python 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0] on linux >>> 2**53 == float(2**53) True >>&

[issue44054] 2**53+1 != float(2**53+1)

Change by Stefan Behnel : -- nosy: +tim.peters ___ Python tracker <https://bugs.python.org/issue44054> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44054] 2**53+1 != float(2**53+1)

Stefan Behnel added the comment: > I really don't know why you would desire a different result. I found it surprising that a comparison uses a different method of conversion than the (obvious) user-side conversion, with a different outcome. This seems to be implementation details

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Stefan Behnel added the comment: For the same reason that motivated this ticket, I think the functions should be inline functions. They should also take the current thread-state as argument, because that's probably known on the caller side already. I guess a macro would be fine

[issue40222] "Zero cost" exception handling

Stefan Behnel added the comment: Just a comment regarding the change to "PyCode_NewWithPosOnlyArgs()". As Pablo mentioned, this has happened before. And that's OK! Exactly because this has happened before, it's clearly not a part of the API that is meant to be stable.

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Stefan Behnel added the comment: I just noticed that new C-API functions are probably useless for Cython since I think it will have to maintain the CFrame stack, so not to enable "use_tracing" for the (Python) caller but the current (Cython) function. This then means that we own T

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Stefan Behnel added the comment: Should we allow empty CFrame entries (with a NULL Frame pointer) that only use their "use_tracing" flag? That would make it easy for code to append and remove such an entry in order to temporarily disab

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Change by Stefan Behnel : -- Removed message: https://bugs.python.org/msg393667 ___ Python tracker <https://bugs.python.org/issue43760> ___ ___ Python-bugs-list m

[issue43420] Optimize rational arithmetics

Stefan Behnel added the comment: Just FYI, I applied the same changes to the quicktions [1] module, a Cython compiled (and optimised) version of fractions.Fraction. [1] https://github.com/scoder/quicktions/ The loss in performance for small values is much higher there, almost 2x for the

[issue19832] XML version is ignored

Stefan Behnel added the comment: After reading up a bit, version "X" should probably be rejected, whereas "1.[0-9]+" is meant to be allowed also by a 1.0 parser, according to the spec: https://www.w3.org/TR/REC-xml/#sec-prolog-dtd """ When an XML 1.0 p

[issue23609] Export PyModuleObject in moduleobject.h

Stefan Behnel added the comment: Could you explain a bit why you want to subclass "PyModuleObject" in C? Why isn't a Python subclass or an independent (non-module) C extension type enough? -- ___ Python tracker <https://bugs.pyt

[issue23609] Export PyModuleObject in moduleobject.h

Change by Stefan Behnel : -- components: +C API -Interpreter Core type: -> enhancement versions: +Python 3.11 -Python 3.5 ___ Python tracker <https://bugs.python.org/issu

[issue23609] Export PyModuleObject in moduleobject.h

Stefan Behnel added the comment: I only just noticed that the original request is from 2015. My guess is that this is a resolved problem, given the available options. I'll close this ticket as outdated. Please comment if this is still an issue. -- resolution: -> out of da

[issue44666] compileall.compile_file fails when sys.stdout is redirected to StringIO

New submission from Stefan Hölzl : compile_files tries to escape non-printable characters in error messages by using sys.stdout.encoding https://github.com/python/cpython/blob/main/Lib/compileall.py#L256 when using contextlib.redirect_stdout to redirect stdout to io.StringIO as explained in

[issue44666] compileall.compile_file fails when sys.stdout is redirected to StringIO

Change by Stefan Hölzl : -- keywords: +patch pull_requests: +25784 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27236 ___ Python tracker <https://bugs.python.org/issu

[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

Stefan Behnel added the comment: The obvious work-around is to not use a default namespace. The result is just a visual difference, not a semantic one. If someone wants to continue with the existing PR, I'll try to free some time to review any improvements. -- versions: +P

[issue24076] sum() several times slower on Python 3 64-bit

Change by Stefan Behnel : -- pull_requests: +26868 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/28469 ___ Python tracker <https://bugs.python.org/issu

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: I created a PR from my last patch, inlining the unpacking of single digit integers. Since most integers should fit into a single digit these days, this is as fast a path as it gets. https://github.com/python/cpython/pull/28469 -- versions: +Python

[issue43760] The DISPATCH() macro is not as efficient as it could be (move PyThreadState.use_tracing)

Stefan Behnel added the comment: > The code in the examples given above are using `tstate->use_tracing` assuming > that its meaning is to determine whether tracing is turned on or not. No, actually not. It is using the field in the same way as CPython, simply because most of this

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: > The patch looks fine, but it looks a bit like benchmark chasing. Is the speed > of builtin sum() of a sequence of integers important enough to do this bit of > inlining? Given that we already accepted essentially separate loops for the int, f

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: New changeset debd80403721b00423680328d6adf160a28fbff4 by scoder in branch 'main': bpo-24076: Inline single digit unpacking in the integer fastpath of sum() (GH-28469) https://github.com/python/cpython/commit/debd80403721b00423680328d6adf1

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: Original: $ ./python -m timeit -s 'd = list(range(2**61, 2**61 + 1))' 'sum(d)' 500 loops, best of 5: 712 usec per loop $ ./python -m timeit -s 'd = list(range(2**30, 2**30 + 1))' 'sum(d)' 2000 loops, best of 5: 1

[issue24076] sum() several times slower on Python 3 64-bit

Change by Stefan Behnel : -- Removed message: https://bugs.python.org/msg402301 ___ Python tracker <https://bugs.python.org/issue24076> ___ ___ Python-bugs-list m

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: Original: $ ./python -m timeit -s 'd = list(range(2**61, 2**61 + 1))' 'sum(d)' 500 loops, best of 5: 712 usec per loop $ ./python -m timeit -s 'd = list(range(2**30, 2**30 + 1))' 'sum(d)' 2000 loops, best of 5: 1

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: Hmm, thanks for insisting, Serhiy. I was accidentally using a debug build this time. I'll make a PGO build and rerun the microbenchmarks. -- ___ Python tracker <https://bugs.python.org/is

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: Old, with PGO: $ ./python -m timeit -s 'd = list(range(2**61, 2**61 + 1))' 'sum(d)' 1000 loops, best of 5: 340 usec per loop $ ./python -m timeit -s 'd = list(range(2**30, 2**30 + 1))' 'sum(d)' 2000 loops, be

[issue24076] sum() several times slower on Python 3 64-bit

Change by Stefan Behnel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue24076] sum() several times slower on Python 3 64-bit

Stefan Behnel added the comment: Sorry for that, Pablo. I knew exactly where the problem was, the second I read your notification. Thank you for resolving it so quickly. -- ___ Python tracker <https://bugs.python.org/issue24

[issue45346] Some "truthy" crept in

New submission from Stefan Pochmann : Python consistently says true/false, not truthy/falsy. But a few "truthy" have crept in now: https://github.com/python/cpython/search?q=truthy - Two in Doc/reference/compound_stmts.rst - One in Doc/library/ast.rst - One in Lib/test/test_

[issue45346] Some "truthy" crept in

Change by Stefan Pochmann : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue45346> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue45530] Improve listobject.c's unsafe_tuple_compare()

Stefan Pochmann added the comment: That's how Elliot did it in the original proposal: https://bugs.python.org/issue28685 Back then you pointed out that "Else we can assume u[0] == v[0]" isn't true for float('nan') values: https://github.com/python/cpython/p

[issue45530] Improve listobject.c's unsafe_tuple_compare()

Stefan Pochmann added the comment: > What justifies "shouldn't"? I based that on your old comments. Looked like tuple comparison results in sorting shouldn't differ from tuple comparison results elsewhere. I had actually proposed this exact method in a comment u

[issue45530] Improve listobject.c's unsafe_tuple_compare()

Stefan Pochmann added the comment: I misinterpreted you then, sorry. I guess also because Elliot shortly after retrated from the approach, saying he "rewrote unsafe_tuple_compare to move the less-than after the equality testing, to make sure it's 100% consistent". I'd s

[issue45530] Improve listobject.c's unsafe_tuple_compare()

Stefan Pochmann added the comment: Ok, I agree, the change only possibly "breaks" expectations that were already broken (including my naive sorted-vs-minmax). Yes, I know sort itself only asks `<` (I've actually read most of its code and all its documentation). That

[issue45530] Improve listobject.c's unsafe_tuple_compare()

Stefan Pochmann added the comment: Hmm. What do you think about using "<" inside the loop for the remaining tuple elements as well? It's even less likely that both the first and the second elements are equal. When the second elements differ, this saves 0.5 PyObject_RichCom

<    3   4   5   6   7   8   9   10   11   12   >