[issue37454] Clarify docs for math.log1p()

[Mark Dickinson]

Mark Dickinson  added the comment:

> however, for x < 0.0 it is always worse

That's quite surprising. Which platform? And can you give some example inputs 
and outputs? With a good math library, I'd expect `log1p(x)` to almost always 
be at least as accurate as `log(1 + x)`, and substantially _more_ accurate for 
small x (say abs(x) < 1e-5). If that's not happening, we may want to substitute 
our own implementation for the system implementation on some platforms (in the 
same was as we did for lgamma, erf, and friends).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37440] httplib should enable post-handshake authentication for TLS 1.3

[miss-islington]

miss-islington  added the comment:


New changeset ee72dda9616258b57c19eb5af00f3e80a3fb8e22 by Miss Islington (bot) 
in branch '3.8':
[3.8] bpo-37440: Enable TLS 1.3 post-handshake auth in http.client (GH-14448) 
(GH-14495)
https://github.com/python/cpython/commit/ee72dda9616258b57c19eb5af00f3e80a3fb8e22


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37440] httplib should enable post-handshake authentication for TLS 1.3

[miss-islington]

miss-islington  added the comment:


New changeset 6be91102f75aa4b4b8c1e55960aa22008ff9e319 by Miss Islington (bot) 
in branch '3.7':
[3.7] bpo-37440: Enable TLS 1.3 post-handshake auth in http.client (GH-14448) 
(GH-14496)
https://github.com/python/cpython/commit/6be91102f75aa4b4b8c1e55960aa22008ff9e319


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37454] Clarify docs for math.log1p()

[Mark Dickinson]

Mark Dickinson  added the comment:

Ah, now I've looked at the script. There's an issue with using 
`random.random()` to create "small" values for testing, since its result is 
always an integer multiple of 2**-53. That means in particular that if x = 
random.random(), then 1 - x is always *exactly* representable (and 1 + x is 
also exactly representable approximately half of the time), so there's no loss 
of accuracy in the intermediate step of computing log(1 + x) if x = 
-random.random().

Here's what I get if I run your script exactly as it stands (Python 3.7.3, 
macOS 10.14.5)

mirzakhani:Desktop mdickinson$ python test.py
Counter({'equal': 51839, 'offset_log': 41988, 'regular_log': 6173})
Counter({'equal': 93727, 'regular_log': 6273})

But if I replace each `random.random()` call with `1e-3 * random.random()`, in 
order to test small values of `x`, here's what I get:

mirzakhani:Desktop mdickinson$ python test.py
Counter({'offset_log': 99945, 'equal': 55})
Counter({'offset_log': 99893, 'equal': 107})

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37462] Default starting directory for os.walk()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is not obvious that the majority of os.walk() calls are with the current 
working directory. And if you need to walk from the current working directory, 
it is not hard to pass "." explicitly. Even if your program contains a lot of 
os.walk(".") you could not use this feature until drop support of Python 3.8.

So I think the value of this feature is tiny. It is not worth the effort for 
implementing, documenting, reviewing and maintaining it. On other hand, it 
increases the burden for learning Python.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37428] SSLContext.post_handshake_auth implicitly enables cert validation

[Christian Heimes]

Christian Heimes  added the comment:


New changeset f22c4cf11d10f52faa86e0b308dd28f11819efd8 by Christian Heimes in 
branch '3.8':
[3.8] bpo-37428: Don't set PHA verify flag on client side (GH-14494)
https://github.com/python/cpython/commit/f22c4cf11d10f52faa86e0b308dd28f11819efd8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37464] multiple comparison

[Chandan Kumar]

New submission from Chandan Kumar :

a=1.0
b=0.0
c=0.0
if (a> d and b):
 print('hi')
else:
 print("bye")

its going to else part
a=1.0
b=0.1
c=0.2
then its going to if part
a==1.0
b=0
c=0.1
then again its going to else part

--
assignee: docs@python
components: Documentation
messages: 346972
nosy: Chandan, docs@python
priority: normal
severity: normal
status: open
title: multiple comparison
type: enhancement
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[STINNER Victor]

STINNER Victor  added the comment:

> To me, it doesn't seem dangerous to backport that, but I would love to hear 
> what Eryk and others think :)

In my experience, any change is dangerous :-)

The initial bug doesn't contain any reproducer. I'm talking about:

> If one of the processes in that list is gone, then (...) "The handle is 
> invalid" (...) will prevent you from creating any new processes with Popen 
> after that

It's the first time that I see such bug report. It seems like subprocess works 
for most people :-) Can you elobrate how to reproduce this issue to justify a 
backport?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37465] Incorrect documentation for `s#` arguments in C API argument parsing

[Enrico Zini]

New submission from Enrico Zini :

In https://docs.python.org/3.9/c-api/arg.html, in the documentation for parsing 
argument, there is:

 s# (str, read-only bytes-like object) [const char *, int or Py_ssize_t]

In my amd64 system, `Py_ssize_t` is a different type than `int`, and passing a 
`Py_ssize_t` causes undefine behaviour.

I assume this has been switched to an `int` in the API, and that thisinstance 
of the documentation has not been updated accordingly. At the bottom of the 
page in the documentation of `Py_BuildValue`, `s#` is correctly documented as 
using an `int` and no `Py_ssize_t`, for example.

--
assignee: docs@python
components: Documentation
messages: 346974
nosy: docs@python, enrico
priority: normal
severity: normal
status: open
title: Incorrect documentation for `s#` arguments in C API argument parsing
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37464] multiple comparison

[Chandan Kumar]

Change by Chandan Kumar :


--
type: enhancement -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37199] Test suite fails when Ipv6 is unavailable

[STINNER Victor]

STINNER Victor  added the comment:

Python 3.7 is still supported, if it's a bugfix, 3.7 should be fixed as well:
https://devguide.python.org/#status-of-python-branches

Christian Heimes asked for a change after the PR was merged:
https://github.com/python/cpython/pull/14480#pullrequestreview-256080790

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37465] Incorrect documentation for `s#` arguments in C API argument parsing

[Inada Naoki]

Inada Naoki  added the comment:

See note in https://docs.python.org/3.9/c-api/arg.html#strings-and-buffers

"""
Note: For all # variants of formats (s#, y#, etc.), the type of the length 
argument (int or Py_ssize_t) is controlled by defining the macro 
PY_SSIZE_T_CLEAN before including Python.h. If the macro was defined, length is 
a Py_ssize_t rather than an int. This behavior will change in a future Python 
version to only support Py_ssize_t and drop int support. It is best to always 
define PY_SSIZE_T_CLEAN. 
"""

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37464] multiple comparison

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

