[issue38249] Optimize out Py_UNREACHABLE in the release mode

[STINNER Victor]

STINNER Victor  added the comment:

What does __builtin_unreachable()? Does it nothing? Call abort()?


> Py_UNREACHABLE is used to indicate that a specific point in the program 
> cannot be reached, even if the compiler might otherwise think it can.

I disagree here.
https://docs.python.org/dev/c-api/intro.html#c.Py_UNREACHABLE

For me, it's not an issue with the compiler, but more about handling corner 
cases. Py_UNREACHABLE() is used in cases which "should not occur" but can 
technically occur if you pass invalid data, or in "very unlikely case".

I looked at the Python code base.

tracemalloc_realloc():

if (ADD_TRACE(ptr2, new_size) < 0) {
/* Memory allocation failed. The error cannot be reported to
   the caller, because realloc() may already have shrunk the
   memory block and so removed bytes.

   This case is very unlikely: a hash entry has just been
   released, so the hash table should have at least one free entry.

   The GIL and the table lock ensures that only one thread is
   allocating memory. */
Py_UNREACHABLE();
}

Technically, Py_UNREACHABLE() can be reached if there is very low available 
memory, but it "should not".

dictobject.c:

static Py_ssize_t
lookdict_index(PyDictKeysObject *k, Py_hash_t hash, Py_ssize_t index)
{
size_t mask = DK_MASK(k);
size_t perturb = (size_t)hash;
size_t i = (size_t)hash & mask;

for (;;) {
Py_ssize_t ix = dictkeys_get_index(k, i);
if (ix == index) {
return i;
}
if (ix == DKIX_EMPTY) {
return DKIX_EMPTY;
}
perturb >>= PERTURB_SHIFT;
i = mask & (i*5 + perturb + 1);
}
Py_UNREACHABLE();
}

Here it's unclear to me if this case can be reached or not.

_PyLong_Format() calls Py_UNREACHABLE() if base is not in (2, 8, 16).

long_bitwise() calls Py_UNREACHABLE() if op is not in ('&', '^', '|'). 
Technically, this case cannot occur, since it's static function which has 
exactly 3 call sites all with valid 'op'. This *very specific* case could use 
__builtin_unreachable().

pytime.c:

_PyTime_t
_PyTime_GetSystemClock(void)
{
_PyTime_t t;
if (pygettimeofday(, NULL, 0) < 0) {
/* should not happen, _PyTime_Init() checked the clock at startup */
Py_UNREACHABLE();
}
return t;
}

_PyTime_t
_PyTime_GetPerfCounter(void)
{
_PyTime_t t;
if (_PyTime_GetPerfCounterWithInfo(, NULL)) {
Py_UNREACHABLE();
}
return t;
}

Clocks should not fail, but if they fail I would prefer to call Py_FatalError() 
to collect the traceback where the bug occurred.


> This is exact the case for __builtin_unreachable in GCC and Clang. I propose 
> to extend Py_UNREACHABLE() to __builtin_unreachable() in the release mode. 
> This will allow the compiler to generate more efficient code.
>
> If there are circumstances in which Py_UNREACHABLE() is reachable, then it is 
> improper use of Py_UNREACHABLE(). It should be replaced with raising an 
> appropriate exception (like TypeError, ValueError, RuntimeError or 
> SystemError) or, in extreme cases, with explicit Py_FatalError()
 
If you consider that it's really worth it to optimize Py_UNREACHABLE(), I would 
prefer to have a new macro which is only used for compiler warnings: for cases 
which really "cannot happen".

But it sounds hard to ensure that bugs cannot happen. I'm not sure that it's 
worth it to optimize Py_UNREACHABLE(). IMHO the current implementation is a 
good tradeoff between correctness and performance.

--

___
Python tracker 

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

[issue38249] Optimize out Py_UNREACHABLE in the release mode

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-38147.

--

___
Python tracker 

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

[issue38258] ctypes ignores when a DLL function is called with too many arguments

[Eryk Sun]

Eryk Sun  added the comment:

According to the docs, raising ValueError in this case has been a deprecated 
feature since 3.6.2, and the ability to do so no longer exists in 3.8. The 
documentation needs to be updated to reflect the new behavior.

https://docs.python.org/3.8/library/ctypes.html#calling-functions

In issue 35947, the customized libffi_msvc was replaced by standard libffi. 
ffi_call() in libffi_msvc returned a stack cleanup delta. This allowed raising 
ValueError in _call_function_pointer if the delta value was non-zero for an x86 
32-bit stdcall function (callee cleanup). A positive delta implied too many 
arguments, and a negative delta implied too few arguments. The standard libffi 
ffi_call() has no return value, so the code for raising ValueError was removed.

---

On a related note, PyCFuncPtr_call can be relaxed to allow the argument count 
to exceed the length of argtypes for x64 stdcall (but not x86). The 64-bit 
calling convention is the same for cdecl, stdcall, fastcall, and thiscall. It 
uses caller cleanup, like x86 cdecl, so we can skip raising TypeError in this 
case, just like we already do for cdecl.

--
assignee:  -> docs@python
components: +Documentation, Windows
nosy: +docs@python, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch
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

[issue38239] test_gdb fails on AMD64 Fedora Stable LTO 3.8 and AMD64 RHEL8 LTO 3.x: Unexpected gdb output

[Steve Dower]

Steve Dower  added the comment:

Greg seems to have done LTO related things in the past, maybe he knows? (All my 
PGO contributions only apply to Windows :) )

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[Steve Dower]

Steve Dower  added the comment:

Why are we keeping the DLL path around at all? It should only be being used in 
1-2 places during path calculation.

--
nosy: +steve.dower

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:

Steve:
> Why are we keeping the DLL path around at all? It should only be being used 
> in 1-2 places during path calculation.

_PyPathConfig_Init() initializes _Py_dll_path global variable which is only 
used by _Py_CheckPython3(). _Py_CheckPython3() is called at each 
_PyImport_FindSharedFuncptrWindows() call which is used by 
_PyImport_LoadDynamicModuleWithSpec() (to import a .pyd extension). I tried to 
minimize my changes to fix the issue, I tried to leave _Py_CheckPython3() 
unchanged. But I made one change in _Py_CheckPython3(): it handles the case 
_Py_dll_path=NULL... which should never occur, but I wasn't 100% sure that it 
really can never occur.

Python 3.6 (before my init work), _Py_CheckPython3() used "static wchar_t 
dllpath[MAXPATHLEN+1];": it was less important when dllpath is initialized.

--

_PyPathConfig_Calculate() of PC/getpathp.c now uses a temporary variable which 
stores the result of _Py_GetDLLPath().

--

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15912
pull_request: https://github.com/python/cpython/pull/16335

___
Python tracker 

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

[issue38258] ctypes ignores when a DLL function is called with too many arguments

[Sebastian Ernst]

New submission from Sebastian Ernst :

A c-function with the following signature ...

```C
int16_t __stdcall __declspec(dllimport) square_int(
int16_t a
);
```

... is being called with ctypes:

```python
def test_error_callargs_unconfigured_too_many_args():

dll = ctypes.windll.LoadLibrary('tests/demo_dll.dll')
square_int = dll.square_int

with pytest.raises(ValueError):
a = square_int(1, 2, 3)
```

