[issue31661] Issues with request rate in robotparser

Nikolay Bogoychev added the comment: Hey Serhiy, The use of namedtuple was requested specifically at a review, I didn't implement it like this initially: https://bugs.python.org/review/16099/#ps6205 I wasn't aware of the performance implications. Could you please explain to me the type vs in

[issue31661] Issues with request rate in robotparser

New submission from Serhiy Storchaka : There are issues in implementing support of request rate in robotparser. req_rate = collections.namedtuple('req_rate', 'requests seconds') entry.req_rate = req_rate entry.req_rate.requests = int(numbers[0])

[issue31660] sys.executable different in os.execv'd python3.6 virtualenv session in python2 vs python3

New submission from Stephen Moore : Hi, I've come across a problem whereby if you do an os.execv to a python3.6 virtualenv python inside python2.7 vs python3.6 then the resulting python session has a different sys.executable. Where if you os.execv from python2.7 the sys.executable is equal to

[issue31659] ssl module should not use textwrap for wrapping PEM format.

INADA Naoki added the comment: For the record, this is part of `import requests`. `import ssl` took 11 ms and `textwrap` weights 2.4 ms of it. - ipaddress 2048 us (self 2048 us) - textwrap 2402 us (self 2402 us) - _ssl 2744 us (self 27

[issue31659] ssl module should not use textwrap for wrapping PEM format.

Change by INADA Naoki : -- keywords: +patch pull_requests: +3829 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue31659] ssl module should not use textwrap for wrapping PEM format.

Change by INADA Naoki : -- components: +Library (Lib) versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue31659] ssl module should not use textwrap for wrapping PEM format.

New submission from INADA Naoki : Current DER_cert_to_PEM_cert() uses textwrap like this: def DER_cert_to_PEM_cert(der_cert_bytes): """Takes a certificate in binary DER format and returns the PEM version of it as a string.""" f = str(base64.standard_b64encode(der_cer

[issue27484] Some Examples in Format String Syntax are incorrect or poorly worded

Rufus V. Smith added the comment: I happened to run across this in my old email inbox. It's embarrassing to realize how wrong I was in submitting the report. Reading it with fresh eyes, your original makes sense. I don't know what I was thinking. > On Jul 11, 2016, at 2:10 PM, Raymond Hettin

[issue21983] segfault in ctypes.cast

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue31589] Links for French documentation pdf is broken

Julien Palard added the comment: One difference I see in the logs of sucessfully building the faq.tex and failing to build it is: Package hyperref Warning: Token not allowed in a PDF string (Unicode): Looks like if I remove all non-ascii characters from titles, it builds again. --

[issue31589] Links for French documentation pdf is broken

Julien Palard added the comment: After an upgrade of my venv, the error is now: Latexmk: applying rule 'pdflatex'... Rule 'pdflatex': File changes, etc: Changed files, or newly in use since previous run(s): 'faq.aux' 'faq.out' 'faq.toc' Latexmk: Maximum runs of pdflatex rea

[issue31589] Links for French documentation pdf is broken

Ezio Melotti added the comment: FWIW most of the errors I met while trying to build the pdfs of the main docs were caused by the presence of non-latin1 characters. French should be limited to the latin1 range and the error you pasted doesn't seem to be related, however that might explain whi

[issue27494] 2to3 parser failure caused by a comma after a generator expression

Jakub Stasiak added the comment: By "forbid" do you mean "forbid in Python" (as in change Python syntax)? I like the idea but that seems like a more serious change and 2to3 arguably needs to handle code targeting older Python versions anyway. -- __

[issue31589] Links for French documentation pdf is broken

Change by Julien Palard : -- nosy: +linkid ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue31654] ctypes should support atomic operations

Antoine Pitrou added the comment: Le 01/10/2017 à 23:33, Daniel Colascione a écrit : > > Huh? Both are very generic. "Specialized" as in "I didn't expect anyone would want to do such a thing in pure Python". > SCM_RIGHTS is "specialized" > and not supported on all systems, yet it's in stdlib.

[issue31589] Links for French documentation pdf is broken