a=1.0
b=0.0
c=0.0
if (a> d and b):
 print('hi')
else:
 print("bye")

d is not defined here and it throws a NameError for me. Can you please attach 
the full scripts that can be used to reproduce the behavior in the report.

--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33234] Improve list() pre-sizing for inputs with known lengths

[Nicholas Musolino]

Change by Nicholas Musolino :


--
pull_requests: +14316
pull_request: https://github.com/python/cpython/pull/14432

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37464] multiple comparison

[SilentGhost]

SilentGhost  added the comment:

Your issue seems to be related to evaluation of 0.0 as falsy value. See 
documentation at 
https://docs.python.org/3/library/stdtypes.html#truth-value-testing

--
assignee: docs@python -> 
nosy: +SilentGhost -docs@python
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36168] DOC: Fix capitalization in string.rst

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Mariatta, I see it also needs a backport to 3.8

We can close it once the backport is completed.

--
nosy: +CuriousLearner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37463] socket.inet_aton IP parsing issue in ssl.match_hostname

[STINNER Victor]

STINNER Victor  added the comment:

> It's a potential security bug although low severity.

What is the worst that can happen with this issue?

Other the client doesn't validate the cert at all, and so this issue has no 
impact, or the client validates the cert and trusts the CA, but the host isn't 
fully validated... Ok, but could someone abuse "1.1.1.1 ; this should not work 
but does"? Does a web browser accept such hostname? Or can it be used to inject 
SQL or a shell command for example?

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37458] ast: Different FormattedValue expressions have same col_offset information

[Eric V. Smith]

Eric V. Smith  added the comment:

I'm working on overhauling how these are calculated. But it's complex, and is 
taking a while.

--
assignee:  -> eric.smith
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37465] Incorrect documentation for `s#` arguments in C API argument parsing

[Enrico Zini]

Enrico Zini  added the comment:

Oh! Fair enough, I had missed it. Does the note also involve `Py_BuildValue`? 
If so, the documentation of `Py_BuildValue` should probably be updated; if not, 
I think it would be clearer if the note mentioned that it only applies to 
parsing, not building, values.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37406] Disable runtime checks in release mode

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

> Python's exception mechanism is a much better way to signal and handle such 
> errors at the application level.

I disagree. There is a difference between exceptions which are possible in 
normal usage of the code and real bugs, which shouldn't ever happen. A NULL 
argument to a C API function is not an ordinary exception, it's a real bug. 
Even if we raise a Python exception for that, it should never be handled in a 
try/exception block like an ordinary exception.

> Using assert() in C is a pretty bad alternative, since this crashes the whole 
> process.

I *prefer* debugging an assert() failure (which is pretty easy with a decent 
debugger) rather than debugging a Python exception raised from C (which 
typically does NOT give a useful traceback).

--
nosy: +jdemeyer

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36390] IDLE: Refactor formatting methods from editor

[Tal Einat]

Tal Einat  added the comment:

Looking at the code yet again, there are several places where replacing 
classifyws() as I suggested would make it clunkier. So let's leave it there, at 
least in editor.py.

Still, the classifyws() implementation can be greatly simplified. See PR 
GH-14500 (with tests based on those Cheryl wrote).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[Eryk Sun]

Eryk Sun  added the comment:

>> If one of the processes in that list is gone, then (...) "The handle 
>> is invalid" (...) will prevent you from creating any new processes 
>> with Popen after that
>
> It's the first time that I see such bug report.

IIRC it's the second time I've seen that issue reported. It should be rare. It 
should only occur if some other code in our process or another process closes 
our _handle value. It's not our bug. Here's an example in 3.7:

>>> p = subprocess.Popen('python -c "input()"', stdin=subprocess.PIPE)
>>> del p
>>> subprocess._active
[]
>>> subprocess._active[0]._handle.Close()

The process is active, but something closed our handle. The next time 
Popen.__init__ calls _cleanup, _internal_poll raises OSError due to the invalid 
handle:

>>> subprocess.call('python -V')
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program Files\Python37\lib\subprocess.py", line 323, in call
with Popen(*popenargs, **kwargs) as p:
  File "C:\Program Files\Python37\lib\subprocess.py", line 664, in __init__
_cleanup()
  File "C:\Program Files\Python37\lib\subprocess.py", line 228, in _cleanup
res = inst._internal_poll(_deadstate=sys.maxsize)
  File "C:\Program Files\Python37\lib\subprocess.py", line 1216, in 
_internal_poll
if _WaitForSingleObject(self._handle, 0) == _WAIT_OBJECT_0:
OSError: [WinError 6] The handle is invalid

I wouldn't want _internal_poll to silence this error, but maybe it could be 
translated into a warning. That said, since there's no need to wait on a 
process in Windows, there's no need for __del__ to insert a running process in 
a list of active process, in which case there's nothing for _cleanup to do. 
Given we're in __del__, our private _handle is about to be closed, at least it 
will be in CPython. Other implementations should wait() or use a with 
statement, in order to explicitly close the process handle. The latter isn't 
implemented currently, but you opened issue 37410 to address this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36390] IDLE: Refactor formatting methods from editor

[Tal Einat]

Change by Tal Einat :


--
pull_requests: +14317
pull_request: https://github.com/python/cpython/pull/14500

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37466] Move casting prompt after its validation in _raw_input()

[myungsekyo]

New submission from myungsekyo :

I think it is more efficient to cast `variable prompt` into string after its 
validation in _raw_input().
Because If it is None or empty string then it is not used. 

```
import timeit

MAX = 1000


start = timeit.default_timer()
for i in range(MAX):
_raw_input()

end = timeit.default_timer()

print('estimated : {}'.format(end - start))

```
I tested on 10 millions inputs with above code.
and the result is as follows.

Before:
estimated : 5.060587857999053
estimated : 5.0425375679988065
estimated : 4.850400277999142
estimated : 4.888060468998447
estimated : 4.84954259771
estimated : 4.82267925859
estimated : 5.053791769001691
estimated : 4.914149145999545
estimated : 4.9584080040003755
estimated : 4.944711199001176

After:
estimated : 4.014042392998817
estimated : 3.987057284997718
estimated : 4.081281360999128
estimated : 4.06813505899845
estimated : 4.040622504999192
estimated : 4.1239150339970365
estimated : 4.174400065003283
estimated : 4.015272281998477
estimated : 4.034917910001241
estimated : 4.08582956799728