Expected result: If the function is called with too many (positional) arguments 
(in the example 3 instead of 1), a `ValueError` should be raised. This is the 
case for at least CPython 3.4 to 3.7.

Actual result: "Nothing", i.e. no exception. The described test "fails". The 
function is called without an error - with CPython 3.8.0b4.

If this behavior is intended, is has not been (as far as I can tell) documented.

--
components: ctypes
messages: 353021
nosy: smernst
priority: normal
severity: normal
status: open
title: ctypes ignores when a DLL function is called with too many arguments
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue38252] Use 8-byte step to detect ASCII sequence in 64bit Windows builds

[Ma Lin]

Ma Lin  added the comment:

There are 4 functions have the similar code, see PR 16334.
Just replaced the `unsigned long` type with `size_t` type, got these benchmarks.
Can this be backported to 3.8 branch?

1.  bytes.isascii()

D:\dev\cpython\PCbuild\amd64\python.exe -m pyperf timeit -s "b = b'x' * 
100_000_000; f = b.isascii;" "f()"

+---+---+--+
| Benchmark | isascii_a | isascii_b|
+===+===+==+
| timeit| 11.7 ms   | 7.84 ms: 1.50x faster (-33%) |
+---+---+--+

2.  bytes.decode('latin1')

D:\dev\cpython\PCbuild\amd64\python.exe -m pyperf timeit -s "b = b'x' * 
100_000_000; f = b.decode;" "f('latin1')"

+---+--+-+
| Benchmark | latin1_a | latin1_b|
+===+==+=+
| timeit| 60.3 ms  | 57.4 ms: 1.05x faster (-5%) |
+---+--+-+

3.  bytes.decode('ascii')

D:\dev\cpython\PCbuild\amd64\python.exe -m pyperf timeit -s "b = b'x' * 
100_000_000; f = b.decode;" "f('ascii')"

+---+-+-+
| Benchmark | ascii_a | ascii_b |
+===+=+=+
| timeit| 48.5 ms | 47.1 ms: 1.03x faster (-3%) |
+---+-+-+

4.  bytes.decode('utf8')

D:\dev\cpython\PCbuild\amd64\python.exe -m pyperf timeit -s "b = b'x' * 
100_000_000; f = b.decode;" "f('utf8')"

+---+-+-+
| Benchmark | utf8_a  | utf8_b  |
+===+=+=+
| timeit| 48.3 ms | 47.1 ms: 1.03x faster (-3%) |
+---+-+-+

--

___
Python tracker 

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

[issue38249] Optimize out Py_UNREACHABLE in the release mode

[STINNER Victor]

STINNER Victor  added the comment:

Ah, moreover, it's a public macro, so I would prefer to not change its 
behavior. I consider that modify the macro to call __builtin_unreachable() 
changes the behavior.

--

___
Python tracker 

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

[issue38255] Replace "method" with "attribute" in the description of super()

[Fred L. Drake, Jr.]

Change by Fred L. Drake, Jr. :


--
versions: +Python 3.8

___
Python tracker 

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

[issue38255] Replace "method" with "attribute" in the description of super()

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: docs@python -> rhettinger

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[Steve Dower]

Steve Dower  added the comment:

> _PyPathConfig_Init() initializes _Py_dll_path global variable which is only 
> used by _Py_CheckPython3().

Ah okay, maybe I'll take the time later on (in a separate issue) to get rid of 
it fully. We may as well load python3.dll at startup anyway, it's not expensive.

--

___
Python tracker 

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

[issue38260] asyncio.run documentation does not mention its return value

[Luis E.]

New submission from Luis E. :