Julien Palard added the comment: Problem happen during pdflatex, I tried a local build and got: ! Package hyperref Error: Wrong DVI mode driver option `dvipdfmx', (hyperref)because pdfTeX or LuaTeX is running in PDF mode. See the hyperref package documentation for explanation.

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Tim Peters added the comment: Ah! So it looks like OpenBSD took its math functions from Sun's fdlibm. I believe wxMaxima does too. That would certainly explain why they give the same answer ;-) So who's right? Using "bigfloats" in wxMaxima and feeding its bigfloat tan() the exact decimal

[issue31654] ctypes should support atomic operations

Daniel Colascione added the comment: On Sun, Oct 1, 2017 at 2:01 PM, Antoine Pitrou wrote: > Perhaps other core developers will disagree with me and agree to include > (i.e. review, maintain) this functionality. I simply am not convinced > it deserves being included, but that's not a veto. c

[issue31654] ctypes should support atomic operations

Daniel Colascione added the comment: On Sun, Oct 1, 2017 at 2:01 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Le 01/10/2017 à 21:51, Daniel Colascione a écrit : > > > >> That does sound specialized to me :-) Can you give an example of such a > >> C API? > > > > The Linu

[issue31654] ctypes should support atomic operations

Serhiy Storchaka added the comment: It is not clear to me what API is needed, but I agree with Antoine that ctypes doesn't look the appropriate place for it. Maybe in multiprocessing or subprocess, or in low-level module providing primitives for multiprocessing or subprocess? -- nosy

[issue31622] Make threading.get_ident() return an opaque type

Serhiy Storchaka added the comment: > Currently, Python exposes "thread identifiers" as unsigned long values across > multiple modules: It happened not so long ago. In 3.6 and earlier "thread identifiers" are signed integers. See issue6532, it was massive change. This issue was deferred for

[issue31656] Bitwise operations for bytes-type

Martin Panter added the comment: There’s already a bug open for this: Issue 19251. Only equal-length strings should be supported. -- nosy: +martin.panter ___ Python tracker __

[issue31654] ctypes should support atomic operations

Antoine Pitrou added the comment: Le 01/10/2017 à 21:51, Daniel Colascione a écrit : > >> That does sound specialized to me :-) Can you give an example of such a >> C API? > > The Linux futex protocol, as described in man futex(7), comes to mind. > Maybe you want to manipulate C++ shared_ptr o

[issue31658] xml.sax.parse won't accept path objects

Change by Raymond Hettinger : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue31658] xml.sax.parse won't accept path objects

New submission from Craig Holmquist : >>> import xml.sax >>> import pathlib [...] >>> xml.sax.parse(pathlib.Path('path/to/file'), handler) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.6/xml/sax/__init__.py", line 33, in parse parser.parse(source) File "

[issue31654] ctypes should support atomic operations

Daniel Colascione added the comment: On Sun, Oct 1, 2017 at 11:12 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Le 01/10/2017 à 20:04, Daniel Colascione a écrit : > > > > It's not that specialized. You might want atomic updates for coordinating > > with C APIs that expec

[issue31654] ctypes should support atomic operations

Daniel Colascione added the comment: On Sun, Oct 1, 2017 at 11:14 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Note that if there is already a C API to perform atomic ops, you can > simply use ctypes to invoke that API. Unfortunately, the aforementioned > GCC builtins

[issue31622] Make threading.get_ident() return an opaque type

Benjamin Peterson added the comment: On Sun, Oct 1, 2017, at 12:25, Antoine Pitrou wrote: > Another possibility would be to have a new separate threading API > returning a "low-level opaque thread handle" that you could pass to > pthread_kill() and pthread_getcpuclockid(). threading.get_ident()

[issue31634] Consider installing wheel in ensurepip by default

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue31622] Make threading.get_ident() return an opaque type

Antoine Pitrou added the comment: Le 01/10/2017 à 21:20, Benjamin Peterson a écrit : > >>> signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on >>> https://github.com/python/cpython/pull/3756 >> >> Given how specialized (and of little actual use) those functions are, I >> don't

[issue31622] Make threading.get_ident() return an opaque type

Benjamin Peterson added the comment: On Sun, Oct 1, 2017, at 12:15, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Le 01/10/2017 à 21:07, Benjamin Peterson a écrit : > > > > signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on > > https://github.com/python/c

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Stefan Krah added the comment: OpenBSD reduces to the range [-pi/4,pi/4]: https://github.com/openbsd/src/blob/master/lib/libm/src/s_tan.c According to the man page on i386: http://man.openbsd.org/FreeBSD-11.0/math.3 "Argument reduction is not performed accurately for huge arguments, r

[issue31622] Make threading.get_ident() return an opaque type

Antoine Pitrou added the comment: Le 01/10/2017 à 21:07, Benjamin Peterson a écrit : > > signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on > https://github.com/python/cpython/pull/3756 Given how specialized (and of little actual use) those functions are, I don't think it's

[issue31622] Make threading.get_ident() return an opaque type

Benjamin Peterson added the comment: On Sun, Oct 1, 2017, at 12:05, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > You don't think having a function that takes an integer and dereferences it > > as memory is a bad idea? > > I'm not sure what you're talking about. What fu

[issue31622] Make threading.get_ident() return an opaque type

Antoine Pitrou added the comment: > You don't think having a function that takes an integer and dereferences it > as memory is a bad idea? I'm not sure what you're talking about. What function is that? -- ___ Python tracker

[issue31622] Make threading.get_ident() return an opaque type

Benjamin Peterson added the comment: You don't think having a function that takes an integer and dereferences it as memory is a bad idea? -- nosy: +benjamin.peterson ___ Python tracker __

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Tim Peters added the comment: Of course the relationship is extremely delicate near pi/2. On my Windows Python 3: >>> import math >>> (1.5707963267948961).hex() '0x1.921fb54442d16p+0' >>> math.tan(float.fromhex('0x1.921fb54442d16p+0')) # what the test expects 1978937966095219.0 >>> math.tan(f

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Mark Dickinson added the comment: So actually, the cause of the inaccuracy here could be that OpenBSD _is_ using the hardware instructions ... -- ___ Python tracker ___ __

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Mark Dickinson added the comment: I'm fairly sure most modern OSs on x86-64 use software implementations of sin, cos and tan. At least, I hope so: the x87 hardware versions are notoriously inaccurate: https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quinti

[issue31654] ctypes should support atomic operations

Antoine Pitrou added the comment: Note that if there is already a C API to perform atomic ops, you can simply use ctypes to invoke that API. Unfortunately, the aforementioned GCC builtins seem to be only available as intrinsics (at least I couldn't find a shared library that exposes the __at

[issue31654] ctypes should support atomic operations

Antoine Pitrou added the comment: Le 01/10/2017 à 20:04, Daniel Colascione a écrit : > > It's not that specialized. You might want atomic updates for coordinating > with C APIs that expect callers to have this capability. That does sound specialized to me :-) Can you give an example of such a

[issue31654] ctypes should support atomic operations

Daniel Colascione added the comment: On Oct 1, 2017 10:46 AM, "Antoine Pitrou" wrote: Antoine Pitrou added the comment: While the use case is reasonable (if specialized), It's not that specialized. You might want atomic updates for coordinating with C APIs that expect callers to have this c

[issue31654] ctypes should support atomic operations

Daniel Colascione added the comment: On Oct 1, 2017 10:19 AM, "Raymond Hettinger" wrote: Raymond Hettinger added the comment: > Compare-and-exchange is sufficient for avoiding the GIL contention > I describe above. If Python objects are involved, it is more complicated than you suggest. Py

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

Raymond Hettinger added the comment: I would have thought this would be a straight pass-through to the underlying hardware FPU tan() instruction so that it would give the same answer for the same hardware regardless of O/S. Perhaps we're seeing a software-only implementation (using CORDIC or

[issue31654] ctypes should support atomic operations

Antoine Pitrou added the comment: While the use case is reasonable (if specialized), I'm not sure ctypes is the place to expose such functionality, which can be quite extensive (see https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html). Perhaps as a separate package on PyPI? ---

[issue31622] Make threading.get_ident() return an opaque type

Antoine Pitrou added the comment: > On a system with pthreads, the thread_id that Python provides is merely > pthread_t casted to unsigned long. This works today, but is in violation of > the standard, and could break on systems with exotic pthread_t. I don't think that follows. Even if pthr

[issue31654] ctypes should support atomic operations

Raymond Hettinger added the comment: > Compare-and-exchange is sufficient for avoiding the GIL contention > I describe above. If Python objects are involved, it is more complicated than you suggest. Possibly, multiprocessing can offer a shared counter that creates integer objects on demand a

[issue21983] segfault in ctypes.cast

Oren Milman added the comment: IMHO, Lib/ctypes/test/test_cast.py is the relevant test. Mark, do you still wish to provide a fix for that? (Otherwise, i would be happy to open a PR.) -- nosy: +Oren Milman ___ Python tracker

[issue31622] Make threading.get_ident() return an opaque type

Change by Raymond Hettinger : -- nosy: +ncoghlan, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue31655] SimpleNamespace accepts non-string keyword names

Raymond Hettinger added the comment: > Wouldn't be better to add also the check that keyword names > for SimpleNamespace constructor are strings? Yes. > I don't know how classify this issue, as a bug or an enhancement. It is arguably a bug fix. +0 for putting this in Python 3.6. --

[issue31553] Extend json.tool to handle jsonlines (with a flag)

Change by Jeffrey Rackauckas : -- keywords: +patch pull_requests: +3828 stage: -> patch review ___ Python tracker ___ ___ Python-bug

[issue31656] Bitwise operations for bytes-type

R. David Murray added the comment: What happens when you apply a bitwise operation to two bytes objects of unequal length? Since the answer to that question is not obvious, we simply don't support the operation. If you want to make a proposal for this the python-ideas mailing list would be

[issue31657] unit test for optimization levels does not cover __debug__ case

Change by diana : -- keywords: +patch pull_requests: +3827 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailin

[issue31657] unit test for optimization levels does not cover __debug__ case

New submission from diana : There are currently three supported optimization levels (0, 1, and 2). Briefly summarized, they do the following. 0: no optimizations 1: remove assert statements and __debug__ blocks 2: remove docstrings, assert statements, and __debug__ blocks The curre

[issue31656] Bitwise operations for bytes-type

New submission from Matthias Gilch : I've seen that the bytes type does not support bitwise operations, but I think users would expect that those operations will work. -- components: Interpreter Core messages: 303464 nosy: MGilch priority: normal severity: normal status: open title: Bit

[issue31655] SimpleNamespace accepts non-string keyword names

R. David Murray added the comment: Sorry, not broken, it just raises a type error, which is appropriate :) -- ___ Python tracker ___ ___

[issue31654] ctypes should support atomic operations

Change by SilentGhost : -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue31555] Windows pyd slower when not loaded via load_dynamic

Steve Dower added the comment: I don't really care, since you're comparing multiple unsupported technologies, but my guess is that the egg install injects the library much earlier on sys.path, which avoids most of the relatively expensive file system scan. --

[issue31655] SimpleNamespace accepts non-string keyword names

Change by R. David Murray : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue31655] SimpleNamespace accepts non-string keyword names

R. David Murray added the comment: Well, it would be an "unenhancement" (reducing functionality :). What I think it would be classed as is an API bug fix, and those generally can be made only in feature releases. I can imagine code depending on this ability, since we have had code in the w

[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method

Change by Oren Milman : -- pull_requests: +3826 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue31626] Writing in freed memory in _PyMem_DebugRawRealloc() after shrinking a memory block

Serhiy Storchaka added the comment: Using nested _PyMem_DebugRawRealloc() looks suspicions to me. This may be a bug. But even without nested _PyMem_DebugRawRealloc() writing to the extra memory after using realloc() looks wrong to me. This can break other non-trivial system allocators which w

[issue31626] Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +3825 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue31555] Windows pyd slower when not loaded via load_dynamic

Safihre added the comment: If you know the problem, would you also know the solution? What is the difference in how they generate sys.path entries and how does this affect performance during execution of the module function? Just want to understand what is going on :) -- _

[issue31308] forkserver process isn't re-launched if it died

Antoine Pitrou added the comment: Looks like this will not make into 3.6.3. I'd like to sum up the discussion a bit: - I think at the very least least we must protect the forkserver against SIGINT, like the semaphore tracker already is - I think it's beneficial to also restart it on demand if

[issue31626] Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD

Change by Serhiy Storchaka : -- priority: normal -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue31626] Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD

Serhiy Storchaka added the comment: There several bugs in the memory allocator. Incorrectly detected the case when realloc() resizes a memory block in-place. Wrong address is used for filling the extra memory with DEADBYTE. -if (q == oldq && nbytes < original_nbytes) { +if (q == oldq

[issue31653] Don't release the GIL if we can acquire a multiprocessing semaphore immediately

Change by Antoine Pitrou : -- type: enhancement -> performance ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31465] Allow _PyType_Lookup() to raise exceptions

Change by Serhiy Storchaka : -- pull_requests: -3632 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue31465] Allow _PyType_Lookup() to raise exceptions

Serhiy Storchaka added the comment: I'm positive to this change in general, but this is too complex and delicate code. In needs careful reviewing. -- ___ Python tracker ___ __

[issue31336] Speed up _PyType_Lookup() for class creation

Stefan Behnel added the comment: Thanks for the reviews, and thank you for merging it, Serhiy. -- ___ Python tracker ___ ___ Python-

[issue31336] Speed up _PyType_Lookup() for class creation

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue31336] Speed up _PyType_Lookup() for class creation

Serhiy Storchaka added the comment: Thank you for your contribution Stefan! I had doubts about your initial (much simpler) changes, but changed my mind. -- ___ Python tracker

[issue31336] Speed up _PyType_Lookup() for class creation

Serhiy Storchaka added the comment: New changeset 2102c789035ccacbac4362589402ac68baa2cd29 by Serhiy Storchaka (scoder) in branch 'master': bpo-31336: Speed up type creation. (#3279) https://github.com/python/cpython/commit/2102c789035ccacbac4362589402ac68baa2cd29 -- ___

[issue31651] io.FileIO cannot write more than 2GB (-4096) bytes??? must be documented (if not fixed)

Serhiy Storchaka added the comment: > On Linux, write() (and similar system calls) will transfer at most 0x7000 > (2,147,479,552) bytes, returning the number of bytes > actually transferred. (This is true on both 32-bit and 64-bit > systems.) This is platform-depending limitation. It ca