--
components: IO
messages: 346986
nosy: myungsekyo
priority: normal
severity: normal
status: open
title: Move casting prompt after its validation in _raw_input()
type: performance

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37462] Default starting directory for os.walk()

[Tal Einat]

Tal Einat  added the comment:

I agree with Serhiy: In this case, it seems to me that "explicit is better than 
implicit" should be the guiding principle.

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37466] Move casting prompt after its validation in _raw_input()

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +14318
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14502

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] print_exception() crash when lxml 4.2.5 raises a parser error

[STINNER Victor]

Change by STINNER Victor :


Added file: https://bugs.python.org/file48450/sf.xml

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] print_exception() crash when lxml 4.2.5 raises a parser error

[STINNER Victor]

New submission from STINNER Victor :

Using attached sf.py and sf.xml, I can crash Python. lxml builds a fake 
traceback to inject the XML filename the XML line number where the parsing 
error occurs. The problem is that the filename is a bytes object, whereas 
print_exception() expects the filename to be a Unicode string.

Attached PR fix the crash.

Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1665490


Example:

$ python3 sf.py

Traceback (most recent call last):
  File "sf.py", line 6, in 
xml2 = etree.parse("sf.xml")
  File "src/lxml/etree.pyx", line 3426, in lxml.etree.parse
  File "src/lxml/parser.pxi", line 1840, in lxml.etree._parseDocument
  File "src/lxml/parser.pxi", line 1866, in lxml.etree._parseDocumentFromURL
  File "src/lxml/parser.pxi", line 1770, in lxml.etree._parseDocFromFile
  File "src/lxml/parser.pxi", line 1163, in 
lxml.etree._BaseParser._parseDocFromFile
  File "src/lxml/parser.pxi", line 601, in 
lxml.etree._ParserContext._handleParseResultDoc
  File "src/lxml/parser.pxi", line 711, in lxml.etree._handleParseResult
  File "src/lxml/parser.pxi", line 651, in lxml.etree._raiseParseError
Segmentation fault (core dumped)


(gdb) frame 6
#6  0x77c85898 in print_exception (value=None, f=<_io.TextIOWrapper at 
remote 0x7fffea910708>)
at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c:753
753 /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c: No such 
file or directory.
(gdb) l
748 in /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Python/pythonrun.c
(gdb) p filename
$1 = b'sf.xml'
(gdb) p *filename
$2 = {
  ob_refcnt = 2, 
  ob_type = 0x77db5da0 
}


Extract of print_exception():

PyObject *message, *filename, *text;
int lineno, offset;
if (!parse_syntax_error(value, &message, &filename,
&lineno, &offset, &text))
PyErr_Clear();
else {
PyObject *line;

Py_DECREF(value);
value = message;

line = PyUnicode_FromFormat("  File \"%S\", line %d\n",   // 
<== HERE
  filename, lineno);
Py_DECREF(filename);


More gdb traceback:

Program received signal SIGSEGV, Segmentation fault.
find_maxchar_surrogates (num_surrogates=, maxchar=, 
end=0xfffd , begin=0x1 )
at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:1660
1660/usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c: No 
such file or directory.
Missing separate debuginfos, use: dnf debuginfo-install 
abrt-libs-2.12.0-2.fc30.x86_64 augeas-libs-1.12.0-1.fc30.x86_64 
bzip2-libs-1.0.6-29.fc30.x86_64 dbus-libs-1.12.16-1.fc30.x86_64 
elfutils-libelf-0.176-3.fc30.x86_64 elfutils-libs-0.176-3.fc30.x86_64 
expat-2.2.6-2.fc30.x86_64 glib2-2.60.4-1.fc30.x86_64 
libacl-2.2.53-3.fc30.x86_64 libcap-2.26-5.fc30.x86_64 
libdb-5.3.28-37.fc30.x86_64 libffi-3.1-19.fc30.x86_64 
libgcc-9.1.1-1.fc30.x86_64 libgcrypt-1.8.4-3.fc30.x86_64 
libgpg-error-1.33-2.fc30.x86_64 libmount-2.33.2-1.fc30.x86_64 
libreport-2.10.0-3.fc30.x86_64 libselinux-2.9-1.fc30.x86_64 
libstdc++-9.1.1-1.fc30.x86_64 libtar-1.2.20-17.fc30.x86_64 
libtool-ltdl-2.4.6-29.fc30.x86_64 libuuid-2.33.2-1.fc30.x86_64 
libxcrypt-4.4.6-2.fc30.x86_64 libxml2-2.9.9-2.fc30.x86_64 
libxslt-1.1.33-1.fc30.x86_64 libzstd-1.4.0-1.fc30.x86_64 
lz4-libs-1.8.3-2.fc30.x86_64 pcre-8.43-2.fc30.x86_64 popt-1.16-17.fc30.x86_64 
python3-abrt-2.12.0-2.fc30.x86_64 python3-dbus-1.2.8-5.fc30.x86_64 
python3-libreport-2.10
 .0-3.fc30.x86_64 python3-lxml-4.2.5-2.fc30.x86_64 
python3-systemd-234-8.fc30.x86_64 python3-xmlsec-1.3.3-5.fc30.x86_64 
rpm-libs-4.14.2.1-4.fc30.1.x86_64 systemd-libs-241-8.git9ef65cb.fc30.x86_64 
xmlsec1-1.2.27-2.fc30.x86_64 xmlsec1-openssl-1.2.27-2.fc30.x86_64 
xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64
(gdb) where
#0  0x77c321ad in find_maxchar_surrogates
(num_surrogates=, maxchar=, 
end=0xfffd , begin=0x1 ) at 
/usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:1660
#1  0x77c321ad in _PyUnicode_Ready (unicode=b'sf.xml') at 
/usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:1699
#2  0x77afad8e in unicode_fromformat_write_str (precision=-1, width=-1, 
str=, writer=0x7fffcb20)
at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2596
#3  0x77afad8e in unicode_fromformat_arg (vargs=0x7fffcb80, 
f=, writer=0x7fffcb20)
at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2807
#4  0x77afad8e in PyUnicode_FromFormatV (format=, 
vargs=)
at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2914
#5  0x77b82a99 in PyUnicode_FromFormat 
(format=format@entry=0x77c9b045 "  File \"%U\", line %d\n")
at /usr/src/debug/python3-3.7.3-3.fc30.x86_64/Objects/unicodeobject.c:2966
#6  0x77c85898 in print_exception (value=None, f=