The documentation for asyncio.run 
(https://docs.python.org/3/library/asyncio-task.html#asyncio.run) does not 
mention the function's return value or lack of one.

Looking at the source, its clear it returns the passed coroutine's value via 
loop.run_until_complete, but the documentation or the provided example do not 
make it clear.

--
assignee: docs@python
components: Documentation, asyncio
messages: 353033
nosy: asvetlov, docs@python, edd07, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.run documentation does not mention its return value
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

[issue38172] Python 3.8 Segfult with Bandersnatch pytest Suite

[STINNER Victor]

STINNER Victor  added the comment:

The Travis CI job contains the Python traceback where the bug occurs.

It seems like the crash occurs at multidict/__init__.py:23 which imports 
multidict._multidict which is a C extension.

> Full failure on Travis CI: 
> https://travis-ci.org/pypa/bandersnatch/jobs/584973434

$ pip --version

pip 19.2.3 from 
/home/travis/virtualenv/python3.8-dev/lib/python3.8/site-packages/pip (python 
3.8)
install.1

1.02s$ pip install --upgrade pip setuptools
install.2

4.44s$ pip install -r requirements.txt -r requirements_test.txt
install.3

1.48s$ pip install .

12.98s$ python test_runner.py

GLOB sdist-make: /home/travis/build/pypa/bandersnatch/setup.py

py38 create: /home/travis/build/pypa/bandersnatch/.tox/py38

py38 installdeps: -rrequirements_test.txt

py38 inst: 
/home/travis/build/pypa/bandersnatch/.tox/.tmp/package/1/bandersnatch-3.4.1.zip

py38 installed: 
aiohttp==3.6.0,apipkg==1.5,appdirs==1.4.3,async-timeout==3.0.1,atomicwrites==1.3.0,attrs==19.1.0,bandersnatch==3.4.1,black==19.3b0,certifi==2019.9.11,chardet==3.0.4,Click==7.0,codecov==2.0.15,coverage==4.5.4,execnet==1.7.1,filelock==3.0.12,freezegun==0.3.12,idna==2.8,more-itertools==7.2.0,multidict==4.5.2,packaging==19.1,pluggy==0.13.0,py==1.8.0,pyparsing==2.4.2,pytest==5.1.2,pytest-cache==1.0,pytest-timeout==1.3.3,python-dateutil==2.8.0,requests==2.22.0,six==1.12.0,toml==0.10.0,tox==3.14.0,urllib3==1.25.3,virtualenv==16.7.5,wcwidth==0.1.7,xmlrpc2==0.3.1,yarl==1.3.0

py38 run-test-pre: PYTHONHASHSEED='690490585'

py38 run-test: commands[0] | coverage run -m pytest

= test session starts ==

platform linux -- Python 3.8.0b4+, pytest-5.1.2, py-1.8.0, pluggy-0.13.0

cachedir: .tox/py38/.pytest_cache

rootdir: /home/travis/build/pypa/bandersnatch, inifile: pytest.ini

plugins: timeout-1.3.3

Fatal Python error: Segmentation fault

Current thread 0x7fabb284a700 (most recent call first):

  File "", line 219 in _call_with_frames_removed

  File "", line 1109 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/multidict/__init__.py",
 line 23 in 

  File "", line 219 in _call_with_frames_removed

  File "", line 783 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/aiohttp/hdrs.py",
 line 6 in 

  File "", line 219 in _call_with_frames_removed

  File "", line 783 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File "", line 219 in _call_with_frames_removed

  File "", line 1042 in _handle_fromlist

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/aiohttp/__init__.py",
 line 5 in 

  File "", line 219 in _call_with_frames_removed

  File "", line 783 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/bandersnatch/verify.py",
 line 14 in 

  File "", line 219 in _call_with_frames_removed

  File "", line 783 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/bandersnatch/main.py",
 line 17 in 

  File "", line 219 in _call_with_frames_removed

  File "", line 783 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File 
"/home/travis/build/pypa/bandersnatch/src/bandersnatch/tests/test_main.py", 
line 10 in 

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/_pytest/assertion/rewrite.py",
 line 140 in exec_module

  File "", line 671 in _load_unlocked

  File "", line 975 in _find_and_load_unlocked

  File "", line 991 in _find_and_load

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/py/_path/local.py",
 line 701 in pyimport

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/_pytest/python.py",
 line 501 in _importtestmodule

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/_pytest/python.py",
 line 433 in _getobj

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/_pytest/python.py",
 line 256 in obj

  File 
"/home/travis/build/pypa/bandersnatch/.tox/py38/lib/python3.8/site-packages/_pytest/python.py",
 line 449 in _inject_setup_module_fixture

  File 

[issue38172] Python 3.8 Segfult with Bandersnatch pytest Suite

[STINNER Victor]

STINNER Victor  added the comment:

> Victor, am I correct in thinking that this should be closed as either 
> intermittent, lacking in sufficient information for us to do anything, or 
> possibly a 3rd party issue?

It can be a Python 3.8 or a bug in third party code. I suggest to attempt to 
reproduce the bug in gdb to collect more info about this crash.

--

___
Python tracker 

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

[issue38239] test_gdb fails on AMD64 Fedora Stable LTO 3.8 and AMD64 RHEL8 LTO 3.x: Unexpected gdb output

[STINNER Victor]

STINNER Victor  added the comment:

> builtid_id isn't in longobject.c, so this is incorrect debug information. The 
> test expects to find it in bltinmodule.c:

gdb may be confused by LTO. I'm not sure if how LTO works to debug symbols.

> Shouldn't this test be suppressed on LTO builds?

Maybe. I don't know.

--

___
Python tracker 

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

[issue38259] There should be a PriorityQueue in multiprocessing module

[Yair Bonastre]

New submission from Yair Bonastre :

In Python 3.7 queue module has Queue, LifoQueue, PriorityQueue, SimpleQueue 
types and in multiprocessing.queue has Queue, SimpleQueue, JoinableQueue.

Why not adding PriorityQueue to multiprocessing.queue?

Now the only way to do it is by making usage of SyncManager check the solution: 
https://stackoverflow.com/questions/25324560/strange-queue-priorityqueue-behaviour-with-multiprocessing-in-python-2-7-6?answertab=active#tab-top

--
messages: 353022
nosy: Yair Bonastre
priority: normal
severity: normal
status: open
title: There should be a PriorityQueue in multiprocessing module
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

[issue38255] Replace "method" with "attribute" in the description of super()

[Fred L. Drake, Jr.]

Change by Fred L. Drake, Jr. :


--
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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:

> When calling Py_SetPath(), the value that is passed in is ignored.

Hum, in fact the bug was even worse: Py_SetPythonHome() and Py_SetProgramName() 
calls are also ignored. I'm not sure when I introduced these regressions.

PR 16335 fix this bug as well.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15913
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/16336

___
Python tracker 

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

[issue38205] Py_UNREACHABLE() no longer behaves as a function call

[STINNER Victor]

STINNER Victor  added the comment:

Serhiy created bpo-38249: "Optimize out Py_UNREACHABLE in the release mode".

--

___
Python tracker 

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

[issue38147] add Py_ASSUME() macro for __builtin_unreachable()

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-38249.

--

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 9c42f8cda552694f3b47d6388d4ae84d61731872 by Victor Stinner in 
branch 'master':
bpo-38234: Fix _PyConfig_InitPathConfig() (GH-16335)
https://github.com/python/cpython/commit/9c42f8cda552694f3b47d6388d4ae84d61731872


--

___
Python tracker 

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

[issue38256] binascii.crc32 is not 64-bit clean

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +nadeem.vawda

___
Python tracker 

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

[issue36947] Fix 3.3.3.1 Metaclasses Documentation

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
status: pending -> open
title: [Good first issue] Fix 3.3.3.1 Metaclasses Documentation -> Fix 3.3.3.1 
Metaclasses Documentation

___
Python tracker 

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

[issue36947] [Good first issue] Fix 3.3.3.1 Metaclasses Documentation

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It is not good first issue. The referred documentation is complex and needs 
deep knowledge of Python for changing.

The original report was wrong. The original documentation is correct. Josh, do 
you think the documentation needs other changes, and if yes, do you mind to 
create a PR? If no, I am inclined to close this issue.

--
keywords:  -easy, patch
nosy: +serhiy.storchaka
status: open -> pending

___
Python tracker 

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

[issue38241] Pickle with protocol=0 in python 3 does not produce a 'human-readable' format

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Protocol 0 was initially ASCII, but it was changed since adding support for the 
unicode type (and bytearray uses the unicode representation for compatibility 
with Python 3). It is Latin1 now. And still mostly human-readable (except that 
some control characters in Unicode strings can be invisible on your terminal).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue38256] binascii.crc32 is not 64-bit clean

[marko kreen]

New submission from marko kreen :

Following code:

import binascii, zlib
bigdata=memoryview(bytearray((1<<32) + 100))

print(binascii.crc32(bigdata))
crc = binascii.crc32(bigdata[:1000])
crc = binascii.crc32(bigdata[1000:], crc)
print(crc)

print(zlib.crc32(bigdata))
crc = zlib.crc32(bigdata[:1000])
crc = zlib.crc32(bigdata[1000:], crc)
print(crc)
---
Outputs with python3.7

$ python3.7 x.py 
2575877834
2838121701
2838121701
2838121701

--
components: Library (Lib)
messages: 352992
nosy: zmk
priority: normal
severity: normal
status: open
title: binascii.crc32 is not 64-bit clean
type: behavior
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

[issue38232] empty local-part in addr_spec displayed incorrectly

[Andrei Troie]

Andrei Troie  added the comment:

As far as I understand it, this is due to the following code in 
email.headerregistry.Address.addr_spec (in 3.8 and below):

if len(nameset) > len(nameset-parser.DOT_ATOM_ENDS):
lp = parser.quote_string(self.username)

or, in the current version on master:

lp = self.username
if not parser.DOT_ATOM_ENDS.isdisjoint(lp):
lp = parser.quote_string(lp)

Both of these tests will not work with the empty string since the empty string 
is always disjoint from anything, so it will never get quoted.

--

___
Python tracker 

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

[issue38251] urllib.request memory leak / overflow

[Ofer Sadan]

Ofer Sadan  added the comment:

I can confirm that testing with http instead of https this problem doesn't 
exist, on 3.7.4.

Are the issues closed because this problem is fixed in the upcoming 3.7.5, or 
3.8.0?

--

___
Python tracker 

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

[issue38251] urllib.request memory leak / overflow

[Christian Heimes]

Christian Heimes  added the comment:

Yes, the problem will be fixed by 3.7.5.

In the mean time you can work around the issue by creating a single SSLContext 
object with ssl.create_default_context() and reusing it for all requests. It's 
also much more efficient to reuse a single context for all requests.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue38252] micro-optimize ucs1lib_find_max_char in Windows 64-bit build

[Ma Lin]

Ma Lin  added the comment:

Maybe @sir-sigurd can find more optimizations.

FYI, `_Py_bytes_isascii()` function [1] also has similar code.
[1] https://github.com/python/cpython/blob/v3.8.0b4/Objects/bytes_methods.c#L104

--

___
Python tracker 

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

[issue38252] micro-optimize ucs1lib_find_max_char in Windows 64-bit build

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This looks like a good idea. Do you mind to create a PR?

--

___
Python tracker 

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

[issue38256] binascii.crc32 is not 64-bit clean

[marko kreen]

marko kreen  added the comment:

Looking at the code, the bug is dependant on USE_ZLIB_CRC32 define and it's 
unfixed in master.  Cause is zlib crc32 that takes length as integer, 
zlibmodule has workaround, binascii has not.

--

___
Python tracker 

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

[issue38251] urllib.request memory leak / overflow

[hongweipeng]

hongweipeng  added the comment:

My Windows 10 (64bit). There is no such problem in 3.6.1, but 3.7.0 has. And 
when requesting `http://...`, both of them are normal.

By the way, the related issues are all closed, is it supposed to reopen one?

--

___
Python tracker 

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

[issue36587] race in logging code when fork()

[Vinay Sajip]

Vinay Sajip  added the comment:

Is this issue still valid, or should it be closed as out of date?

--

___
Python tracker 

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

[issue38260] asyncio.run documentation does not mention its return value

[Yury Selivanov]

Change by Yury Selivanov :


--
nosy: +aeros167

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 3f5409a3f13c59baa34656bccefdc3728e46c9ef by Victor Stinner in 
branch '3.8':
bpo-38234: Fix _PyConfig_InitPathConfig() (GH-16335) (GH-16336)
https://github.com/python/cpython/commit/3f5409a3f13c59baa34656bccefdc3728e46c9ef


--

___
Python tracker 

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

[issue38254] Pickle not deserializing an aiohttp ClientConnectorError exception as expected

[David Parks]

David Parks  added the comment:

I may be wrong here, but the issue appears to be a problem in pickle, which is 
why I brought it over here. From the looks of the very simple code in the 
Exception I can't see that there's any way that this exception is possible 
unless pickle itself has a bug. Pickle appears to be reconstructing the object 
with a string in a place where an Object was before the serialization process.

The issue is currently reported under aiohttp here: 
https://github.com/aio-libs/aiohttp/issues/4077

It's also posted (originally) on stack overflow here: 
https://stackoverflow.com/questions/58019939/attributeerror-str-object-has-no-attribute-errno

--
resolution: third party -> 
status: closed -> open

___
Python tracker 

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

[issue38249] Optimize out Py_UNREACHABLE in the release mode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> What does __builtin_unreachable()? Does it nothing? Call abort()?

It is more than does nothing. It gives a hint to the compiler, so it can 
optimize out checks that lead to this code. For example, in

switch (k) {
case 0: ...
case 1: ...
case 2: ...
case 3: ...
default: __builtin_unreachable();
}

the compiler can remove the check that k is in the range from 0 to 3 and use 
direct jump table. Or it can keep tests for k == 0, k == 1, k == 2 and remove 
the test for k == 3.

Py_UNREACHABLE() replaces assert(0), but additionally silences compiler warning 
about unreachable code. It was the purpose of introducing Py_UNREACHABLE() (see 
issue14656).

> For me, it's not an issue with the compiler, but more about handling corner 
> cases. Py_UNREACHABLE() is used in cases which "should not occur" but can 
> technically occur if you pass invalid data, or in "very unlikely case".

It is bad if Py_UNREACHABLE() is now used in both cases: for assert(0) and for 
abort(). Using Py_UNREACHABLE() for "very unlikely case" is technically 
incorrect. Raise an exception or call Py_FatalError() in that case.

We need to fix incorrect uses of Py_UNREACHABLE() or add Py_TRUE_UNREACHABLE() 
for true unreachable code.

> Here it's unclear to me if this case can be reached or not.

This is an infinite loop without "break". What can be the doubts?

> _PyLong_Format() calls Py_UNREACHABLE() if base is not in (2, 8, 16).

There is assert(base == 2 || base == 8 || base == 16) above in the code. 
Technically it is a bug. _PyLong_Format() can be used from public 
PyNumber_ToBase(). Either PyNumber_ToBase() or _PyLong_Format() should check 
that the base is 2, 8, 10 or 16, and raise an exception otherwise, but not 
abort the program.

--

___
Python tracker 

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

[issue15902] imp.load_module won't accept None for the file argument for a C extension

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Ned Deily]

Ned Deily  added the comment:

> Will the latter to accept non-ascii values also be merged to security 
> branches too given that it predates the security issue addressed ?

At this point, I'm willing to allow it in 3.6 unless someone identifies a 
compelling reason not to.

--

___
Python tracker 

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

[issue38259] having a PriorityQueue in multiprocessing.queue module like in queue module would be a plus

[Yair Bonastre]

Change by Yair Bonastre :


--
title: There should be a PriorityQueue in multiprocessing module -> having a 
PriorityQueue in multiprocessing.queue module like in queue module would be a 
plus

___
Python tracker 

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

[issue35243] readline timeout too long for async gfx use

[pmp-p]

Change by pmp-p :


--
nosy: +pmpp
type: enhancement -> performance

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[miss-islington]

Change by miss-islington :


--
pull_requests: +15917
pull_request: https://github.com/python/cpython/pull/16340

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 85ce0a7178801b538160cbb5cf9ef50a713c45bf by Victor Stinner in 
branch 'master':
bpo-38234: read_pth_file() now returns PyStatus (GH-16338)
https://github.com/python/cpython/commit/85ce0a7178801b538160cbb5cf9ef50a713c45bf


--

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[miss-islington]

miss-islington  added the comment:


New changeset 7f7cd899e3d773b803b7af5b0c19eeff83dd69fe by Miss Islington (bot) 
in branch '3.8':
bpo-38234: read_pth_file() now returns PyStatus (GH-16338)
https://github.com/python/cpython/commit/7f7cd899e3d773b803b7af5b0c19eeff83dd69fe


--
nosy: +miss-islington

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15916
pull_request: https://github.com/python/cpython/pull/16339

___
Python tracker 

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

[issue38260] asyncio.run documentation does not mention its return value

[Emmanuel Arias]

Emmanuel Arias  added the comment:

So, I think that will return the Future's return, isn't? I will propose a PR 
for this

--
nosy: +eamanu

___
Python tracker 

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

[issue38260] asyncio.run documentation does not mention its return value

[Emmanuel Arias]

Change by Emmanuel Arias :


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

___
Python tracker 

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

[issue38234] The value of Py_SetPath is not used to populate the configuration

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15915
pull_request: https://github.com/python/cpython/pull/16338

___
Python tracker 

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