[issue37209] Add what's new entries for pickle enhancements

[Pierre Glaser]

Change by Pierre Glaser :


--
keywords: +patch
pull_requests: +14319
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14503

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37466] Move casting prompt after its validation in _raw_input()

[Tal Einat]

Tal Einat  added the comment:

This is a subtle change with the potential to affect more than just 
performance. Also, in this case, the performance is likely negligible in every 
actual use-case.

This might actually be more correct, though. For example, one would expect 
passing prompt=None to result in no prompt displayed, rather than "None".

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37462] Default starting directory for os.walk()

[aeros167]

aeros167  added the comment:

Oh okay, that's fair enough. I can definitely understand that assigning the 
current directory as the default does not provide a significant change in 
improved functionality, and it is not implicit that os.walk() would use the 
current directory as the default option. Even if this change was approved, it 
is likely that many would never notice a difference. After reading the 
criticisms, I can also understand that the value of this feature would be too 
niche and does not justify the maintenance. It may also lead to some 
unnecessary confusion. 

Thanks for the constructive feedback serhiy and taleinat. I'm quite new to 
making contributions to Python (only a couple of minor merged PRs) and working 
on open source projects in general. This was my first attempt at coming up with 
an original issue for Python. As a result, I'm not entirely certain as to what 
qualifies as being adequately valuable enough to justify creating an issue. I 
have some basic understanding from others that I've looked over, but it seems 
like it might be a bit of a trial by error process. 

Before attempting to create any more original issues, I'll work on existing 
issues and the suggestions of others to develop a better practical 
understanding of the standards. 

I'll close this issue and the pull request, but I'll be sure to read over any 
other responses that are made. I definitely appreciate the criticism.

--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37466] Move casting prompt after its validation in _raw_input()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I don't think that will work. If the user passes a non-string which is falsey, 
your patch will attempt to write it directly to the stream without converting 
it to a string.

Try ``_raw_input(0)`` as an example.

Tal Einat:
> one would expect passing prompt=None to result in no prompt displayed

I wouldn't. That's not how getpass works now, or input.

By the way, myungsekyo, that's not the best way to use timeit to time code 
snippets. You are timing the overhead of the loop, ten million lookups of the 
name "_raw_input", and most importantly, ten million times that _raw_input 
halts waiting for input from the user. Surely you didn't sit there hitting 
Enter over and over again?

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] print_exception() crash when lxml/xmlsec raises a parser error

[STINNER Victor]

STINNER Victor  added the comment:

The bug can be reproduced on the master branch of Python. I tested with 
versions:

* lxml 4.3.4
* xmlsec 1.3.3  

The filename comes from a lxml.etree.XMLSyntaxError exception which inherits 
from SyntaxError. The bug can be reproduced without lxml nor xmlsec, just with 
attached excepthook_syntaxerror.py:

$ ./python excepthook_syntaxerror.py
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/excepthook_syntaxerror.py", line 3, 
in 
raise SyntaxError("msg", (b"bytes_filename", 123, 0, "text"))
Objects/unicodeobject.c:492: _PyUnicode_CheckConsistency: Assertion 
"((PyObject*)(op))->ob_type))->tp_flags & ((1UL << 28))) != 0)" failed
Enable tracemalloc to get the memory block allocation traceback

object  : b'bytes_filename'
type: bytes
refcount: 4
address : 0x7fe22fe7ce50
Fatal Python error: _PyObject_AssertFailed

Current thread 0x7fe23cfbf740 (most recent call first):
  File "/home/vstinner/prog/python/master/excepthook_syntaxerror.py", line 5 in 

Aborted (core dumped)


excepthook_syntaxerror.py uses:

raise SyntaxError("msg", (b"bytes_filename", 123, 0, "text"))

--
title: print_exception() crash when lxml 4.2.5 raises a parser error -> 
print_exception() crash when lxml/xmlsec raises a parser error
versions: +Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48451/excepthook_syntaxerror.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

Change by STINNER Victor :


--
title: print_exception() crash when lxml/xmlsec raises a parser error -> 
sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes 
filename

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Petr Viktorin]

Petr Viktorin  added the comment:


New changeset 4a2edc34a405150d0b23ecfdcb401e7cf59f4650 by Petr Viktorin (Pablo 
Galindo) in branch 'master':
bpo-37221: Add PyCode_NewWithPosOnlyArgs to be used internally and set 
PyCode_New as a compatibility wrapper (GH-13959)
https://github.com/python/cpython/commit/4a2edc34a405150d0b23ecfdcb401e7cf59f4650


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +14320
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14504

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37221] PyCode_New API change breaks backwards compatibility policy

[miss-islington]

Change by miss-islington :


--
pull_requests: +14321
pull_request: https://github.com/python/cpython/pull/14505

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[STINNER Victor]

STINNER Victor  added the comment:

> subprocess._active[0]._handle.Close()

Why would you do that? You should not access the private _active list, nor 
access the private _handle attribute. I understand that it's a way to trigger 
such bug, but is it possible to trigger this bug without accessing any private 
attribute?


> I wouldn't want _internal_poll to silence this error, but maybe it could be 
> translated into a warning

I disagree with that. It's very bad is suddenly the handle becomes invalid for 
no obvious reason. It's better to get an hard error (exception) in such case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37406] Disable runtime checks in release mode

[STINNER Victor]

STINNER Victor  added the comment:

FYI I'm finishing an article to explain the problem that I am trying to solve 
here. Sorry for the delay, I will reply later :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[Miro Hrončok]

Change by Miro Hrončok :


--
keywords: +patch
pull_requests: +14322
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14506

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37221] PyCode_New API change breaks backwards compatibility policy

[STINNER Victor]

STINNER Victor  added the comment:

https://github.com/cython/cython/pull/3009 was merged. Is it part of Cython 
0.29.11 released yesterday?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Petr Viktorin]

Petr Viktorin  added the comment:

> https://github.com/cython/cython/pull/3009 was merged.

(to master, so far)

> Is it part of Cython 0.29.11 released yesterday?

It should be, see: https://cython.readthedocs.io/en/latest/src/changes.html#id2

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[Miro Hrončok]

Miro Hrončok  added the comment:

I've opened a PR thet removes the support for bdist_wininst on non-Windows. 
Apparently, it was broken since the beginning of Py3k anyway. The support can 
be reintroduced once it is actually fixed (or never).

https://github.com/python/cpython/pull/14506

--
nosy: +hroncok

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[STINNER Victor]

STINNER Victor  added the comment:

> I've opened a PR thet removes the support for bdist_wininst on non-Windows. 
> Apparently, it was broken since the beginning of Py3k anyway. The support can 
> be reintroduced once it is actually fixed (or never).

It would be better to use the Unicode (wide character) flavor of the Windows 
API to avoid completely any explicitly encoding, and only pass Unicode strings. 
But This issue is open for 8 years and it seems like nobody cares enough to 
invest time to implement such change.

So I'm fine with trivial PR 14506. It doesn't change the status quo: bdist_win 
was always broken on non-Windows platforms since Python 3.0, but the PR makes 
the status quo more obvious which is a good thing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37462] Default starting directory for os.walk()

[aeros167]

aeros167  added the comment:

For any future issues, is it more appropriate to leave the issue status on 
pending until the proposal is approved? This may not apply if the issue was 
specifically mentioned or requested by a core developer, but it may be better 
to use pending for any original issues that I propose until they have received 
feedback.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[STINNER Victor]

STINNER Victor  added the comment:

I started a discussion on the Packaging list:

"Deprecate bdist_wininst" 
https://discuss.python.org/t/deprecate-bdist-wininst/1929

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37462] Default starting directory for os.walk()

[Tal Einat]

Tal Einat  added the comment:

Hi Kyle,

First off, thanks for bringing this up, and for taking our feedback so well!

> Before attempting to create any more original issues, I'll work on existing 
> issues and the suggestions of others to develop a better practical 
> understanding of the standards. 

Do not be discouraged that one of the first suggestions you've made has been 
rejected; this is normal and happens all of the time.

In the future, you could also bring up such ideas for discussion on the 
python-ideas mailing list to "test the water" before opening an issue.

> For any future issues, is it more appropriate to leave the issue status on 
> pending until the proposal is approved?

In the future, you don't have to set the status to anything special when 
creating a new issue. The default, "open", is what it should be to begin with.

--
resolution:  -> rejected

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37466] Move casting prompt after its validation in _raw_input()

[Tal Einat]

Tal Einat  added the comment:

>> one would expect passing prompt=None to result in no prompt displayed

> I wouldn't. That's not how getpass works now, or input.

Ah, thanks for the input, Steve. In that case, this should likely not be 
changed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37221] PyCode_New API change breaks backwards compatibility policy

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset cb083f7cdf604c1d9d264f387f9e8846bc953eb3 by Łukasz Langa (Miss 
Islington (bot)) in branch '3.8':
bpo-37221: Add PyCode_NewWithPosOnlyArgs to be used internally and set 
PyCode_New as a compatibility wrapper (GH-13959) (#14505)
https://github.com/python/cpython/commit/cb083f7cdf604c1d9d264f387f9e8846bc953eb3


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified

[miss-islington]

Change by miss-islington :


--
pull_requests: +14323
pull_request: https://github.com/python/cpython/pull/14507

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified

[miss-islington]

Change by miss-islington :


--
pull_requests: +14324
pull_request: https://github.com/python/cpython/pull/14508

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 84de34e39eb9e49b2ae691c6f67df8d7da3561de by Vinay Sajip in branch 
'master':
bpo-32934: Clarified meaning of 'capacity' for BufferingHandler and 
MemoryHandler. (GH-14498)
https://github.com/python/cpython/commit/84de34e39eb9e49b2ae691c6f67df8d7da3561de


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[Eryk Sun]

Eryk Sun  added the comment:

>> subprocess._active[0]._handle.Close()
>
> Why would you do that? You should not access the private _active list, 
> nor access the private _handle attribute. I understand that it's a way 
> to trigger such bug, but is it possible to trigger this bug without 
> accessing any private attribute?

The example is just emulating a problem from someone else's code that's closing 
our handle. Typically this situation occurs because the code is holding onto a 
handle value for a kernel object (File, Section, Job, Process, Thread, Event, 
etc) that got closed. The handle value eventually gets reused, such as for our 
_handle. 

>> I wouldn't want _internal_poll to silence this error, but maybe it 
>> could be translated into a warning
>
> I disagree with that. It's very bad is suddenly the handle becomes 
> invalid for no obvious reason. It's better to get an hard error 
> (exception) in such case.

I agree, but the exception breaks Popen.__init__. It would have to be ignored 
or translated to a warning somewhere if we continues to poll a list of active 
processes every time __init__() is called. But since the latter is unnecessary 
in Windows, I suggested to just skip it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 471d785dc759eb2e9c06f077f323cf136d32506b by Vinay Sajip (Miss 
Islington (bot)) in branch '3.7':
bpo-32934: Clarified meaning of 'capacity' for BufferingHandler and 
MemoryHandler. (GH-14498) (GH-14508)
https://github.com/python/cpython/commit/471d785dc759eb2e9c06f077f323cf136d32506b


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified

[Vinay Sajip]

Vinay Sajip  added the comment:


New changeset 3db5c5c7630af92336a8c0a269e05607cd68f9e7 by Vinay Sajip (Miss 
Islington (bot)) in branch '3.8':
bpo-32934: Clarified meaning of 'capacity' for BufferingHandler and 
MemoryHandler. (GH-14498) (GH-14507)
https://github.com/python/cpython/commit/3db5c5c7630af92336a8c0a269e05607cd68f9e7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +14325
pull_request: https://github.com/python/cpython/pull/14509

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 72cd653c4ed7a4f8f8fb06ac364b08a97085a2b5 by Victor Stinner (Miro 
Hrončok) in branch 'master':
bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506)
https://github.com/python/cpython/commit/72cd653c4ed7a4f8f8fb06ac364b08a97085a2b5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified

[Vinay Sajip]

Change by Vinay Sajip :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[miss-islington]

Change by miss-islington :


--
pull_requests: +14326
pull_request: https://github.com/python/cpython/pull/14510

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37468] Don't install wininst*.exe on non-Windows platforms

[STINNER Victor]

New submission from STINNER Victor :

bdist_wininst only works on Windows: see bpo-10945 and commit 
72cd653c4ed7a4f8f8fb06ac364b08a97085a2b5. So 
$PREFIX/lib/python3.9/distutils/command/wininst-*.exe are useless on Linux (for 
example).

Attached PR modify "make install" to not longer install wininst-*.exe files.

I propose to only modify Python 3.9. Even if bdist_wininst only works on 
Windows on Python 3.*, I don't feel the need to modify other branches.

I also started a "Deprecate bdist_wininst" discussion on the Packaging list:
https://discuss.python.org/t/deprecate-bdist-wininst/1929