[issue11410] Use GCC visibility attrs in PyAPI_*

[Vinay Sajip]

Vinay Sajip  added the comment:

Reopening, as a new patch is available.

--
nosy: +vinay.sajip
resolution: out of date -> 
stage: resolved -> patch review
status: closed -> open

___
Python tracker 

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

[issue38261] Tkinter CheckButton default label white in macOS dark mode

[Ryang Sohn]

New submission from Ryang Sohn :

In macOS, when "Dark Mode" is turned on, TKinter's checkbutton's default label 
color is white, not black.

--
components: Tkinter, macOS
files: tkinter_checkbox.py
messages: 353056
nosy: Ryang Sohn, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Tkinter CheckButton default label white in macOS dark mode
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48620/tkinter_checkbox.py

___
Python tracker 

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

[issue11410] Use GCC visibility attrs in PyAPI_*

[Vinay Sajip]

Change by Vinay Sajip :


--
pull_requests: +15924
pull_request: https://github.com/python/cpython/pull/16347

___
Python tracker 

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

[issue11410] Use GCC visibility attrs in PyAPI_*

[Vinay Sajip]

Change by Vinay Sajip :


--
versions: +Python 3.9 -Python 3.3

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:

> So like... both of these approaches are definitely possible, but to me it 
> seems like if you look at it holistically, your approach is actually making 
> the documentation and deprecations *more* complicated, not less.

I think Nathaniel might have a point here.  Andrew, Guido, what do you think?

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +aeros167

___
Python tracker 

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

[issue16637] py-bt, py-locals, etc. GDB commands fail with output-radix 16

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 6f53d34fb0f944a8c0ee530334c353559ac40f72 by Benjamin Peterson 
(Marc Hartmayer) in branch 'master':
closes bpo-16637: libpython: construct integer object directly from gdbvalue 
(GH-15232)
https://github.com/python/cpython/commit/6f53d34fb0f944a8c0ee530334c353559ac40f72


--
nosy: +benjamin.peterson
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

[issue16637] py-bt, py-locals, etc. GDB commands fail with output-radix 16

[miss-islington]

Change by miss-islington :


--
pull_requests: +15922
pull_request: https://github.com/python/cpython/pull/16345

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> I hope that the Trio project can minimize the number of methods they want to 
> add to those ABCs so that we don't need to duplicate a lot of functionality 
> in asyncio.Stream.  E.g. in the new asyncio.Stream there's a Stream.write() 
> coroutine; in Trio it's Stream.send_all().  I'm not entirely convinced that 
> "send_all()" is a good name, for example, even though I now understand the 
> motivation.  We can discuss that later in a relevant issue though.

Yeah, we definitely need to bikeshed the method names but we should do that 
separately. The actual methods are mostly settled though, and designed to be as 
minimal as possible. The complete set is:

- send data
- send EOF
- receive data
- close
- and *maybe* a kind of 'drain' method, which is quasi-optional and I'm hoping 
we can get rid of it; it's related to some latency/flow control/buffering 
issues that are too complex to discuss here

And we'll provide standard implementations for iteration and 
__aenter__/__aexit__.

> Another important point to consider: if the new Trio Stream ABCs are 
> *significantly different* from asyncio.Stream and would require us to alias 
> too many methods or to do heavy refactoring and deprecations, then Trio will 
> have to show some real world usage and traction of its APIs first.

It sounds like the only aliasing will be for the send data method; everything 
else either has different semantics, or has both the same semantics and the 
same name.* And there won't be any refactoring needed; the whole goal of this 
design is to make sure that any reasonable stream implementation can easily 
provide these methods :-).

*I was going to say the "send EOF" method would also be potentially aliased, 
but send EOF should be async, because e.g. on a TLS stream it has to send data, 
and Stream.write_eof is sync. Or maybe we should migrate Stream.write_eof to 
become async too?

> Nathaniel, I think it's important to emphasize that those compromises should 
> be mutual.  I'm willing to support changing "Stream.close()" to 
> "Stream.aclose()" and to perhaps alias some methods.  We can also implement 
> "Stream.chunks()".  But changing the semantics of "__aiter__" is, 
> unfortunately, not on the table, at least for me.

Let's put __aiter__ aside for a moment, and just think about what's best for 
asyncio itself. And if that turns out to include breaking compatibility between 
Stream and StreamReader/StreamWriter, then we can go back to the discussion 
about __aiter__ :-)

> Here's the plan:
>
> 1. We add "aclose()" and "write()" coroutines to the new "asyncio.Stream()".  
> It won't have "wait_closed()" or "drain()" or "close()".
>
> 2. We add a _LegacyStream class derived from the new asyncio.Stream.  We will 
> use it for subprocesses. Its "write()" method will return an 
> "OptionallyAwaitable" wrapper that will nudge users to add an await in front 
> of "stdin.write()".  _LegacyStream will be completely backwards compatible.
>
> This path enables us to add a decent new streaming API while retaining 
> consistency and backwards compatibility.

I don't think this is a terrible plan or anything like that. But I'm still 
confused about why you think it's better than adding new subprocess spawn 
functions. IIUC, your goal is to make the documentation and deprecations as 
simple as possible.

If we add two new subprocess functions, then the documentation/deprecations 
look like this:

- We have to document that there are two different versions of the stream API, 
the new one and the legacy one
- We have to document how Stream works, and how StreamReader/StreamWriter work
- We have to document that 6 functions that return old-style streams are 
deprecated (open_connection, start_server, open_unix_connection, 
start_unix_server, create_subprocess_exec, create_subprocess_shell) and 
replaced by 8 new functions (connect, StreamServer, connect_unix, 
UnixStreamServer, connect_read_pipe, connect_write_pipe, and whatever we called 
the new subprocess functions)

OTOH, with your proposal, we also have a set of deprecations and migrations to 
do:

- We have to document that there are two different versions of the stream API, 
the new one and the legacy one
- We have to document how Stream works, and how StreamReader/StreamWriter work
- We have to document that 4 functions that return old-style streams are 
deprecated (open_connection, start_server, open_unix_connection, 
start_unix_server) and replaced by 6 new functions (connect, StreamServer, 
connect_unix, UnixStreamServer, connect_read_pipe, connect_write_pipe)
- We have to document that Process objects use a third kind of stream object 
that doesn't match either the old or new APIs, and how this one works
- We have to deprecate the no-await write and no-await close (and maybe 
no-await write_eof)

In addition, deprecating a function is straightforward and well understood: you 
just issue a deprecation warning, and tools can automatically 

[issue38136] Remove AsyncMock.assert_awaited_*

[Lisa Roach]

Lisa Roach  added the comment:


New changeset ef048517755db1f0d211fb6dfc655a8b412cc96f by Lisa Roach in branch 
'master':
bpo-38136: Updates await_count and call_count to be different things (GH-16192)
https://github.com/python/cpython/commit/ef048517755db1f0d211fb6dfc655a8b412cc96f


--

___
Python tracker 

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

[issue16637] py-bt, py-locals, etc. GDB commands fail with output-radix 16

[miss-islington]

miss-islington  added the comment:


New changeset 5b94eb8d14f5a5b20dc2a999d6ca6219214b458c by Miss Islington (bot) 
in branch '3.8':
closes bpo-16637: libpython: construct integer object directly from gdbvalue 
(GH-15232)
https://github.com/python/cpython/commit/5b94eb8d14f5a5b20dc2a999d6ca6219214b458c


--
nosy: +miss-islington

___
Python tracker 

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

[issue38174] Security vulnerability in bundled expat CVE-2019-15903 (fix available in expat 2.2.8)

[Benjamin Peterson]

Change by Benjamin Peterson :


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

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Nathaniel Smith]

Nathaniel Smith  added the comment:

I saw Yury on Saturday, and we spent some time working through the implications 
of different options here.

For context: the stream ABCs will be a bit different from most third-party 
code, because their value is proportional to how many projects adopt them. So 
some kind of central standardization is especially valuable. And, they'll have 
lots of implementors + lots of users, so they'll be hard to change regardless 
of whether we standardize them (e.g. even adding new features will be a 
breaking change). Part of the reason we've been aggressively iterating on them 
in Trio is because I know that eventually we need to end up with a minimal core 
that can never change again, so I want to make sure we find the right one :-).

So Yury and I are tentatively thinking we'll make some kind of PEP for the 3.9 
timescale, probably just for the core ABCs, maybe in the stdlib or maybe just 
as an informational PEP that we can use to convince people that this is "the 
python way" (like the WSGI PEP).

Now, the implications for the asyncio.Stream API in 3.8. This is tricky because 
we aren't sure of how everything will shake out, so we considered multiple 
scenarios.

First decision point: will asyncio.Stream implement the ABCs directly, or will 
you need some kind of adapter? If we go with an adapter, then there's no 
conflict between the ABC approach and whatever we do in 3.8, because the 
adapter can always fix things up later. But, it might be nicer to eventually 
have asyncio.Stream implement the ABC directly, so users can use the 
recommended API directly without extra fuss, so let's consider that too.

Next decision point: will the byte stream ABC have an __aiter__ that yields 
chunks? We're pretty sure this is the only place where the ABC *might* conflict 
with the asyncio.Stream interface. And as Josh Oreman pointed out in the Trio 
issue thread, we could even avoid this by making the ABC's chunk-iterator be a 
method like .chunks() instead of naming it __aiter__.

So even with the current asyncio.Stream, there are two potentially workable 
options. But, they do involve *some* compromises, so what would happen if we 
wanted asyncio.Stream to implement the ABC directly without and adapter, *and* 
the ABC uses __aiter__? We can't do that with the current asyncio.Stream. Are 
there any tweaks we'd want to make to 3.8 to keep our options open here?

The obvious change would be to leave out __aiter__ from asyncio.Stream in 3.8. 
That would leave all our options open. For sockets this would be easy, because 
the old functions are still there and still returning StreamReader/StreamWriter 
objects. For 3.8, we're adding a bunch of new Stream-based APIs, and users 
won't encounter a Stream until they switch to those. (The new APIs are: 
connect, connect_read_pipe, connect_write_pipe, connect_unix, StreamServer, 
UnixStreamServer). The problem is the subprocess functions 
(create_subprocess_exec, create_subprocess_shell), since they've been changed 
*in place* to return asyncio.Stream instead of StreamReader/StreamWriter.

We considered the possibility of migrating the existing subprocess functions to 
a different __aiter__ implementation via a deprecation period, but concluded 
that this wasn't really workable. So if we want to go down this branch of the 
decision tree, then 3.8 would have to leave create_subprocess_{exec,shell} as 
using StreamReader/StreamWriter, and in either 3.8 or 3.9 we'd have to add new 
subprocess functions that use Stream, like we did for sockets.

Doing this for subprocesses is a bit more complicated than for sockets, because 
subprocesses have a Process object that holds the stream objects and interacts 
with them. But looking at the code, I don't see any real blockers.

If we completely separated the old StreamReader/StreamWriter functions from the 
new Stream functions, then it would also have another advantage: we could clean 
up several issues with Stream that are only needed for compatibility with the 
old APIs. In particular, we could get rid of the optional-await hacks on 
'write' and 'close', and turn them into regular coroutines.

So I guess this is the real question we have to answer now. Which of these do 
we pick?

Option 1: Keep the Stream code as-is, and accept that using asyncio.Stream with 
future ABC-based code will require some compromises

Option 2: Create new functions for spawning subprocesses; revert 
create_subprocess_{exec,shell} to use StreamReader/StreamWriter; take advantage 
of the break between old and new APIs to clean up Stream in general; take 
advantage of that cleanup to remove __aiter__ so the the future ABC-based code 
won't have to compromise.

I think this is one of those good problems to have, where really we could live 
with either option :-). Still, we should pick one on purpose instead of by 
accident.

Yury's preference was "option 1", because he feels compromises for the ABC 
design aren't that bad, and 

[issue30256] Adding a SyncManager Queue proxy to a SyncManager dict or Namespace proxy raises an exception

[finefoot]

Change by finefoot :


--
pull_requests: +15918
pull_request: https://github.com/python/cpython/pull/16341

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Nathaniel Smith]

Nathaniel Smith  added the comment:

BTW Andrew, while writing that I realized that there's also overlap between 
your new Server classes and Trio's ABC for servers, and I think it'd be 
interesting to chat about how they compare maybe? But it's not relevant to this 
issue, so maybe gitter or another issue or something?

--

___
Python tracker 

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

[issue38242] Revert the new asyncio Streams API

[Yury Selivanov]

Yury Selivanov  added the comment:

Nathaniel, thanks for the summary!


A few comments to address some points:


> So Yury and I are tentatively thinking we'll make some kind of PEP for the 
> 3.9 timescale, probably just for the core ABCs

Yes!  At the very least for things like asynchronous version of "closable", 
e.g. an object with an "aclose()" coroutine method.  I'm sure there are some 
other straightforward design patterns that we can codify.  Maybe we can do that 
for streams too -- see some thoughts below.


> First decision point: will asyncio.Stream implement the ABCs directly, or 
> will you need some kind of adapter?

I'd love asyncio.Stream to implement the ABCs directly.  The only problem is 
that Trio isn't yet settled on the design of those ABCs and we need to make 
some decisions for asyncio *now*.

I hope that the Trio project can minimize the number of methods they want to 
add to those ABCs so that we don't need to duplicate a lot of functionality in 
asyncio.Stream.  E.g. in the new asyncio.Stream there's a Stream.write() 
coroutine; in Trio it's Stream.send_all().  I'm not entirely convinced that 
"send_all()" is a good name, for example, even though I now understand the 
motivation.  We can discuss that later in a relevant issue though.

Another important point to consider: if the new Trio Stream ABCs are 
*significantly different* from asyncio.Stream and would require us to alias too 
many methods or to do heavy refactoring and deprecations, then Trio will have 
to show some real world usage and traction of its APIs first.


> If we completely separated the old StreamReader/StreamWriter functions from 
> the new Stream functions, then it would also have another advantage: we could 
> clean up several issues with Stream that are only needed for compatibility 
> with the old APIs. In particular, we could get rid of the optional-await 
> hacks on 'write' and 'close', and turn them into regular coroutines.