--

Currently, I get these .exe files:

$ find /opt/py39dbg/ -name "*.exe"
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-32.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-10.0-amd64.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-10.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-14.0-amd64.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-14.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-6.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-7.1.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-8.0.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-9.0-amd64.exe
/opt/py39dbg/lib/python3.9/distutils/command/wininst-9.0.exe

site-packages/setuptools/ and site-packages/pip/ are out of the scope of this 
issue.


With my PR:

vstinner@apu$ find /opt/py39dbg/ -name "*.exe"
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/gui-32.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-64.exe
/opt/py39dbg/lib/python3.9/site-packages/setuptools/cli-32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/w32.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t64.exe
/opt/py39dbg/lib/python3.9/site-packages/pip/_vendor/distlib/t32.exe

/opt/py39dbg/lib/python3.9/distutils/command/wininst-*.exe files are gone.


--


wininst-*.exe files are created from PC/bdist_wininst/ program.

October 2018, there was a discussion about the license of these files:
https://mail.python.org/pipermail/python-dev/2018-October/155507.html

The Fedora package of Python 3.7 already explicitly removes these .exe files:

* https://bugzilla.redhat.com/show_bug.cgi?id=525469
* 
https://src.fedoraproject.org/rpms/python3/c/1092d478f540ba9d510316205eca201e5c5d07e9?branch=master
* https://bugzilla.redhat.com/show_bug.cgi?id=1426250
* https://bugzilla.redhat.com/show_bug.cgi?id=1426257

--
components: Library (Lib)
messages: 347010
nosy: vstinner
priority: normal
severity: normal
status: open
title: Don't install wininst*.exe on non-Windows platforms
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[miss-islington]

miss-islington  added the comment:


New changeset 45c10da40912e04c0d0de02af4b23438ed0de49b by Miss Islington (bot) 
in branch '3.7':
bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506)
https://github.com/python/cpython/commit/45c10da40912e04c0d0de02af4b23438ed0de49b


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37468] Don't install wininst*.exe on non-Windows platforms

[STINNER Victor]

STINNER Victor  added the comment:

Debian doesn't distribute wininst*.exe binaries in their python* packages. 
debian/rules explicitly removes thesee files:

find $(d) -name 'wininst*.exe' | xargs -r rm -f

--

RHEL7 issue closed as WONTFIX:
https://bugzilla.redhat.com/show_bug.cgi?id=1566459

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37468] Don't install wininst*.exe on non-Windows platforms

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +14327
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14511

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[miss-islington]

miss-islington  added the comment:


New changeset be5bb52f5f2d4da4b9d6f42399f7275ab47910f3 by Miss Islington (bot) 
in branch '3.8':
bpo-10945: Drop support for bdist_wininst on non-Windows systems (GH-14506)
https://github.com/python/cpython/commit/be5bb52f5f2d4da4b9d6f42399f7275ab47910f3


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37461] email.parser.Parser hang

[Marcin Niemira]

Marcin Niemira  added the comment:

Sounds like there is an infinite loop here:


```
Pdb) 
> /usr/lib/python3.7/email/_header_value_parser.py(2370)get_parameter()
-> v.append(token)
(Pdb) 
> /usr/lib/python3.7/email/_header_value_parser.py(2365)get_parameter()
-> while value:
```

the ```v.append(token)``` is just growing with ```ValueTerminal(''), 
ValueTerminal(''), ValueTerminal('')...```

I'd be happy to try to fix this.

--
nosy: +Marcin Niemira

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[STINNER Victor]

STINNER Victor  added the comment:

Follow-up issue: bpo-37468 "Don't install wininst*.exe on non-Windows 
platforms".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[STINNER Victor]

STINNER Victor  added the comment:

> The example is just emulating a problem from someone else's code that's 
> closing our handle. Typically this situation occurs because the code is 
> holding onto a handle value for a kernel object (File, Section, Job, Process, 
> Thread, Event, etc) that got closed.

Without accessing private attributes, I don't see how someone can discover the 
private handle. So for me, it's more a serious bug in an application, no? 
Blindly closing random handles doesn't sound like a good idea to me.

> The handle value eventually gets reused, such as for our _handle.

That's a side effect on the blindly closing random handles.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37250] C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed

[Nick Coghlan]

Change by Nick Coghlan :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> compile error

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.

[Martijn Pieters]

New submission from Martijn Pieters :

The implementation of the logging.handler.QueueHandler and 
logging.handler.QueueListener does not make use of the task tracking API of 
queues (queue.task_done(), queue.join()) nor does it care if the queue is 
unbounded (queue.full(), catching the Full exception).

As such, it can work just as well with the new queue.SimpleQueue implementation 
(new in 3.7, see 
https://docs.python.org/3/library/queue.html#queue.SimpleQueue), which is fast 
and lightweight, implemented in C.

Can the documentation be updated to make this option explicit?

--
assignee: docs@python
components: Documentation
messages: 347017
nosy: docs@python, mjpieters
priority: normal
severity: normal
status: open
title: Make it explicit that logging QueueHandler / QueueListener accepts a 
SimpleQueue.
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler

[Martijn Pieters]

New submission from Martijn Pieters :

The documentation doesn't make it explicit what happens if you use a bounded 
queue together with logging.handlers.QueueHandler.

If the queue is bounded in size and attempts are made to add logrecords faster 
than a queue listener removes them, then the resulting `queue.Full` exception 
is passed to `handler.handleError()` and that usually means the record is 
simply dropped (see 
https://docs.python.org/3/library/logging.html#logging.Handler.handleError).

That may be the desired behaviour, but making it explicit is always better.

--
assignee: docs@python
components: Documentation
messages: 347018
nosy: docs@python, mjpieters
priority: normal
severity: normal
status: open
title: Make it explicit what happens when using a bounded queue with 
QueueHandler
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[Eryk Sun]

Eryk Sun  added the comment:

> Without accessing private attributes, I don't see how someone can 
> discover the private handle. So for me, it's more a serious bug in an 
> application, no? Blindly closing random handles doesn't sound like a 
> good idea to me.

Say a library calls CreateEventW and gets handle 32. It passes this handle to 
some other library, which uses the event and closes the handle when it no 
longer needs it. But due to a miscommunication in the documentation, the first 
library thinks the handle remains open. Now handle 32 is free for reuse, but 
the library doesn't know this. subprocess.Popen subsequently calls 
CreateProcessW and gets handle 32. Later on, the library closes handle 32, 
making it invalid, at least until it gets assigned to some other kernel object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37209] Add what's new entries for pickle enhancements

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset ec6c1bd0491590f3c0e2908a7b2dfb91b6acdae9 by Antoine Pitrou 
(Pierre Glaser) in branch 'master':
bpo-37209: Add pickle entry for 3.8 whatsnew (GH-14503)
https://github.com/python/cpython/commit/ec6c1bd0491590f3c0e2908a7b2dfb91b6acdae9


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37209] Add what's new entries for pickle enhancements