We'd like to avoid that and have one asyncio.Stream class in asyncio.  Using 
legacy StreamReader/StreamWriter functions for subprocesses alone (long term) 
isn't a solution for us, since there're real problems with .write() and 
.close() not being awaitables.  Sticking to having a new asyncio.Stream API and 
old StreamReader/StreamWriter for subprocesses isn't an acceptable solution 
either.  We'd like to minimize the API surface that asyncio users have to deal 
with.


> The obvious change would be to leave out __aiter__ from asyncio.Stream in 3.8.

> Option 1: Keep the Stream code as-is, and accept that using asyncio.Stream 
> with future ABC-based code will require some compromises

Nathaniel, I think it's important to emphasize that those compromises should be 
mutual.  I'm willing to support changing "Stream.close()" to "Stream.aclose()" 
and to perhaps alias some methods.  We can also implement "Stream.chunks()".  
But changing the semantics of "__aiter__" is, unfortunately, not on the table, 
at least for me.

If Trio doesn't want to change the __aiter__ semantics of its Stream ABC (which 
is only a *proposal* right now!), then:

- Fragmenting asyncio APIs by letting subprocesses use old 
StreamReader/StreamWriter while we have new asyncio.Stream isn't an option.

- Asking us to implement new subprocess APIs just for the sake of having 
different Stream implementation for Process.std* channels isn't an option 
either.  

Adding new APIs and deprecating old ones is a huge burden on asyncio 
maintainers and users.  So the "obvious change" for *me* would be using 
"Stream.chunks()" iterator in Trio.  For Trio it's a question of whether the 
new API is pretty; for asyncio it's a question of how many APIs we need to 
deprecate/change.  I hope you understand my position and why I am strong -1 on 
the "Option 2".


> Right now we don't have any path to fixing 'write'/'close' at all;

Andrew and I discussed that this morning.  Here's the plan:

1. We add "aclose()" and "write()" coroutines to the new "asyncio.Stream()".  
It won't have "wait_closed()" or "drain()" or "close()".

2. We add a _LegacyStream class derived from the new asyncio.Stream.  We will 
use it for subprocesses. Its "write()" method will return an 
"OptionallyAwaitable" wrapper that will nudge users to add an await in front of 
"stdin.write()".  _LegacyStream will be completely backwards compatible.

This path enables us to add a decent new streaming API while retaining 
consistency and backwards compatibility.


> BTW Andrew, while writing that I realized that there's also overlap between 
> your new Server classes and Trio's ABC for servers, and I think it'd be 
> interesting to chat about how they compare maybe? But it's not relevant to 
> this issue, so maybe gitter or another issue or something?

If possible please use email/bpo/github.  I don't use gitter and I'd like to be 
part of that discussion (or at least be able to follow it).

--

___
Python tracker 

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[miss-islington]

Change by miss-islington :


--
pull_requests: +15919
pull_request: https://github.com/python/cpython/pull/16342

___
Python tracker 

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

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[miss-islington]

Change by miss-islington :


--
pull_requests: +15921
pull_request: https://github.com/python/cpython/pull/16344

___
Python tracker 

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

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[Benjamin Peterson]

Benjamin Peterson  added the comment:


New changeset 4346bad3321699d49a45e3446270b57726ab5c8f by Benjamin Peterson 
(Hai Shi) in branch 'master':
closes bpo-38253: Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h. (GH-16230)
https://github.com/python/cpython/commit/4346bad3321699d49a45e3446270b57726ab5c8f


--
nosy: +benjamin.peterson
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

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[miss-islington]

Change by miss-islington :


--
pull_requests: +15920
pull_request: https://github.com/python/cpython/pull/16343

___
Python tracker 

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

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[miss-islington]

miss-islington  added the comment:


New changeset 7c65adf688dfadb113eec64374d8d5ccb4fc892b by Miss Islington (bot) 
in branch '2.7':
closes bpo-38253: Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h. (GH-16230)
https://github.com/python/cpython/commit/7c65adf688dfadb113eec64374d8d5ccb4fc892b


--
nosy: +miss-islington

___
Python tracker 

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

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[miss-islington]

miss-islington  added the comment:


New changeset 912b5a986c4fe0f4d758d7536ce818b1ab672437 by Miss Islington (bot) 
in branch '3.7':
closes bpo-38253: Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h. (GH-16230)
https://github.com/python/cpython/commit/912b5a986c4fe0f4d758d7536ce818b1ab672437


--

___
Python tracker 

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

[issue38253] Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h

[miss-islington]

miss-islington  added the comment:


New changeset a7c73a0094c336e5f10d9364f244be70683409ff by Miss Islington (bot) 
in branch '3.8':
closes bpo-38253: Fix typo of Py_SET_ERANGE_IF_OVERFLOW in pyport.h. (GH-16230)
https://github.com/python/cpython/commit/a7c73a0094c336e5f10d9364f244be70683409ff


--

___
Python tracker 

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

[issue38255] Replace "method" with "attribute" in the description of super()

[Géry]

New submission from Géry :

The description of `super()` uses the word "method" instead of the more general 
word "attribute".

> super([type[, object-or-type]])
> Return a proxy object that delegates method calls to a parent or sibling 
> class of *type*.  This is useful for accessing inherited methods that have 
> been overridden in a class.

`super()` is not restricted to method access but can also do data attribute 
access:

```
>>> class A:
... x = True
... 
>>> class B(A):
... x = False
... 
>>> B().x
False
>>> super(B, B()).x
True
```

I have just opened a PR to address this issue.

--
assignee: docs@python
components: Documentation
messages: 352991
nosy: docs@python, maggyero, rhettinger
priority: normal
pull_requests: 15908
severity: normal
status: open
title: Replace "method" with "attribute" in the description of super()
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

[issue38256] binascii.crc32 is not 64-bit clean

[Александр Семенов]

Александр Семенов  added the comment:

I've got 
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit 
(AMD64)]
2838121701
2838121701
2838121701
2838121701

--
nosy: +iamsav

___
Python tracker 

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

[issue38254] Pickle not deserializing an aiohttp ClientConnectorError exception as expected

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

aiohttp is not the part of the standard Python library. Please use an 
appropriate bug tracker for reporting this issue.

--
nosy: +serhiy.storchaka
resolution:  -> third party
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

[issue38216] Fix for issue30458 (HTTP Header Injection) prevents crafting invalid requests

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

If I understand PR 16321 correctly it has a private hook to bypass validating 
invalid bytes in URL added in 3.7.4 and also has the fix to accept non-ascii 
values which is a regression from 2.7 to 3.0 . Will the latter to accept 
non-ascii values also be merged to security branches too given that it predates 
the security issue addressed ?

--

___
Python tracker 

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

[issue38251] urllib.request memory leak / overflow

[Ofer Sadan]

Ofer Sadan  added the comment:

I appreciate the suggestion and the update, thank you!

--

___
Python tracker 

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

[issue38257] __pycache__ directory with World writable permission

[SivaKumar NSK]

New submission from SivaKumar NSK :

Hello All,

I am having some python script, which will be loaded when I run lpinfo -v in 
Manjaro Linux Distro (18.0.4) which has Python 3.7 , it is creating _pycache__ 
directory with full permission, not root user can edit those file.