[miss-islington]

Change by miss-islington :


--
pull_requests: +14328
pull_request: https://github.com/python/cpython/pull/14512

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37444] Differing exception between builtins and importlib when importing beyond top-level package

[Nick Coghlan]

Nick Coghlan  added the comment:

ImportError sounds right to me.

We already raise that just above this for the "no dots at all" case, so also 
raising it for the "not enough dots" case makes more sense than leaving them 
different.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37209] Add what's new entries for pickle enhancements

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset e224d2865aa0f021b25d68de9a6c2be617341f4c by Antoine Pitrou (Miss 
Islington (bot)) in branch '3.8':
bpo-37209: Add pickle entry for 3.8 whatsnew (GH-14503) (GH-14512)
https://github.com/python/cpython/commit/e224d2865aa0f021b25d68de9a6c2be617341f4c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37471] mmap module, adding new constant

[David CARLIER]

Change by David CARLIER :


--
components: Extension Modules, FreeBSD
nosy: devnexen, koobs
priority: normal
pull_requests: 14329
severity: normal
status: open
title: mmap module, adding new constant
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37454] Clarify docs for math.log1p()

[Steven D'Aprano]

Change by Steven D'Aprano :


--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37471] mmap module, adding new constant

[Kubilay Kocak]

New submission from Kubilay Kocak :

Thanks David!

Can this be backported to earlier 3.x's and 2.7?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37471] mmap module, add MAP_ALIGNED_SUPER FreeBSD constant

[Kubilay Kocak]

Change by Kubilay Kocak :


--
title: mmap module, adding new constant -> mmap module, add MAP_ALIGNED_SUPER 
FreeBSD constant

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37380] subprocess.Popen._cleanup() "The handle is invalid" error when some old process is gone

[STINNER Victor]

STINNER Victor  added the comment:

> Say a library calls CreateEventW and gets handle 32. It passes this handle to 
> some other library, which uses the event and closes the handle when it no 
> longer needs it. But due to a miscommunication in the documentation, the 
> first library thinks the handle remains open. Now handle 32 is free for 
> reuse, but the library doesn't know this. subprocess.Popen subsequently calls 
> CreateProcessW and gets handle 32. Later on, the library closes handle 32, 
> making it invalid, at least until it gets assigned to some other kernel 
> object.

So yeah, it's a severe bug in an application. An application should not close 
the wrong handle by mistake :-) 

Thanks for the explanation. So it would be "nice" to backport the change to 
reduce the impact of such application bug, but it's not really a bug in Python 
itself. Python cannot fully protect developers for such class of bugs.

On Unix, there is a similar bug with applications trying to close a file 
descriptor which is already closed. It can lead to very severe bugs (crashes):
https://bugs.python.org/issue18748

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Nick Coghlan]

Nick Coghlan  added the comment:

Reviewing the thread, we never actually commented on thautwarm's proposal in 
https://bugs.python.org/issue12782#msg327875 that aims to strip out any INDENT, 
NEWLINE, and DEDENT tokens that appear between the opening "with" keyword and 
the statement header terminating ":".

The problem with that is that line continuations are actually handled by the 
tokenizer, *not* the compiler, and the tokenizer already switches off the 
INDENT/NEWLINE/DEDENT token generation based on the following rules:

* tracking opening & closing of triple-quoted strings 
* tracking opening & closing of parentheses ("()"), brackets ("[]"), and braces 
("{}")
* detecting a backslash immediately followed by a newline

By design, the tokenizer is generally unaware of which NAME tokens are actually 
keywords - it's only aware of async & await at the moment as part of the 
backwards compatibility dance that allowed those to be gradually converted to 
full keywords over the course of a couple of releases.

Hence why INDENT/NEWLINE/DEDENT never appear inside expressions in the Grammar: 
the tokenization rules mean that those tokens will never appear in those 
locations.

And it isn't simply a matter of making the tokenizer aware of the combination 
of "with" and ":" as a new pairing that ignores linebreaks between them, as ":" 
can appear in many subexpressions (e.g. lambda functions, slice notation, and 
the new assignments expressions), and it's only the full parser that has enough 
context to tell which colon is the one that actually ends the statement header.

Thus the design requirement is to come up with a grammar rule that allows this 
existing code to continue to compile and run correctly:

```
>>> from contextlib import nullcontext
>>> with (nullcontext()) as example:
... pass
... 
>>> 
```

While also enabling new code constructs like the following:


with (nullcontext() as example):
pass

with (nullcontext(), nullcontext()):
pass

with (nullcontext() as example, nullcontext()):
pass

with (nullcontext(), nullcontext() as example):
pass

with (nullcontext() as example1, nullcontext() as example2):
pass

If we can get the Grammar to allow those additional placements of parentheses, 
then the existing tokenizer will take care of the rest.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37471] mmap module: add MAP_ALIGNED_SUPER FreeBSD constant

[STINNER Victor]

STINNER Victor  added the comment:

> Can this be backported to earlier 3.x's and 2.7?

No, a new constant is a new feature. If we add it to Python 3.7.4, it would 
mean that an application written with 3.7.4 will fail on 3.7.3 which would be 
surprising and bad.

--
nosy: +vstinner
title: mmap module, add MAP_ALIGNED_SUPER FreeBSD constant -> mmap module: add 
MAP_ALIGNED_SUPER FreeBSD constant
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37471] mmap module: add MAP_ALIGNED_SUPER FreeBSD constant

[Kubilay Kocak]

Kubilay Kocak  added the comment:

Thanks for clarifying Victor

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[miss-islington]

Change by miss-islington :


--
pull_requests: +14330
pull_request: https://github.com/python/cpython/pull/14514

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f9b7457bd7f438263e0d2dd1f70589ad56a2585e by Victor Stinner in 
branch 'master':
bpo-37467: Fix PyErr_Display() for bytes filename (GH-14504)
https://github.com/python/cpython/commit/f9b7457bd7f438263e0d2dd1f70589ad56a2585e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +14331
pull_request: https://github.com/python/cpython/pull/14515

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