May i know on what basis the permission of the __pycache__ directory has been 
decided.

Thanks in advance.

--
messages: 353009
nosy: SivaKumar NSK
priority: normal
severity: normal
status: open
title: __pycache__ directory with World writable permission
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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fcdb027234566c4d506d6d753c7d5638490fb088 by Victor Stinner in 
branch 'master':
bpo-38236: Dump path config at first import error (GH-16300)
https://github.com/python/cpython/commit/fcdb027234566c4d506d6d753c7d5638490fb088


--

___
Python tracker 

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

[issue38241] Pickle with protocol=0 in python 3 does not produce a 'human-readable' format

[Nicholas Neumann]

Nicholas Neumann  added the comment:

Apologies as I'm not super-familiar with Latin1 or how Python refers to Latin1, 
but it seems a little odd to even call it Latin1. It can be decoded as Latin1, 
but it can contain every possible byte, including 0x7f through 0x9f, which 
aren't really Latin1. It is human readable when pickling certain data types, 
but when others are involved, it sure seems like binary to me.

I think that is fine, and perhaps all that needs to be done is to update the 
documentation to say something like: "Protocol level 0 is the original pickling 
format. It is the default for Python 2 and is now a binary format; it 
originally was an ASCII format but this ceased to be true as support for new 
datatypes was added to Python."

--

___
Python tracker 

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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

STINNER Victor  added the comment:

I backported my change to Python 3.8.

Example with PYTHONPATH set to Python 2.7 with Python 3.8:

$ PYTHONPATH=/usr/lib64/python2.7/ ./python -c pass
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = '/usr/lib64/python2.7/'
  program name = './python'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = '/home/vstinner/python/3.8/python'
  sys.base_prefix = '/usr/local'
  sys.base_exec_prefix = '/usr/local'
  sys.executable = '/home/vstinner/python/3.8/python'
  sys.prefix = '/usr/local'
  sys.exec_prefix = '/usr/local'
  sys.path = [
'/usr/lib64/python2.7/',
'/usr/local/lib/python38.zip',
'/home/vstinner/python/3.8/Lib',
'/home/vstinner/python/3.8/build/lib.linux-x86_64-3.8-pydebug',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the 
filesystem encoding
Python runtime state: core initialized
  File "/usr/lib64/python2.7/encodings/__init__.py", line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax

Current thread 0x7fe3ade4d740 (most recent call first):


--
versions: +Python 3.8

___
Python tracker 

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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

Change by STINNER Victor :


--
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

[issue38256] binascii.crc32 is not 64-bit clean

[marko kreen]

marko kreen  added the comment:

Found zlibmodule fix: https://bugs.python.org/issue10276

--
versions: +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

[issue38232] empty local-part in addr_spec displayed incorrectly

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +maxking

___
Python tracker 

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

[issue38238] site.py reporting user site info even if ENABLE_USER_SITE=False

[Christian Heimes]

Christian Heimes  added the comment:

getusersitepackages() and getuserbase() don't take ENABLE_USER_SITE into 
account. The function simply return the location of the user site-package 
directory independently of the value of ENABLE_USER_SITE. The check for 
ENABLE_USER_SITE and modification of sys.path occurs later. The design allows 
applications to get the hypothetical path for user site-packages independently 
from the ENABLE_USER_SITE flag.

The API is mature, old, and around since Python 2.6. We can't change it without 
breaking backwards compatibility.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue38239] test_gdb fails on AMD64 Fedora Stable LTO 3.8 and AMD64 RHEL8 LTO 3.x: Unexpected gdb output

[STINNER Victor]

STINNER Victor  added the comment:

AMD64 Fedora Stable LTO + PGO 3.7 is also affected:
https://buildbot.python.org/all/#/builders/252/builds/2

And AMD64 Fedora Stable LTO 3.7:
https://buildbot.python.org/all/#/builders/270/builds/2

--

___
Python tracker 

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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15910
pull_request: https://github.com/python/cpython/pull/16333

___
Python tracker 

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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +15909
pull_request: https://github.com/python/cpython/pull/16332

___
Python tracker 

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

[issue38184] test_site: test_s_option() failed on AMD64 Fedora Rawhide Refleaks 2.7 and AMD64 Fedora Stable Refleaks 3.7

[STINNER Victor]

STINNER Victor  added the comment:

Fail on AMD64 Fedora Stable Refleaks 3.7:
https://buildbot.python.org/all/#/builders/261/builds/2

FAIL: test_s_option (test.test_site.HelperFunctionsTests)
--
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/test_site.py",
 line 204, in test_s_option
self.assertIn(usersite, sys.path)
AssertionError: '/home/buildbot/.local/lib/python3.7/site-packages' not found 
in ['/home/buildbot/buildarea/3.7.cstratak-fedora-stable-x86_64.refleak/build', 
'/home/buildbot/buildarea/3.7.cstratak-fedora-stable-x86_64.refleak/build/target/lib/python37.zip',
 
'/home/buildbot/buildarea/3.7.cstratak-fedora-stable-x86_64.refleak/build/Lib', 
'/home/buildbot/buildarea/3.7.cstratak-fedora-stable-x86_64.refleak/build/build/lib.linux-x86_64-3.7-pydebug']

--
title: [2.7] test_site: test_s_option() failed on AMD64 Fedora Rawhide Refleaks 
2.7 -> test_site: test_s_option() failed on AMD64 Fedora Rawhide Refleaks 2.7 
and AMD64 Fedora Stable Refleaks 3.7
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

[issue38184] [2.7] test_site: test_s_option() failed on AMD64 Fedora Rawhide Refleaks 2.7

[STINNER Victor]

STINNER Victor  added the comment:

Same error on AMD64 Fedora Stable Refleaks 2.7:
https://buildbot.python.org/all/#/builders/291/builds/2

--

___
Python tracker 

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

[issue38252] micro-optimize ucs1lib_find_max_char in Windows 64-bit build

[Ma Lin]

Change by Ma Lin :


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

___
Python tracker 

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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 88e6447451fb5525e83e802c66c3e51b4a45bf86 by Victor Stinner in 
branch 'master':
bpo-38236: Fix init_dump_ascii_wstr() (GH-16333)
https://github.com/python/cpython/commit/88e6447451fb5525e83e802c66c3e51b4a45bf86


--

___
Python tracker 

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

[issue38252] Use 8-byte step to detect ASCII sequence in 64bit Windows builds

[Ma Lin]

Change by Ma Lin :


--
title: micro-optimize ucs1lib_find_max_char in Windows 64-bit build -> Use 
8-byte step to detect ASCII sequence in 64bit Windows builds

___
Python tracker 

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

[issue38236] Dump the Python path configuration at the first import error

[STINNER Victor]

STINNER Victor  added the comment:


New changeset c5c642565e260477ae2fb29d0c86a91e19702ae3 by Victor Stinner in 
branch '3.8':
bpo-38236: Dump path config at first import error (GH-16300) (GH-16332)
https://github.com/python/cpython/commit/c5c642565e260477ae2fb29d0c86a91e19702ae3


--

___
Python tracker 

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