STINNER Victor  added the comment:

Python 2.7 is not affected:

const char *filename, *text;
int lineno, offset;
if (!parse_syntax_error(value, &message, &filename,
&lineno, &offset, &text))
PyErr_Clear();
else {
char buf[10];
PyFile_WriteString("  File \"", f);
if (filename == NULL)
PyFile_WriteString("", f);
else
PyFile_WriteString(filename, f);
PyFile_WriteString("\", line ", f);
PyOS_snprintf(buf, sizeof(buf), "%d", lineno);
PyFile_WriteString(buf, f);
PyFile_WriteString("\n", f);

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[miss-islington]

miss-islington  added the comment:


New changeset 2683ded568b24fff1139edd9127a349f432292a6 by Miss Islington (bot) 
in branch '3.8':
bpo-37467: Fix PyErr_Display() for bytes filename (GH-14504)
https://github.com/python/cpython/commit/2683ded568b24fff1139edd9127a349f432292a6


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37472] Remove Lib/test/outstanding_bugs.py

[STINNER Victor]

New submission from STINNER Victor :

Lib/test/outstanding_bugs.py was created by:

commit c4e2a9b70ac49cdd8bcc9ca60afac20162f84f24
Author: Georg Brandl 
Date:   Sun Jan 8 14:32:19 2006 +

Add a test file (which isn't run by regrtest) for bugs which
aren't fixed yet.

Includes a first test (for compiler).

and has not been touched since:


commit bdce938af2af03b2eb0d0e4731f1b8c4b965eaf5
Author: Zachary Ware 
Date:   Fri Dec 20 13:25:07 2013 -0600

Update test.outstanding_bugs.py

diff --git a/Lib/test/outstanding_bugs.py b/Lib/test/outstanding_bugs.py
index 0849ee5885..7e527a6706 100644
--- a/Lib/test/outstanding_bugs.py
+++ b/Lib/test/outstanding_bugs.py
@@ -10,79 +10,9 @@ import unittest
 from test import support
 
 #
-# One test case for outstanding bugs at the moment:
+# No test cases for outstanding bugs at the moment.
 #
(...)


I propose to remove this file. We don't manage "outstanding bugs" this way 
anymore.

--
components: Tests
messages: 347031
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove Lib/test/outstanding_bugs.py
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37472] Remove Lib/test/outstanding_bugs.py

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +14332
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14516

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37473] importlib: Remove libregrtest hack: "We import importlib *ASAP* in order to test #15386"

[STINNER Victor]

New submission from STINNER Victor :

Lib/test/regrtest.py starts with:

# We import importlib *ASAP* in order to test #15386
import importlib

If there is a bug to test, would it be possible to write a dedicated test, 
rather than putting the test... in the code of the test runner?

Code added by bpo-15386:

commit be7e49fd820318509cd8b4dbde479c552f74ef62
Author: Nick Coghlan 
Date:   Fri Jul 20 23:40:09 2012 +1000

Close #15386: There was a loophole that meant importlib.machinery and imp 
would sometimes reference an uninitialised copy of importlib._bootstrap

(...)

diff --git a/Lib/runpy.py b/Lib/runpy.py
index d612727c6f..39c0e9f7dd 100644
--- a/Lib/runpy.py
+++ b/Lib/runpy.py
@@ -12,8 +12,8 @@ importers when locating support scripts as well as when 
importing modules.
 
 import os
 import sys
+import importlib.machinery # importlib first so we can test #15386 via -m
 import imp
-import importlib.machinery
 from pkgutil import read_code, get_loader, get_importer
 
 __all__ = [
diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py
index 28655f0e65..3c8359aca1 100755
--- a/Lib/test/regrtest.py
+++ b/Lib/test/regrtest.py
@@ -165,6 +165,9 @@ example, to run all the tests except for the gui tests, 
give the
 option '-uall,-gui'.
 """
 
+# We import importlib *ASAP* in order to test #15386
+import importlib
+
 import builtins
 import faulthandler
 import getopt
diff --git a/Lib/test/test_import.py b/Lib/test/test_import.py
index 89ec8dcedc..51b52c7e0b 100644
--- a/Lib/test/test_import.py
+++ b/Lib/test/test_import.py
@@ -1,8 +1,9 @@
+# We import importlib *ASAP* in order to test #15386
+import importlib
 import builtins
 import imp
 from importlib.test.import_ import test_suite as importlib_import_test_suite
 from importlib.test.import_ import util as importlib_util
-import importlib
 import marshal
 import os
 import platform

--
components: Tests
messages: 347032
nosy: brett.cannon, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: importlib: Remove libregrtest hack: "We import importlib *ASAP* in order 
to test #15386"
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36926] Implement methoddescr_call without _PyMethodDef_RawFastCallDict

[Jeroen Demeyer]

Jeroen Demeyer  added the comment:

Superseded by PR 13781

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37231] Optimize calling special methods

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36924] Simplify implementation of classmethod_descriptor.__call__

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37454] Clarify docs for math.log1p()

[Tim Peters]

Tim Peters  added the comment:

Mark's analysis is spot-on - good eye :-)

Here under 3.7.3 [MSC v.1916 64 bit (AMD64)] on win32, in the original script 
it makes no difference at all for negative "small x" (where, as Mark said, `1 - 
random.random()` is exactly representable):

Counter({'equal': 50058, 'offset_log': 41936, 'regular_log': 8006})
Counter({'equal': 10})

Changing to Mark's 1e-3 * random.random():

Counter({'offset_log': 99958, 'equal': 42})
Counter({'offset_log': 99884, 'equal': 116})

And going on to use 1e-6 instead:

Counter({'offset_log': 10})
Counter({'offset_log': 10})

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8cbffc4d96d1da0fbc38da6f34f2da30c5ffd601 by Victor Stinner in 
branch '3.7':
bpo-37467: Fix PyErr_Display() for bytes filename (GH-14504) (GH-14515)
https://github.com/python/cpython/commit/8cbffc4d96d1da0fbc38da6f34f2da30c5ffd601


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37467] sys.excepthook (PyErr_Display) does crash with SyntaxError which has a bytes filename

[STINNER Victor]

STINNER Victor  added the comment:

Ok, it's not fixed in all affected maintained branches, I close the issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36904] Implement _PyStack_UnpackDict() with a single allocation

[Jeroen Demeyer]

Change by Jeroen Demeyer :


--
pull_requests: +14333
pull_request: https://github.com/python/cpython/pull/14517

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com