From report at bugs.python.org  Wed Aug  1 00:17:06 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Aug 2018 04:17:06 +0000
Subject: [issue29502] Should PyObject_Call() call the profiler on C functions, 
 use C_TRACE() macro?
In-Reply-To: <1486568378.9.0.904847418882.issue29502@psf.upfronthosting.co.za>
Message-ID: <1533097026.68.0.56676864532.issue29502@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

FYI, _lsprof uses PyObject_Call()
https://github.com/python/cpython/blob/ea68d83933e6de6cabfb115ec1b8888301947369/Modules/_lsprof.c#L120-L123

If PyObject_Call() trigger profiler, lsprof should avoid recursion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29502>
_______________________________________

From report at bugs.python.org  Wed Aug  1 00:32:15 2018
From: report at bugs.python.org (Martin Panter)
Date: Wed, 01 Aug 2018 04:32:15 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1533097935.12.0.56676864532.issue25095@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I reproduced the problem on a Windows computer, and now understand why my "Content-Length: 0" suggestion isn't good enough on its own. It does solve the initial deadlock, but there is a further deadlock. The main thread is waiting for the server to shut down while it is holding the HTTP connection open, and the server is still trying to read a second request on that connection.

Setting "self.close_connection = True" in the server (or using "Connection: close") solves both deadlocks. But it seems cleaner for the client to close the connection and response objects anyway, before shutting down the server. I would modify the "test_get" method:

with support.captured_stderr() as err:
    self.con.request('GET', '/')
    res = self.con.getresponse()
    res.close()  # Not needed but cleans up socket if no Content-Length
self.con.close()  # Needed to shut down connection with Content-Length

I think my Windows computer has a firewall that holds TCP data if it looks like an unfinished HTTP request or response. I suspect Terry and William had a similar firewall. Here is a demonstration of the socket behaviour it causes:

>>> from socket import *
>>> listener = socket()
>>> listener.bind(("127.1", 0))
>>> listener.listen()
>>> outgoing = create_connection(listener.getsockname())
>>> [incoming, address] = listener.accept()
>>> outgoing.sendall(b"GET / HTTP/1.1\r\n")  # Unfinished HTTP request
>>> incoming.settimeout(3)
>>> incoming.recv(300)  # Partial request should normally be received
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.timeout: timed out
>>> outgoing.sendall(b"\r\n")  # Complete the request
>>> incoming.recv(300)  # Only now is the request received
b'GET / HTTP/1.1\r\n\r\n'
>>> incoming.sendall(b"HTTP/1.1 200 OK\r\n")  # Unfinished response
>>> outgoing.settimeout(3)
>>> outgoing.recv(300)  # Should normally be received
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.timeout: timed out
>>> incoming.sendall(b"Content-Length: 0\r\n\r\n")  # Complete the response
>>> outgoing.recv(300)  # Only now received
b'HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:01:55 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Aug 2018 05:01:55 +0000
Subject: [issue34269] logging in 3.7 behaves different due to caching
In-Reply-To: <1532855036.26.0.56676864532.issue34269@psf.upfronthosting.co.za>
Message-ID: <1533099715.04.0.56676864532.issue34269@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> But, seems like one has no public api to reinitialize logging to a like-fresh state

For the use case of testing, you could use a context manager approach as described here in the logging cookbook:

https://docs.python.org/3/howto/logging-cookbook.html#using-a-context-manager-for-selective-logging

The approach outlined can be built on to add more convenience according to the specifics of your use case.

In this way, you can restore logging to "the state in which you found it" which is a potentially more useful thing than just clearing out everything.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34269>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:09:03 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Wed, 01 Aug 2018 05:09:03 +0000
Subject: [issue34303] micro-optimizations in functools.reduce()
Message-ID: <1533100143.91.0.56676864532.issue34303@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

`PyTuple_SetItem()` can be replaced with macro version and `PyObject_Call()` can be used instead of `PyEval_CallObject()`.

Here's benchmark results:

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from functools import reduce; from operator import is_; r = range(50000)" "reduce(is_, r)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 1.64 ms +- 0.01 ms
/home/sergey/tmp/cpython-venv/bin/python: ..................... 1.40 ms +- 0.00 ms

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 1.64 ms +- 0.01 ms -> [/home/sergey/tmp/cpython-venv/bin/python] 1.40 ms +- 0.00 ms: 1.17x faster (-15%)

----------
components: Extension Modules
messages: 322841
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: micro-optimizations in functools.reduce()
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34303>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:10:27 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Wed, 01 Aug 2018 05:10:27 +0000
Subject: [issue34303] micro-optimizations in functools.reduce()
In-Reply-To: <1533100143.91.0.56676864532.issue34303@psf.upfronthosting.co.za>
Message-ID: <1533100227.04.0.56676864532.issue34303@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +8107
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34303>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:13:39 2018
From: report at bugs.python.org (Saba Kauser)
Date: Wed, 01 Aug 2018 05:13:39 +0000
Subject: [issue34304] clarification on escaping \d in regular expressions
Message-ID: <1533100419.92.0.56676864532.issue34304@psf.upfronthosting.co.za>


New submission from Saba Kauser <skauseribmdb at gmail.com>:

Hello,

I have a program that works well upto python 3.6 but fails with python 3.7.

import re

pattern="DBMS_NAME: string(%d) %s"
sym = ['\[','\]','\(','\)']
for chr in sym:
  pattern = re.sub(chr, '\\' + chr, pattern)
  print(pattern)
  
pattern=re.sub('%s','.*?',pattern)
print(pattern)
pattern = re.sub('%d', '\\d+', pattern) 
print(pattern)
result=re.match(pattern, "DBMS_NAME: string(8) \"DB2/NT64\" ")
print(result)
result=re.match("DBMS_NAME python4: string\(\d+\) .*?", "DBMS_NAME python4: string(8) \"DB2/NT64\" ")
print(result)

expected output:
DBMS_NAME: string(%d) %s
DBMS_NAME: string(%d) %s
DBMS_NAME: string\(%d) %s
DBMS_NAME: string\(%d\) %s
DBMS_NAME: string\(%d\) .*?
DBMS_NAME: string\(\d+\) .*?
<re.Match object; span=(0, 21), match='DBMS_NAME: string(8) '>
<re.Match object; span=(0, 29), match='DBMS_NAME python4: string(8) '>

However, the below statement execution fails with python 3.7:
pattern = re.sub('%d', '\\d+', pattern) 

DBMS_NAME: string(%d) %s
DBMS_NAME: string(%d) %s
DBMS_NAME: string\(%d) %s
DBMS_NAME: string\(%d\) %s
DBMS_NAME: string\(%d\) .*?
Traceback (most recent call last):
  File "c:\users\skauser\appdata\local\programs\python\python37\lib\sre_parse.py", line 1021, in parse_template
    this = chr(ESCAPES[this][1])
KeyError: '\\d'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pattern.txt", line 11, in <module>
    pattern = re.sub('%d', '\\d+', pattern)
  File "c:\users\skauser\appdata\local\programs\python\python37\lib\re.py", line 192, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "c:\users\skauser\appdata\local\programs\python\python37\lib\re.py", line 309, in _subx
    template = _compile_repl(template, pattern)
  File "c:\users\skauser\appdata\local\programs\python\python37\lib\re.py", line 300, in _compile_repl
    return sre_parse.parse_template(repl, pattern)
  File "c:\users\skauser\appdata\local\programs\python\python37\lib\sre_parse.py", line 1024, in parse_template
    raise s.error('bad escape %s' % this, len(this))
re.error: bad escape \d at position 0

if I change the statement to have 3 backslash like 
pattern = re.sub('%d', '\\\d+', pattern) 

I can correctly generate correct regular expression.

Can you please comment if this has changed in python 3.7 and we need to escape 'd' in '\d' as well ?

Thank you!

----------
components: Regular Expressions
messages: 322842
nosy: ezio.melotti, mrabarnett, sabakauser
priority: normal
severity: normal
status: open
title: clarification on escaping \d in regular expressions
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34304>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:39:14 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Aug 2018 05:39:14 +0000
Subject: [issue34275] Problems with tkinter and tk8.6 on MacOS
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533101953.99.0.56676864532.issue34275@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you! Adding update worked for calltip_w.  Adding update to tooltip and copying
   tw.lift()  # work around bug in Tk 8.5.18+ (issue #24570)
from calltip worked for tooltip.  (It seems the bug is still present. ;-)  I will either patch these files directly or modify the patch for #33839 tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:43:45 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Aug 2018 05:43:45 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533102225.81.0.56676864532.issue34047@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Moving the scrollwheel in either direction scrolls down, so I have to use the scrollbar once stuck on the bottom of the file.  (The Macbook has no PageUp key.)  For me, this is the most obnoxious bug.  Tomorrow, I will add prints to the scroll event handling code to see what is being generated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Wed Aug  1 01:44:19 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Aug 2018 05:44:19 +0000
Subject: [issue34086] logging.Handler.handleError regressed in python3
In-Reply-To: <1531245533.0.0.56676864532.issue34086@psf.upfronthosting.co.za>
Message-ID: <1533102259.66.0.56676864532.issue34086@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34086>
_______________________________________

From report at bugs.python.org  Wed Aug  1 02:04:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Aug 2018 06:04:17 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533103457.88.0.56676864532.issue34120@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The tkinter doc could use a section on 'OS-tk peculiarities and interactions' ;-).  Anyway, thanks again.  Some of the 'Windows peculiarities' I noted above, where the test behaved better on Mac, may be due to the absence of calls that should be avoided on Mac.  Perhaps I can factor out some of the dialog setup and shutdown code, get it right for each platform, and then use it for all or at least multiple dialogs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 02:44:15 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 06:44:15 +0000
Subject: [issue34275] Problems with tkinter and tk8.6 on MacOS
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533105855.95.0.56676864532.issue34275@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Perhaps we can use .update_idletasks() rather than .update()? That tends to have less of a performance hit. My macOS setup is currently not working so I can't test this myself.

Regarding the "MacWindowStyle" call, IDLE is backported to older versions of Python and generally strives to support older systems. Can you tell which versions of macOS/OSX this is needed in? If so, I suggest surrounding that call with an OS version check, which could be removed at a later time when the relevant OS versions are truly irrelevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Wed Aug  1 03:20:53 2018
From: report at bugs.python.org (Eric Wieser)
Date: Wed, 01 Aug 2018 07:20:53 +0000
Subject: [issue34305] inspect.getsourcefile and inspect.getcomments do not
 work with decorated functions
Message-ID: <1533108053.89.0.56676864532.issue34305@psf.upfronthosting.co.za>


New submission from Eric Wieser <wieser.eric+pybug at gmail.com>:

Following on from https://bugs.python.org/issue1764286 - inspect.getsourcefile and inspect.getcomments fall afoul of the same problem.

----------
components: Library (Lib)
messages: 322847
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: inspect.getsourcefile and inspect.getcomments do not work with decorated functions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34305>
_______________________________________

From report at bugs.python.org  Wed Aug  1 03:21:09 2018
From: report at bugs.python.org (Eric Wieser)
Date: Wed, 01 Aug 2018 07:21:09 +0000
Subject: [issue34305] inspect.getsourcefile and inspect.getcomments do not
 work with decorated functions
In-Reply-To: <1533108053.89.0.56676864532.issue34305@psf.upfronthosting.co.za>
Message-ID: <1533108069.58.0.56676864532.issue34305@psf.upfronthosting.co.za>


Change by Eric Wieser <wieser.eric+pybug at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34305>
_______________________________________

From report at bugs.python.org  Wed Aug  1 03:24:40 2018
From: report at bugs.python.org (Eric Wieser)
Date: Wed, 01 Aug 2018 07:24:40 +0000
Subject: [issue34305] inspect.getsourcefile and inspect.getcomments do not
 work with decorated functions
In-Reply-To: <1533108053.89.0.56676864532.issue34305@psf.upfronthosting.co.za>
Message-ID: <1533108280.11.0.56676864532.issue34305@psf.upfronthosting.co.za>


Change by Eric Wieser <wieser.eric+pybug at gmail.com>:


----------
keywords: +patch
pull_requests: +8108
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34305>
_______________________________________

From report at bugs.python.org  Wed Aug  1 03:43:12 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 01 Aug 2018 07:43:12 +0000
Subject: [issue24564] shutil.copytree fails when copying NFS to NFS
In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za>
Message-ID: <1533109392.78.0.56676864532.issue24564@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

[ https://bugs.python.org/issue24564#msg246278 ]

> Adding `EINVAL` to the ignored errnos would fix the problem, but might hide real failures (I'm not sure about the real failures, but it seems logical).

I think this is an acceptable compromise considering that:

1) because of this the copy operation will ultimately fail (despite file will be copied)
2) there is nothing we can do except emit a warning somehow 
3) EPERM and ENODATA are already silently ignored (also ENOTSUP but that is more legit)

For completeness, other than copytree() also copy2() and move() are affected. 
I submitted a PR: https://github.com/python/cpython/pull/8601.

----------
nosy: +giampaolo.rodola
pull_requests: +8109
stage:  -> patch review
versions: +Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24564>
_______________________________________

From report at bugs.python.org  Wed Aug  1 04:09:51 2018
From: report at bugs.python.org (=?utf-8?q?Kamil_Ga=C5=82uszka?=)
Date: Wed, 01 Aug 2018 08:09:51 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1533110991.65.0.56676864532.issue23078@psf.upfronthosting.co.za>


Kamil Ga?uszka <galuszkak at gmail.com> added the comment:

This affects all versions from 3.4 up to 3.8-dev. Would be nice if someone could do the review of the supplied patch. 

Thanks for awesome work on Python!

I'm here because it just hit me also and I was for 1 h thinking that I don't know how to use patch/mock. ;)

----------
nosy: +galuszkak
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Wed Aug  1 04:27:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Aug 2018 08:27:28 +0000
Subject: [issue34303] micro-optimizations in functools.reduce()
In-Reply-To: <1533100143.91.0.56676864532.issue34303@psf.upfronthosting.co.za>
Message-ID: <1533112048.08.0.56676864532.issue34303@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34303>
_______________________________________

From report at bugs.python.org  Wed Aug  1 04:31:48 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 08:31:48 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533112308.79.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +8110
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 04:32:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Aug 2018 08:32:09 +0000
Subject: [issue34304] clarification on escaping \d in regular expressions
In-Reply-To: <1533100419.92.0.56676864532.issue34304@psf.upfronthosting.co.za>
Message-ID: <1533112329.47.0.56676864532.issue34304@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34304>
_______________________________________

From report at bugs.python.org  Wed Aug  1 04:35:41 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 08:35:41 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533112541.82.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I can confirm that removing .grab_set() calls fixes this issue on macOS 10.13.5 with Python 3.7.0 from python.org.

Searching for those calls in all of IDLE's code lead me to discover additional similar issues, e.g. with the search dialog and the text viewer.  Removing the .grab_set() and .grab_release() calls fixes those issues as well.

I tried IDLE with these changes on Windows 10 with python build from the latest master branch.  Things appear to be working well without these calls.

Is it reasonable to simply remove the grab calls entirely?  I've created a PR with such a change to facilitate evaluating this approach.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 04:49:44 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 08:49:44 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533113384.39.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Confirmed on macOS 10.13.5 with the new Python 2.7.15 64-bit from python.org which bundles Tcl/Tk 8.6.8.

The same fix works: Removing the grab_set() calls fixes the freezing after closing the about and config dialogs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 05:12:25 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 01 Aug 2018 09:12:25 +0000
Subject: [issue34303] micro-optimizations in functools.reduce()
In-Reply-To: <1533100143.91.0.56676864532.issue34303@psf.upfronthosting.co.za>
Message-ID: <1533114745.95.0.56676864532.issue34303@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
type: enhancement -> performance
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34303>
_______________________________________

From report at bugs.python.org  Wed Aug  1 05:15:56 2018
From: report at bugs.python.org (Michael Fischer)
Date: Wed, 01 Aug 2018 09:15:56 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533114956.03.0.56676864532.issue34273@psf.upfronthosting.co.za>


Michael Fischer <michael-fischer89 at web.de> added the comment:

Thank you for your quick reply. I understand why you chose this description better now. However in C %f behaves exactly the same as in Python (for floating-point numbers) and you will mostly find the description for it along the lines of:

'%f' Print a floating-point number in normal (fixed-point) notation. [The GNU C Library Reference Manual - https://www.gnu.org/software/libc/manual/pdf/libc.pdf]

For the sake of simplicity I suggest the following wording:

Fixed point notation. Displays the (floating-point) number as a fixed-point number. The default precision is 6.

In my opinion this emphasizes the intent (fixed precision representation) and hints at the independence of input type, by putting the floating-point in brackets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Wed Aug  1 06:16:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Aug 2018 10:16:15 +0000
Subject: [issue34304] clarification on escaping \d in regular expressions
In-Reply-To: <1533100419.92.0.56676864532.issue34304@psf.upfronthosting.co.za>
Message-ID: <1533118575.8.0.56676864532.issue34304@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The reported behavior is reproducible in master as well as of ea68d83933 but not on 3.6.0. I couldn't bisect to the exact commit between 3.7.0 and 3.6.0 where this change was introduced though. I can also see some deprecation warnings as below while running the script : 

?  cpython git:(master) ./python.exe ../backups/bpo34034.py
../backups/bpo34034.py:4: DeprecationWarning: invalid escape sequence \[
  sym = ['\[','\]','\(','\)']
../backups/bpo34034.py:4: DeprecationWarning: invalid escape sequence \]
  sym = ['\[','\]','\(','\)']
../backups/bpo34034.py:4: DeprecationWarning: invalid escape sequence \(
  sym = ['\[','\]','\(','\)']
../backups/bpo34034.py:4: DeprecationWarning: invalid escape sequence \)
  sym = ['\[','\]','\(','\)']
../backups/bpo34034.py:15: DeprecationWarning: invalid escape sequence \(
  result=re.match("DBMS_NAME python4: string\(\d+\) .*?", "DBMS_NAME python4: string(8) \"DB2/NT64\" ")
DBMS_NAME: string(%d) %s
DBMS_NAME: string(%d) %s
DBMS_NAME: string\(%d) %s
DBMS_NAME: string\(%d\) %s
DBMS_NAME: string\(%d\) .*?
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/sre_parse.py", line 1045, in parse_template
    this = chr(ESCAPES[this][1])
KeyError: '\\d'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "../backups/bpo34034.py", line 11, in <module>
    pattern = re.sub('%d', '\\d+', pattern)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/re.py", line 192, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/re.py", line 309, in _subx
    template = _compile_repl(template, pattern)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/re.py", line 300, in _compile_repl
    return sre_parse.parse_template(repl, pattern)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/sre_parse.py", line 1048, in parse_template
    raise s.error('bad escape %s' % this, len(this))
re.error: bad escape \d at position 0


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34304>
_______________________________________

From report at bugs.python.org  Wed Aug  1 06:19:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Aug 2018 10:19:42 +0000
Subject: [issue34304] clarification on escaping \d in regular expressions
In-Reply-To: <1533100419.92.0.56676864532.issue34304@psf.upfronthosting.co.za>
Message-ID: <1533118782.74.0.56676864532.issue34304@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If you want to replace %d with literal \d, you need to repeat the backslash 4 times:

    pattern = re.sub('%d', '\\\\d+', pattern)

or use a raw string literal and repeat the backslash 2 times:

    pattern = re.sub('%d', r'\\d+', pattern)

Since the backslash has a special meaning in the replacement pattern, it needs to be escaped with a backslash, i.e. duplicated. But since it has a special meaning in Python string literals, every of these backslashes needs to be escaped with a backslash in a non-raw string literal, i.e. repeated 4 times.

Python 3.6 is more lenient. It keeps a backslash if it is followed by a character which doesn't compound a known escape sequences in a replacement string. But it emits a deprecation warning, which you can see when run Python with corresponding -W option.

$ python3.6 -Wa -c 'import re; print(re.sub("%d", "\d+", "DBMS_NAME: string(%d) %s"))'
<string>:1: DeprecationWarning: invalid escape sequence \d
/usr/lib/python3.6/re.py:191: DeprecationWarning: bad escape \d
  return _compile(pattern, flags).sub(repl, string, count)
DBMS_NAME: string(\d+) %s

$ python3.6 -Wa -c 'import re; print(re.sub("%d", "\\d+", "DBMS_NAME: string(%d) %s"))'
/usr/lib/python3.6/re.py:191: DeprecationWarning: bad escape \d
  return _compile(pattern, flags).sub(repl, string, count)
DBMS_NAME: string(\d+) %s

$ python3.6 -Wa -c 'import re; print(re.sub("%d", "\\\d+", "DBMS_NAME: string(%d) %s"))'
<string>:1: DeprecationWarning: invalid escape sequence \d
DBMS_NAME: string(\d+) %s

$ python3.6 -Wa -c 'import re; print(re.sub("%d", "\\\\d+", "DBMS_NAME: string(%d) %s"))'
DBMS_NAME: string(\d+) %s

Here "invalid escape sequence \d" is generated by the Python parser, "bad escape \d" is generated by the RE engine.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34304>
_______________________________________

From report at bugs.python.org  Wed Aug  1 06:54:55 2018
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 01 Aug 2018 10:54:55 +0000
Subject: [issue34275] Problems with tkinter and tk8.6 on MacOS
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533120895.47.0.56676864532.issue34275@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Tal, your proposed revisions to the patch work fine. It's harmless to leave the older calls to MacWindowStyle there. New patch attached.

----------
Added file: https://bugs.python.org/file47726/calltips_w-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Wed Aug  1 07:40:54 2018
From: report at bugs.python.org (William Pickard)
Date: Wed, 01 Aug 2018 11:40:54 +0000
Subject: [issue25095] test_httpservers hangs since Python 3.5
In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za>
Message-ID: <1533123654.47.0.56676864532.issue25095@psf.upfronthosting.co.za>


William Pickard <lollol222gg at gmail.com> added the comment:

My computer was running BitDefender Total Security 2018 (At the time, currently running the 2019 edition) and MalwareBytes 3 Premium.

BitDefender has both a built-in firewall and a web protection module while MalwareBytes has a web protection module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25095>
_______________________________________

From report at bugs.python.org  Wed Aug  1 08:05:23 2018
From: report at bugs.python.org (Erik Bray)
Date: Wed, 01 Aug 2018 12:05:23 +0000
Subject: [issue34211] Cygwin build broken due to use of &PyType_Type in static
 declaration in _abc module
In-Reply-To: <1532451616.3.0.56676864532.issue34211@psf.upfronthosting.co.za>
Message-ID: <1533125123.75.0.56676864532.issue34211@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

> For those who are not very aware of Cygwin issues: what is wrong with
>
> PyVarObject_HEAD_INIT(&PyType_Type, 0);

I'm glad you asked, because it actually got me thinking, and since I added a fix (albeit an unsatisfying one) for issue34212, this fix is no longer strictly necessary *so long as* the _abc module is always built as a core built-in (that is, linked into libpython).

IIUC that is the case since _abc is required for the core, but I'm not sure.

The problem is explained somewhat in issue21124, but what it comes down to is that if the linker can't resolve PyType_Type at link time it will make a complaint like "can't initialize global with a non-constant".

Because of issue34212, when compiling _abc.c it was using the wrong external linkage for PyType_Type (treating it as some data that needs to be imported from an other DLL, rather than data in the same DLL).  But with a fix for issue34212 this is not a problem (again, so long as the _abc module is included in libpython).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34211>
_______________________________________

From report at bugs.python.org  Wed Aug  1 08:26:57 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 01 Aug 2018 12:26:57 +0000
Subject: [issue34211] Cygwin build broken due to use of &PyType_Type in static
 declaration in _abc module
In-Reply-To: <1532451616.3.0.56676864532.issue34211@psf.upfronthosting.co.za>
Message-ID: <1533126417.34.0.56676864532.issue34211@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Linker issues are always tricky...

I understand that there is no problem within libpython, so the questions below refer to extension modules. I am asking them from the point of view of somebody writing Python extension modules who is clueless about Cygwin.

So you're saying that it's not allowed to refer to &PyType_Type in a static struct? But it is OK to refer to &PyType_Type in code?

I assume that there is nothing special about PyType_Type and that this apply for all variables. Are functions OK? For example, in functools.c I see

static PyGetSetDef partial_getsetlist[] = {
    {"__dict__", PyObject_GenericGetDict, PyObject_GenericSetDict},
    {NULL} /* Sentinel */
};

What makes functions different from variables? Aren't they essentially just pointers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34211>
_______________________________________

From report at bugs.python.org  Wed Aug  1 08:37:41 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 01 Aug 2018 12:37:41 +0000
Subject: [issue34302] Avoid inefficient way to find start point in deque.index
In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za>
Message-ID: <1533127061.19.0.56676864532.issue34302@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm not sure what your proposal is. Do you have a patch that increases the performance of collections.deque in some cases?  If so please share that patch, preferably as a pull request on GitHub (see <https://devguide.python.org/pullrequest/> for an explanation).

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34302>
_______________________________________

From report at bugs.python.org  Wed Aug  1 09:32:29 2018
From: report at bugs.python.org (Victor Porton)
Date: Wed, 01 Aug 2018 13:32:29 +0000
Subject: [issue34306] minidom: wrong processing of xmlns attributes
Message-ID: <1533130349.62.0.56676864532.issue34306@psf.upfronthosting.co.za>


New submission from Victor Porton <porton at narod.ru>:

The below script prints

http://www.w3.org/2000/xmlns/
aa:aa

It should print

None
aa:aa

because xmlns:z is NOT an attribute of xmlns namespace.

~~~
import xml.dom.minidom

x = xml.dom.minidom.parseString("<x xmlns:z='aa:aa' z:q='1'/>")

for i in x.documentElement.attributes.values():
    print(i.namespaceURI)
~~~

----------
components: XML
messages: 322860
nosy: porton
priority: normal
severity: normal
status: open
title: minidom: wrong processing of xmlns attributes
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34306>
_______________________________________

From report at bugs.python.org  Wed Aug  1 09:34:16 2018
From: report at bugs.python.org (Romuald Brunet)
Date: Wed, 01 Aug 2018 13:34:16 +0000
Subject: [issue34307] NullHandler init refusing arguments
Message-ID: <1533130455.97.0.56676864532.issue34307@psf.upfronthosting.co.za>


New submission from Romuald Brunet <romuald.brunet at gmail.com>:

Context:

I'm using a custom Handler that relies on a third-party library that may not be present

try:
  from acme.logging import CustomHandler as BaseHandler
except ImportError:
  import logging.NullHandler as BaseHandler

class MoreCustomHandler(BaseHandler):
  def handle(self):
    self.stuff()

The logging configuration has some arguments for the CustomHandler. The problem is that the NullHandler does not accept them.

I expected it to be a "dummy" handler that might accept any argument

----------
components: Library (Lib)
messages: 322861
nosy: Romuald
priority: normal
severity: normal
status: open
title: NullHandler init refusing arguments
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34307>
_______________________________________

From report at bugs.python.org  Wed Aug  1 09:45:22 2018
From: report at bugs.python.org (Romuald Brunet)
Date: Wed, 01 Aug 2018 13:45:22 +0000
Subject: [issue34307] NullHandler init refusing arguments
In-Reply-To: <1533130455.97.0.56676864532.issue34307@psf.upfronthosting.co.za>
Message-ID: <1533131122.96.0.56676864532.issue34307@psf.upfronthosting.co.za>


Change by Romuald Brunet <romuald.brunet at gmail.com>:


----------
keywords: +patch
pull_requests: +8111
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34307>
_______________________________________

From report at bugs.python.org  Wed Aug  1 09:53:14 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Aug 2018 13:53:14 +0000
Subject: [issue34307] NullHandler init refusing arguments
In-Reply-To: <1533130455.97.0.56676864532.issue34307@psf.upfronthosting.co.za>
Message-ID: <1533131594.47.0.56676864532.issue34307@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34307>
_______________________________________

From report at bugs.python.org  Wed Aug  1 10:12:44 2018
From: report at bugs.python.org (Seonggi Kim)
Date: Wed, 01 Aug 2018 14:12:44 +0000
Subject: [issue34302] Avoid inefficient way to find start point in deque.index
In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za>
Message-ID: <1533132764.32.0.56676864532.issue34302@psf.upfronthosting.co.za>


Seonggi Kim <ksg97031 at gmail.com> added the comment:

Sorry, I'm waiting for permit CLA signing.
I will request PR after CLA was signed.

----------
nosy: +hacksg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34302>
_______________________________________

From report at bugs.python.org  Wed Aug  1 10:15:24 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 01 Aug 2018 14:15:24 +0000
Subject: [issue34302] Avoid inefficient way to find start point in deque.index
In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za>
Message-ID: <1533132924.62.0.56676864532.issue34302@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That's ok, I hadn't expected that you'd sign the CLA before being asked to do so :-)

Good luck.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34302>
_______________________________________

From report at bugs.python.org  Wed Aug  1 10:16:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 14:16:51 +0000
Subject: [issue33499] Environment variable to set alternate location for
 pycache tree
In-Reply-To: <1526310769.71.0.682650639539.issue33499@psf.upfronthosting.co.za>
Message-ID: <1533133011.27.0.56676864532.issue33499@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fc96437db4fa95dff99d43d4500beaf12bad5bff by Victor Stinner in branch 'master':
bpo-33499: Fix pymain_init_pycache_prefix() (GH-8596)
https://github.com/python/cpython/commit/fc96437db4fa95dff99d43d4500beaf12bad5bff


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33499>
_______________________________________

From report at bugs.python.org  Wed Aug  1 10:18:09 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 01 Aug 2018 14:18:09 +0000
Subject: [issue32752] no information about accessing typing.Generic type
 arguments
In-Reply-To: <1517612346.62.0.467229070634.issue32752@psf.upfronthosting.co.za>
Message-ID: <1533133089.87.0.56676864532.issue32752@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> 3.7 is less convenient and less consistent

Taking into account that internal API is something one should never use, I don't think these terms apply here. Anyway, we will provide some helpers for external use in one of the next releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32752>
_______________________________________

From report at bugs.python.org  Wed Aug  1 10:51:51 2018
From: report at bugs.python.org (Chantal Ackermann)
Date: Wed, 01 Aug 2018 14:51:51 +0000
Subject: [issue34308] shutil.copystat fails in dockered Linux (Debian) on
 Azure (Windows)
Message-ID: <1533135111.37.0.56676864532.issue34308@psf.upfronthosting.co.za>


New submission from Chantal Ackermann <chantal.ackermann at web.de>:

root:/media/documents# df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                  29.0G     24.0G      5.0G  83% /
tmpfs                     1.7G         0      1.7G   0% /dev
tmpfs                     1.7G         0      1.7G   0% /sys/fs/cgroup
//storage01.file.core.windows.net/kubernetes-dynamic-pvc-526aa3da-6993-11e8-8c6f-0a58ac1f00ad
                          1.0G    384.0K   1023.6M   0% /media
root:/media/documents# ls -al
insgesamt 267
drwxrwxrwx 2 1000 1000      0 Jul 31 15:29 .
drwxrwxrwx 2 1000 1000      0 Jul 31 15:29 ..
-rwxrwxrwx 1 1000 1000 136479 Jul 31 16:48 orig.pdf
-rwxrwxrwx 1 1000 1000 136479 Jul 31 15:29 testfile
root:/media/documents# lsattr 
--S-----c-jI------- ./orig.pdf
--S-----c-jI------- ./testfile
root:/media/documents# python
Python 3.6.6 (default, Jul 17 2018, 11:12:33) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.copystat('orig.pdf', 'testfile')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/shutil.py", line 225, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/local/lib/python3.6/shutil.py", line 157, in _copyxattr
    names = os.listxattr(src, follow_symlinks=follow_symlinks)
OSError: [Errno 38] Function not implemented: 'orig.pdf'
>>> shutil.copystat('orig.pdf', 'testfile', follow_symlinks=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/shutil.py", line 225, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/local/lib/python3.6/shutil.py", line 157, in _copyxattr
    names = os.listxattr(src, follow_symlinks=follow_symlinks)
OSError: [Errno 38] Function not implemented: 'orig.pdf'
>>> 

shutil.py#164ff:

if hasattr(os, 'listxattr'):
    def _copyxattr(src, dst, *, follow_symlinks=True):
        try:
            names = os.listxattr(src, follow_symlinks=follow_symlinks)
        except OSError as e:
            if e.errno not in (errno.ENOTSUP, errno.ENODATA):
                raise
            return

=> This is true inside the docker container. However, calling os.listxattr fails with errno.ENOSYS (Error 38).

The documentation states that "copystat() never returns failure."

StackOverflow link: https://stackoverflow.com/questions/51616058/shutil-copystat-fails-inside-docker-on-azure#51635427

I can provide a pull request, if it is OK to add errno.ENOSYS to the list of ignored errors. (Would be a similar fix to the one provided for https://bugs.python.org/issue24564 (https://github.com/python/cpython/pull/8601).)

----------
components: Library (Lib)
messages: 322866
nosy: nuarhu
priority: normal
severity: normal
status: open
title: shutil.copystat fails in dockered Linux (Debian) on Azure (Windows)
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34308>
_______________________________________

From report at bugs.python.org  Wed Aug  1 10:56:44 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 14:56:44 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533135404.64.0.56676864532.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8112

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Wed Aug  1 11:28:03 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Aug 2018 15:28:03 +0000
Subject: [issue34286] lib2to3 tests fail on the 3.7 branch (used to work with
 3.7.0)
In-Reply-To: <1533007091.73.0.56676864532.issue34286@psf.upfronthosting.co.za>
Message-ID: <1533137283.04.0.56676864532.issue34286@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I'm not able to reproduce this:

 ./configure
 make -s -j
 sudo make install
 python3.7 -m test test_lib2to3

 Run tests sequentially
 0:00:00 load avg: 0.86 [1/1] test_lib2to3

 == Tests result: SUCCESS ==

 1 test OK.

 Total duration: 13 sec 456 ms
 Tests result: SUCCESS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34286>
_______________________________________

From report at bugs.python.org  Wed Aug  1 11:56:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 15:56:19 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533138979.28.0.56676864532.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 6c785c0ebdadc84d80a53d896c38fd7ada8ae1f6 by Victor Stinner in branch 'master':
bpo-34170: Add Python/coreconfig.c for _PyCoreConfig (GH-8607)
https://github.com/python/cpython/commit/6c785c0ebdadc84d80a53d896c38fd7ada8ae1f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:04:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 16:04:12 +0000
Subject: [issue31650] implement PEP 552
In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za>
Message-ID: <1533139452.03.0.56676864532.issue31650@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8113

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31650>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:04:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 16:04:12 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533139452.16.0.665841612001.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8114

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:18:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 16:18:10 +0000
Subject: [issue31650] implement PEP 552
In-Reply-To: <1506801596.1.0.213398074469.issue31650@psf.upfronthosting.co.za>
Message-ID: <1533140290.75.0.56676864532.issue31650@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 80b762f010097ab8137782e5fbdc89c5c620ed4e by Victor Stinner in branch 'master':
bpo-31650: Remove _Py_CheckHashBasedPycsMode global config var (GH-8608)
https://github.com/python/cpython/commit/80b762f010097ab8137782e5fbdc89c5c620ed4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31650>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:18:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 16:18:10 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533140290.92.0.902498594338.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 80b762f010097ab8137782e5fbdc89c5c620ed4e by Victor Stinner in branch 'master':
bpo-31650: Remove _Py_CheckHashBasedPycsMode global config var (GH-8608)
https://github.com/python/cpython/commit/80b762f010097ab8137782e5fbdc89c5c620ed4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:18:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2018 16:18:51 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533140331.75.0.56676864532.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

"""
TODO list, open questions:

* Should isolated=1 always imply config->ignore_environment=1 and config->user_site_directory = 0?
* Should we rename debug to parser_debug? "debug" is a very generic term, whereas this flag is really specific to the parser
* Remove _Py_CheckHashBasedPycsMode: replace it with config._check_hash_pycs_mode?
"""

=> DONE!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:20:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Aug 2018 16:20:44 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533140444.07.0.56676864532.issue33695@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not convinced that this change should be merged. The benefit is small, and 1) it is only for an artificial set of tiny files, 2) the benchmarking ignores the real IO, it measures the work with a cache. When copy real files (/usr/include or Lib/) with dropped caches the difference is insignificant. On other hand, this optimization makes the code more complex. It can make the case with specifying the ignore argument slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Wed Aug  1 12:24:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Aug 2018 16:24:07 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533140647.18.0.56676864532.issue33695@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For dropping disc caches on Linux run

    with open('/proc/sys/vm/drop_caches', 'ab') as f: f.write(b'3\n')

before every test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Wed Aug  1 13:16:31 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Wed, 01 Aug 2018 17:16:31 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533143791.63.0.56676864532.issue34120@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

I can confirm that removing the grab_set() calls fixes the locking. But am I the only one to notice that the dialogs aren't modal any more?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 13:33:36 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Wed, 01 Aug 2018 17:33:36 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533144816.28.0.56676864532.issue34120@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

Adding self.grab_release() in the ok() method for the dialogs BEFORE destroy() solved the problem for me, keeping the grab_set() methods in place (uncommented, actives).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 13:36:13 2018
From: report at bugs.python.org (chris)
Date: Wed, 01 Aug 2018 17:36:13 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
Message-ID: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>


New submission from chris <christoph.wiedemann at hs-weingarten.de>:

I'm linking an issue from numpy here: https://github.com/numpy/numpy/issues/8097

Embedding python suffers from a possibility to reliably reset the state of the python interpreter. For my use case, I noticed that when using numpy with Py_Initialize() and Py_Finalize():

Py_Initialize()
// call code importing numpy
Py_Finalize()
Py_Initialize()
// call same code again

The above code will result in a crash.

One of the comments in the referenced issue is that Py_Finalize doesn't unload loaded DLL's or shared objects. Doing that would probably fix the issues.

As of now, embedding python is fundamentally broken for applications which want to embed non-trivial scientific python scripts involving user-adapted python code, because

a) Py_Finalize cannot be used reliably
b) There is no possibility to reliably reset the python interpreter otherwise (because the sub-interpreters are also not working reliably, which is stated in the documentation)
c) manually reloading changed modules via importlib.reload is not a feasible solution

The possibility to reset an embedded python interpreter to an initial state is a strong requirement for such applications.

----------
components: Extension Modules, Interpreter Core
messages: 322876
nosy: christoph.wiedemann at hs-weingarten.de
priority: normal
severity: normal
status: open
title: Embedding Python; Py_Initialize / Py_Finalize cycles
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 13:38:45 2018
From: report at bugs.python.org (Wu Yu)
Date: Wed, 01 Aug 2018 17:38:45 +0000
Subject: [issue34310] Build error with option "--with-pydebug" on Mac OS
 10.13.6
Message-ID: <1533145125.37.0.56676864532.issue34310@psf.upfronthosting.co.za>


New submission from Wu Yu <chaconnewu at gmail.com>:

I'm encountering a build error from the master branch of CPython (heads/master-dirty:d17fe275a3) on Mac OS 10.13.6, with "--with-pydebug" turned on. 

The error message:

./python.exe -E -S -m sysconfig --generate-posix-vars ;\
	if test $? -ne 0 ; then \
		echo "generate-posix-vars failed" ; \
		rm -f ./pybuilddir.txt ; \
		exit 1 ; \
	fi
Assertion failed: (TYPE(ch) == test || TYPE(ch) == test_nocond || TYPE(ch) == star_expr), function seq_for_testlist, file Python/ast.c, line 1205.
/bin/sh: line 1: 34527 Abort trap: 6           ./python.exe -E -S -m sysconfig --generate-posix-vars
generate-posix-vars failed
make: *** [pybuilddir.txt] Error 1

----------
components: Build
messages: 322877
nosy: wuyu
priority: normal
severity: normal
status: open
title: Build error with option "--with-pydebug" on Mac OS 10.13.6
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34310>
_______________________________________

From report at bugs.python.org  Wed Aug  1 13:50:25 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Aug 2018 17:50:25 +0000
Subject: [issue34307] NullHandler init refusing arguments
In-Reply-To: <1533130455.97.0.56676864532.issue34307@psf.upfronthosting.co.za>
Message-ID: <1533145825.91.0.56676864532.issue34307@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I expected it to be a "dummy" handler that might accept any argument

I don't know why you expected that, but your expectation wasn't valid. You will need to define your own BaseHandler which handles any arguments passed by your logging configuration.

NullHandler's __init__ is inherited from logging.Handler. There are no plans to change that. The documentation for it states:

"The NullHandler class, located in the core logging package, does not do any formatting or output. It is essentially a ?no-op? handler for use by library developers."

This does not indicate that it is suitable for use as a base class. If you want to use a base class for your handler, use logging.Handler.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34307>
_______________________________________

From report at bugs.python.org  Wed Aug  1 14:42:13 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Aug 2018 18:42:13 +0000
Subject: [issue9372] pulldom.DOMEventStream.__getitem__ is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1533148933.75.0.56676864532.issue9372@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8115

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9372>
_______________________________________

From report at bugs.python.org  Wed Aug  1 14:44:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Aug 2018 18:44:44 +0000
Subject: [issue9372] pulldom.DOMEventStream.__getitem__ is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1533149084.32.0.56676864532.issue9372@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I've fixed a bug that uses DOMEventStream.__getitem__ at work today. I've opened PR 8609 to deprecate __getitem__ methods of DOMEventStream, FileInput and FileWrapper classes.

----------
components: +Library (Lib)
nosy: +berker.peksag
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9372>
_______________________________________

From report at bugs.python.org  Wed Aug  1 15:11:09 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Wed, 01 Aug 2018 19:11:09 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533150669.33.0.56676864532.issue34120@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

I've checked again the source code in config_key.py, configdialog.py, help_about.py, query.py, searchbase.py, textview.py and added a self.grab_release() in functions like ok() and cancel() before the call to self.destroy() and I see no more lock/focus issues. Maybe the grab was kept in the non-existent (destroyed) dialog window, so the click events could not be transferred to the pyshell or editor, but, because of a local (not global) grab, clicking on another application's window, by losing focus and grab, completely freed the event-chain, then clicks in IDLE were correctly received.
Can you confirm if adding the grab_release() calls works for you too (do not remove the grab_set() calls!)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 15:32:57 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Aug 2018 19:32:57 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533151977.48.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

The matter of unloading extension modules is partly covered in bpo-401713.  However, note that a few things have changed in the last 18 years. :)  I think it would be worth revisiting the decision in that issue at this point.

If that were sorted out would there be other issues to address?

Regardless, If I understood right, your only objective here is to completely reset Python in the current process to the initial state.  You mention "embedded python interpreter", but it sounds more like you mean "embedded python runtime" (particularly since you are using Py_Initialize and Py_Finalize).  Why is completely resetting Python "a strong requirement"?

----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 15:43:01 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Aug 2018 19:43:01 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533152581.64.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Regarding your 3 points:

> a) Py_Finalize cannot be used reliably

Note that unloading extension modules is not the only thing that Py_Finalize isn't doing that it probably should be.  I expect that you would find a number of memory leaks and potentially cases that crash the process when calling Py_Initialize() after Py_Finalize().

As bpo-401713 indicates, calling Py_Initialize/Py_Finalize multiple times isn't a well supported pattern.  The docs indicate likewise (see https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx).  That said, I'm sure everyone agrees that it *should* work and that we should fix issues there when we can.  It's mostly a matter of finding folks motivated enough to work on it. :)

> b) There is no possibility to reliably reset the python interpreter otherwise

At the level of the interpreter (main or otherwise), the C-API doesn't really provide anything like that, though I suppose it could.  However, it's mostly simpler to just make a new interpreter.  So I doubt we'd introduce an explicit concept of resetting an interpreter.  What would be the advantage?

At the level of the *runtime* the C-API likewise doesn't offer anything for reset, other than what you've already tried.  It would really help to understand why resetting is needed.

>  (because the sub-interpreters are also not working reliably,
> which is stated in the documentation)

This is something I'm actively working on, including improving isolation between interpreters (minimizing global state) and improving the extension module experience when using subinterpreters.  The latter is tricky, particularly with extension modules that use libraries that have their own C globals.

Note that isolation between interpreters will never be perfect.  If you need perfect isolation then use multiple processes.  All interpreters in the same process will always share the runtime state, as well as process-wide data.

FWIW, even if we were to completely isolate the Python runtime, allowing more than one runtime in a process, the runtimes would still share the process-wide data.

> c) manually reloading changed modules via importlib.reload is not a
> feasible solution

Yeah, while I suppose it could work for some extensions, I expect it would not work for many.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:10:01 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Aug 2018 20:10:01 +0000
Subject: [issue34302] Avoid inefficient way to find start point in deque.index
In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za>
Message-ID: <1533154201.08.0.56676864532.issue34302@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Why are we getting multiple tracker items opening and closing for this at the same time?  Something odd is happening.  Please don't close the tracker and change user ids in the middle of a conversation:

   https://bugs.python.org/issue34298
   https://bugs.python.org/issue34295

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34302>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:20:27 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 20:20:27 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533154827.51.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Adding grab_release() calls also resolves the issue. Tested on mac and win.

PR updated with this approach, IMO ready for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:21:26 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 20:21:26 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533154886.54.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:21:45 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 20:21:45 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533154905.36.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:22:51 2018
From: report at bugs.python.org (James Emerton)
Date: Wed, 01 Aug 2018 20:22:51 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
Message-ID: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>


New submission from James Emerton <james at emerton.info>:

We use locale.format('%.2f', x, True) to convert Decimal values to strings for display. Unfortunately, the locale module is using %-formatting to generate the initial string before applying locale specific formatting. As a result, any value which cannot be accurately represented as a float will produce incorrect results.

I've built some formatting that uses new-style string formatting (and some internal locale functions) which corrects the problem.

Unfortunately, making this change in the locale module would require converting the input format string to the new syntax, so '%.2f' would become '{:.2f}'.

See also #33731

----------
components: Library (Lib)
messages: 322885
nosy: jemerton
priority: normal
severity: normal
status: open
title: locale.format() and locale.format_string() cast Decimals to float
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:37:02 2018
From: report at bugs.python.org (chris)
Date: Wed, 01 Aug 2018 20:37:02 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533155822.09.0.56676864532.issue34309@psf.upfronthosting.co.za>


chris <christoph.wiedemann at hs-weingarten.de> added the comment:

Thanks for your comments and the link to the issue from the year 2000.

> You mention "embedded python interpreter", but it sounds more like you mean "embedded python runtime"

Yes that's right. Sorry for imprecise wording.

> Why is completely resetting Python "a strong requirement"?

Because otherwise, if this is not an option, we need to restart the embedding C/C++ application whenever a python module is changed and need to be reloaded. This is occurring frequently in our use case and it is the main reason we want to embed python for rapid development purposes. (The application itself is a development environment for computer vision algorithms, where python is only one of multiple interacting, configurable plugins.)

Being forced to restart the whole application on code changes compromises the advantage of using a scripting language without edit/compile/link steps to a degree which questions the whole idea. I'm not very confident in hacking reload(...) stuff in the modules. 

Interestingly enough, our use case matches exactly the one which has been described as unlikely in the original issue (https://bugs.python.org/issue401713#msg34524): the python runtime is dynamically loaded at runtime as a plugin :) I haven't tried it, but I suppose that we get the very same issues when we reload the plugin, because the dynamic libraries of extension modules are still loaded with an invalid state.

Maybe using processes and some kind of socket / shared memory communication would suit our needs better, but this is also much more complicated and error-prone to implement than simply embedding python into the main process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:47:42 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 01 Aug 2018 20:47:42 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
Message-ID: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

str.endswith() and str.startswith() only takes str or a tuple of str. It might be nice to make this str or an iterable of str (and that order must be kept so that a string isn't treated as an iterable of length-1 str).

----------
components: Interpreter Core
messages: 322887
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Allow str.endswith and str.startswith to accept an iterable
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:49:42 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 20:49:42 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
Message-ID: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>


New submission from Tal Einat <taleinat at gmail.com>:

On macOS 10.13.5 (the latest available) with ActiveTcl 8.6.7 (the latest available), I'm building Python from latest master (to be 3.8.0).  I'm consistently having IDLE crash almost immediately, just by opening any file for editing.  The crash results in the following error:

$ root/bin/python3 -m idlelib
objc[50759]: Invalid or prematurely-freed autorelease pool 0x7fb74091f050.
[1]    50759 abort      root/bin/python3 -m idlelib

In issue34120, @vtudorache reported a similar issue (also on macOS).

With Python 3.7.0 from python.org, everything works fine.

Strangely, replacing ActiveTcl with version 8.5.18.0 resolves this issue.

I'm not sure whether this is specific to IDLE; I'll try to provide a minimal way to reproduce.

----------
assignee: terry.reedy
components: IDLE, Tkinter
messages: 322888
nosy: gpolo, serhiy.storchaka, taleinat, terry.reedy, vtudorache
priority: normal
severity: normal
status: open
title: IDLE crashes with Tk-related error on macOS with ActiveTcl 8.6
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Wed Aug  1 16:55:24 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 01 Aug 2018 20:55:24 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533156924.56.0.56676864532.issue34309@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 17:41:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Aug 2018 21:41:47 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533159707.83.0.56676864532.issue34120@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I wrote the following justification for adding grab_release while Tal was revising his PR to make the change.  I will look at the PR now and test on Windows.
---

Vlad, I was wondering about modality.  Properly de-modalizing a dialog requires more than just removing grab_set.  The parent of a modal dialog is a window with a menu, an instance of idlelib.  If a dialog were not modal, its parent could be deleted, which would also delete the dialog and any un-saved and un-acted-upon data.  This is true of Debugger, whose parent is Shell.  Duplicate dialogs would also be possible, as is true of IDLE Help, whose parent is root, unless explicitly prevented, as is true of Debugger (Shell knows if there is a Debugger instance).

Removing modality has been discussed in various places, such as in #24760, which focuses on Settings.  If it were de-modalized, its parent should be root and only one copy allowed.  Mark Roseman noted on the issue that "because modal doesn't fully work on the Mac, you can actually create multiple copies of the config dialog!".

So my preferred short-term fix, once confirmed, for 3.7.1, would be the addition of grab_release.

Merely removing grab would have to be Mac-specific, and I would expect new problems and complaints.  Properly de-modalizing on all platforms, where sensible, is a longer-term project.  Notepad++ on Windows, for instance, has a non-modal singleton Find dialog (with Replace and Find in Files on separate tabs), designed as such, that operates on the 'current' editor tab, unless one selects 'Find All in All Open Documents' to work on all of them.

PS: Tal Einat also get 'autorelease pool' errors when trying to run IDLE on locally built 3.7.0.

----------
dependencies:  -Problems with tkinter and tk8.6 on MacOS
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 17:47:28 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Aug 2018 21:47:28 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533160048.48.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Ah, thanks for clarifying.  So which of these is the main thing you really want:

1. reload extension modules
2. completely restart Python

It sounds like #1.  If that's the case then there are a number of issues to resolve to make it work.  However, there are some serious technical challenges to overcome. :/

So if it's #1 the problem space is relatively focused so a solution (if possible) would be tractable in the "short" term, so it *could* happen. :)  However, if it's #2 then a lot of things will have to fixed and so realistically it might never happen.

FYI, either way none of it will be backported, so the functionality would not be available on Python 3.7 or earlier.

---------------

FWIW, in VS Code they run their plugins (extensions) in a separate process.  Their docs give some insight into plugin system design. :)

   https://code.visualstudio.com/docs/extensionAPI/patterns-and-principles#_stability-extension-isolation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 17:49:38 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 01 Aug 2018 21:49:38 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533160178.65.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Why remove the 2.7 version? This bug occurs with 2.7.15 on macOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 17:56:50 2018
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Wed, 01 Aug 2018 21:56:50 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1533160610.03.0.56676864532.issue1230540@psf.upfronthosting.co.za>


Change by Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com>:


----------
keywords: +patch
pull_requests: +8116
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Wed Aug  1 18:08:24 2018
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Wed, 01 Aug 2018 22:08:24 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1533161304.27.0.56676864532.issue1230540@psf.upfronthosting.co.za>


Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> added the comment:

I've added a PR with a patch I developed during the EuroPython 2018 sprint.

I've fixed this issue in a way that is more or less consistent with how '_thread' threads interact with sys.excepthook, but I haven't added the log line they print to sys.stderr about an unhandled exception in a thread:

    Unhandled exception in thread started by <function <lambda> at 0x108c840d0>

I can add these messages if they are needed.

I'd like to mention the issue I discussed with Victor Stinner at the sprints (adding Victor to the nosy list as he requested). The fix could possibly break the de facto contract that has been there for ages that 'theading' threads don't invoke sys.excepthook on uncaught exceptions.

If the fact that sys.execepthook doesn't work with threading is considered a feature, then an alternative solution could be a new threading-specific hook: threading.excepthook.

----------
nosy: +vlasovskikh, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Wed Aug  1 18:08:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Aug 2018 22:08:42 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533161322.4.0.56676864532.issue34120@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Removing 2.7 was unintended, from simultaneous editing.  This is one of the exceptional cases where a backport is worth the risk (which seems here extremely low).  I will remove it from the PR because auto backport will fail because of file renames, in addition to internal changes.  Here are the new name to old name translations, where not a just a case change, needed to prepare a 2.7 patch.

config_key  keybindingDialog
help_about aboutDialog
query  .  # New in 3.6. Grep 2.7 code for 'grab_set' to find any usages in deleted code that query replaced.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Wed Aug  1 18:10:52 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Aug 2018 22:10:52 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533161452.59.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Also, part of the motivation for PEP 489 (extension module initialization) was to help with reloading extension modules.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 18:12:50 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Aug 2018 22:12:50 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1533161570.49.0.56676864532.issue1230540@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

No, I think this is a bug that deserves fixing, at least in 3.8.

----------
versions: +Python 3.8 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Wed Aug  1 18:15:22 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Aug 2018 22:15:22 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533161722.12.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Also, PEP 3121 provides a good summary of some of the issues at hand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  1 19:16:22 2018
From: report at bugs.python.org (Conrad Ho)
Date: Wed, 01 Aug 2018 23:16:22 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533165382.09.0.56676864532.issue24255@psf.upfronthosting.co.za>


Conrad Ho <conrad.alwin.ho at gmail.com> added the comment:

Hi,

I have referenced the original patch and created an updated patch that uses the logging module + f-strings in place of the print statements in the http.client module. Also updated the relevant tests for print/logging in test_httplib to reflect these changes.

The HTTPHandlerTest testcase from test_logging was also affected. In the testcase, it gets a logger with name 'http' and adds a logging.HTTPHandler to it. In our patch, we create a http.client logger, which happens to be considered a child of this testcase logger under the logger naming hierarchy.

This causes http.client logging events to propagate up to the 'http' logger and for the testcase to loop infinitely (ie. the HTTPHandler calls http.client functions internally. These functions log events using the http.client logger, which propagate up to the testcase http logger which calls HttpHandler again).

I have simply changed the testcase getLogger name to not be 'http' and clash with that http.client module logger.

----------
nosy: +Conrad Ho
Added file: https://bugs.python.org/file47727/http-client-logging-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Wed Aug  1 19:49:55 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Aug 2018 23:49:55 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533167395.78.0.56676864532.issue34313@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume then that you tested PR8603 without opening an editor (which is certainly possible).

10.13.6 was released in the last month.

PCBuild/build.bat -e downloads missing external dependency source code into externals/ and then compiles it into compatible .dlls.  This includes doing updates as appropriate. I presume that the source and compilation flags are the same as used to make a release. AFAIK, Zach Ware is mainly responsible for the current easy-to-use, easy-to-get-right status.

For a stripped-down reporducer, you might start with the files I attached to #34047.

----------
assignee: terry.reedy -> 
components: +macOS
nosy: +ned.deily, ronaldoussoren -gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:03:09 2018
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 02 Aug 2018 00:03:09 +0000
Subject: [issue34286] lib2to3 tests fail on the 3.7 branch (used to work with
 3.7.0)
In-Reply-To: <1533007091.73.0.56676864532.issue34286@psf.upfronthosting.co.za>
Message-ID: <1533168189.22.0.56676864532.issue34286@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

strange. I see it succeeding in the build location, not the install location.  Did you make sure to cd /tmp before running the test?

I still can reproduce it:

$ python3.7 -m test test_lib2to3
Run tests sequentially
0:00:00 load avg: 0.24 [1/1] test_lib2to3
test test_lib2to3 failed -- multiple errors occurred; run in verbose mode for details
test_lib2to3 failed

== Tests result: FAILURE ==

1 test failed:
    test_lib2to3

Total duration: 5 sec 211 ms
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34286>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:07:21 2018
From: report at bugs.python.org (ksg97031)
Date: Thu, 02 Aug 2018 00:07:21 +0000
Subject: [issue34302] Avoid inefficient way to find start point in deque.index
In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za>
Message-ID: <1533168441.97.0.56676864532.issue34302@psf.upfronthosting.co.za>


Change by ksg97031 <ksg97031 at gmail.com>:


----------
keywords: +patch
pull_requests: +8117
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34302>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:10:08 2018
From: report at bugs.python.org (Seonggi Kim)
Date: Thu, 02 Aug 2018 00:10:08 +0000
Subject: [issue34302] Avoid inefficient way to find start point in deque.index
In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za>
Message-ID: <1533168608.42.0.56676864532.issue34302@psf.upfronthosting.co.za>


Seonggi Kim <ksg97031 at gmail.com> added the comment:

I thing so too, it's my fault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34302>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:16:31 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Aug 2018 00:16:31 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533168991.89.0.56676864532.issue33695@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I agree the provided benchmark on Linux should be more refined. And I'm not sure if "echo 3 | sudo tee /proc/sys/vm/drop_caches" before running it is enough honestly.

The main point here is the reduction of stat() syscalls (-38%) and that can make a considerable  difference, especially with network filesystems. That's basically the reason why scandir() was introduced in the first place and used in os.walk() glob.glob() and shutil.rmtree(), so I'm not sure why we should use a different rationale for shutil.copytree().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:29:02 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 02 Aug 2018 00:29:02 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1533169742.76.0.56676864532.issue34311@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:32:19 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 00:32:19 +0000
Subject: [issue34286] lib2to3 tests fail on the 3.7 branch (used to work with
 3.7.0)
In-Reply-To: <1533007091.73.0.56676864532.issue34286@psf.upfronthosting.co.za>
Message-ID: <1533169939.14.0.56676864532.issue34286@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I ran "python3.7 -m test test_lib2to3" in a separate terminal. I don't remember the exact location, but I'm sure it wasn't the build location (it was probably my home directory)

Is it possible to add some debug print()s inside https://github.com/python/cpython/blob/3.7/Lib/lib2to3/tests/support.py#L37 ? My only guess is that the test code somehow finds the wrong refactorer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34286>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:40:06 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 02 Aug 2018 00:40:06 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1533170406.14.0.56676864532.issue34311@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Would my suggestion in #33731 of adding another letter in the format spec for float and decimal.Decimal solve your problem? I guess if you're using monetary=True you'd need two additional letters: like 'f' but locale aware, and like 'f' but locale aware and monetary=True.  Maybe 'l' and 'L' for these? In this case, there would be no changes to the locale module.

I don't see any good way of using new-style formatting without changing float.__format__ and decimal.Decimal.__format__.

----------
components: +Interpreter Core
type:  -> enhancement
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:48:39 2018
From: report at bugs.python.org (James Emerton)
Date: Thu, 02 Aug 2018 00:48:39 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1533170919.18.0.56676864532.issue34311@psf.upfronthosting.co.za>


James Emerton <james at emerton.info> added the comment:

Certainly adding another letter to the format spec would solve my issue and would in fact be somewhat preferable to using local.format directly.

I think this could be fixed in the locale module by transforming the format spec and using new-style formatting, but I'm not familiar enough with the corner cases to know if its practical to cover all the possible cases; particularly those coming from format_string().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Wed Aug  1 20:48:53 2018
From: report at bugs.python.org (James Emerton)
Date: Thu, 02 Aug 2018 00:48:53 +0000
Subject: [issue33731] string formatting that produces floats with preset
 precision while respecting locale
In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za>
Message-ID: <1533170933.45.0.56676864532.issue33731@psf.upfronthosting.co.za>


Change by James Emerton <james at emerton.info>:


----------
nosy: +jemerton

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33731>
_______________________________________

From report at bugs.python.org  Wed Aug  1 21:44:28 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 02 Aug 2018 01:44:28 +0000
Subject: [issue34259] Improve docstring of list.sort
In-Reply-To: <1532778727.04.0.56676864532.issue34259@psf.upfronthosting.co.za>
Message-ID: <1533174267.99.0.56676864532.issue34259@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Copying from the sorted built-in's docstring would make sense here, given that sorted is implemented in terms of list.sort in the first place.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34259>
_______________________________________

From report at bugs.python.org  Wed Aug  1 22:37:03 2018
From: report at bugs.python.org (ppperry)
Date: Thu, 02 Aug 2018 02:37:03 +0000
Subject: [issue34279] RFC: issue a warning in regrtest when no tests have been
 executed?
In-Reply-To: <1532947707.98.0.56676864532.issue34279@psf.upfronthosting.co.za>
Message-ID: <1533177423.2.0.56676864532.issue34279@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: RFC: issue a warning in regrtest when no test have been executed? -> RFC: issue a warning in regrtest when no tests have been executed?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34279>
_______________________________________

From report at bugs.python.org  Wed Aug  1 22:54:24 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Aug 2018 02:54:24 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533178464.44.0.56676864532.issue34312@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

ISTM that this would encourage silently inefficient coding patterns like:

   url.endswith({'.html', '.txt', '.php'})
   # The set object gets rebuilt on every call
   # and a new set iterator object gets built on every call.
   # Looping over the contents uses the slower iterator protocol
   # rather than the existing superfast PyTuple_GET_SIZE() and
   # PyTuple_GET_ITEM() macros which are entirely in-lined.

Do we have any known use cases or user requests where the existing API doesn't suffice?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Wed Aug  1 22:57:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Aug 2018 02:57:59 +0000
Subject: [issue34259] Improve docstring of list.sort
In-Reply-To: <1532778727.04.0.56676864532.issue34259@psf.upfronthosting.co.za>
Message-ID: <1533178679.36.0.56676864532.issue34259@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34259>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:02:06 2018
From: report at bugs.python.org (Dan Snider)
Date: Thu, 02 Aug 2018 03:02:06 +0000
Subject: [issue34314] Like __hash__,
 allow setting MyClass.__init__ to None to prevent it being called by
 type.__call__
Message-ID: <1533178926.29.0.56676864532.issue34314@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Right now, you really gotta jump through hoops in some cases if you only want to use __new__ and don't care about __init__ (is there ever a time where you'd use both?). The problem originates in type.__call__. I'm attaching a full Python implementation of type_call/object_init at the end, but here's a tl;dr representation of the issue i type_call (where the whole thing can be basically summarized as this):

def type_call(type, *args, **kws):
   r = type.__new__(type, *args, **kws)
   if not issubclass(r, type):
       type(r).__init__(r, *args, **kws)
   return r

So if type(r).__init__ is object.__init__ or some other method with an incompatible signature to the metaclass's, errors are raised, which leads to having to implement really annoying workarounds. The annoyingness is compounded further by the fact that all object_init does is make sure it didn't receive any arguments. 

All of that can be avoided by setting __init__ in the class to None, which would have the same effect as setting tp_init to NULL on an extension type. Perhaps with a caveat that the only current reachable __init__ is object.__init__?

I don't really find myself in situations involving the need for __new__ too often, but wouldn't this have a profoundly positive impact on pickle as well? One thing I can think of is there can be a universal pickle implementation for extension types with Py_TPFLAGS_BASETYPE set and a nonzero dict offset since if it detected a NULL init all it has to do is memcpy the base struct and pickle the instance dict.

Anyway, the C code is pretty easy to understand but here's a Python implementation almost exactly equivalent that shows a case where a metaclass can be used as a callable that accepts an arbitrary number of arguments instead of a forced three and returns a class:


PyType_Type = type
Py_TYPE = type
PyType_IsSubtype = issubclass
PyTuple_Check = tuple.__instancecheck__
PyDict_Check = dict.__instancecheck__
PyDict_GET_SIZE = dict.__len__
PyTUple_GET_SIZE = tuple.__len__

NULL = 0
ALLOW_NULL_INIT = False

def excess_args(args, kws):
    return args or kws

class Object:

    def __init__(self, *args, **kws):
        # object_init literally does nothing but check for zero len args/kws
        # (bit of a tangent but why is excess_args not a macro...?)
        if ALLOW_NULL_INIT:
            return
        tp = Py_TYPE(self)
        print('Object.__init__, type is:', tp.__name__)
        if excess_args(args, kws):
            if tp.__init__ is object.__init__:
                raise TypeError("object.__init__() takes no arguments")
            raise TypeError(f'{tp.__name__}.__init__() takes no arguments')

def fake_init(*args, **kws):
    pass

class Type(type):

    def __getattribute__(self, attr):
        value = type.__getattribute__(self, attr)
        if attr == '__init__':
            if ALLOW_NULL_INIT and value is None:
                return fake_init
            return super(type(self).__mro__[1], self).__init__
        return value
    
    def __call__(tp, *args, **kws):
        
        if getattr(tp, '__new__', 0) == NULL:
            raise TypeError(f"cannot create {tp.__name__} instances")
        
        obj = tp.__new__(tp, *args, **kws)
        if (tp is type and
            PyTuple_Check(args) and PyTuple_GET_SIZE(args)== 1 and
            (kws == NULL or
             (PyDict_Check(kws) and PyDict_GET_SIZE(kws)==0))):
            return obj
        
        if not PyType_IsSubtype(Py_TYPE(obj), tp):
            return obj
        
        tp = Py_TYPE(obj)
        
        # Here's where the problem is. What could possibly be negatively
        # affected by this?
        if getattr(tp, '__init__', 0):
            res = tp.__init__(obj, *args, **kws)
            
        return obj

def autoname(arg):
    return '_'.join(arg.split())

def autobase(opt):
    return () if not opt else (opt,)

class MetaBase(Object, type):
    pass

class Mixin1:
    pass

class Meta(MetaBase, metaclass=Type):

    __init__ = None
        
    def __new__(metacls, name, opt=None):
        return super().__new__(metacls, autoname(name), autobase(opt), {})

if __name__ == '__main__':
    try:
        foobar = Meta('foo bar', Mixin1)
    except TypeError as er:
        print(f'could not make foobar because: {er}')
    print('setting ALLOW_NULL_INIT to True;')
    ALLOW_NULL_INIT = True
    foobar = Meta('foo bar', Mixin1)
    print('foobar.__name__ is:', foobar.__name__)
    print('foobar__mro__ is:', foobar.__mro__)

----------
components: Interpreter Core
messages: 322907
nosy: bup
priority: normal
severity: normal
status: open
title: Like __hash__, allow setting MyClass.__init__ to None to prevent it being called by type.__call__
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34314>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:17:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Aug 2018 03:17:08 +0000
Subject: [issue34314] Like __hash__,
 allow setting MyClass.__init__ to None to prevent it being called by
 type.__call__
In-Reply-To: <1533178926.29.0.56676864532.issue34314@psf.upfronthosting.co.za>
Message-ID: <1533179828.95.0.56676864532.issue34314@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Right now, you really gotta jump through hoops
> in some cases if you only want to use __new__ 
> and don't care about __init__ 

I'm now sure I see the difficulty. It is easy to define a classes with __new__ and without __init__:

    >>> class A:
            def __new__(cls, *args):
                print('New called with', cls, 'and', args)
                return object.__new__(cls)

    >>> a = A(10, 20, 30)
    New called with <class '__main__.A'> and (10, 20, 30)
    >>> isinstance(a, A)
    True

> Like __hash__, allow setting MyClass.__init__ to None

FWIW, the API for hashing being set-to-None wasn't done because we like it (there a numerous downsides). It was done because we needed hashing to be on by default and there needed to be a way to turn it off.  The downsides are that it confuses users, it is hard to teach and remember, and it adds a branch to various APIs which would then need to test for None.  Instead, we prefer the pattern of having object() provide a default dummy method that either does nothing or gives up (like object.__init__ or the various rich comparison methods for object).  This simplifies downstream code than doesn't have to check for a rare special case.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34314>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:34:56 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Aug 2018 03:34:56 +0000
Subject: [issue33731] string formatting that produces floats with preset
 precision while respecting locale
In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za>
Message-ID: <1533180896.27.0.56676864532.issue33731@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8118
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33731>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:37:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 03:37:07 +0000
Subject: [issue34314] Like __hash__,
 allow setting MyClass.__init__ to None to prevent it being called by
 type.__call__
In-Reply-To: <1533178926.29.0.56676864532.issue34314@psf.upfronthosting.co.za>
Message-ID: <1533181027.61.0.56676864532.issue34314@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Setting __hash__ to None doesn't do what you think. It doesn't prevent __hash__ from being called by hash(), instead it produces a TypeError.

>>> class A: __hash__ = None
... 
>>> hash(A())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'A'

Actually the effect of special casing __hash__ is not raising a TypeError, but raising a TypeError with better error message. A TypeError was already raised before if set __hash__ to a non-callable. In 2.7:

>>> class A: __hash__ = None
... 
>>> hash(A())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable


If you want to prevent an inherited __init__ from being called by types's __call__, you can define an __init__ with an empty body.

    def __init__(self, *args, **kwargs):
        pass

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34314>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:38:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 03:38:09 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533181089.89.0.56676864532.issue34312@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have same concerns as Raymond.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:42:26 2018
From: report at bugs.python.org (James Emerton)
Date: Thu, 02 Aug 2018 03:42:26 +0000
Subject: [issue33731] string formatting that produces floats with preset
 precision while respecting locale
In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za>
Message-ID: <1533181346.48.0.56676864532.issue33731@psf.upfronthosting.co.za>


James Emerton <james at emerton.info> added the comment:

So far, I've implemented this for Decimal

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33731>
_______________________________________

From report at bugs.python.org  Wed Aug  1 23:52:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 03:52:46 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533181966.95.0.56676864532.issue33695@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

os.walk() and glob.glob() used *only* stat(), opendir() and readdir() syscalls (and stat() syscalls dominated). The effect of reducing the number of the stat() syscalls is significant. shutil.rmtree() uses also the unlink() syscall. Since it is usually cheap (but see issue32453), the benefit still is good, but not such large. Actually I had concerns about using scandir() in shutil.rmtree().

shutil.copytree() needs to open, read, and write files. This is not so cheap, and the benefit of reducing the number of the stat() syscalls is hardly noticed in real cases. shutil.copytree() was not converted to using scandir() intentionally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Thu Aug  2 00:26:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Aug 2018 04:26:08 +0000
Subject: [issue33731] string formatting that produces floats with preset
 precision while respecting locale
In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za>
Message-ID: <1533183968.48.0.56676864532.issue33731@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to see locale() remain somewhat decoupled from the rest of string formatting.  IIRC locale() is finicky especially when concurrency is involved.  I think a best practice is for an app to address locale issues explicitly rather than inside string formatting.  I'll defer to those with more experience using locale -- I just have a vague recollection of this being an area fraught with landmines.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33731>
_______________________________________

From report at bugs.python.org  Thu Aug  2 00:31:21 2018
From: report at bugs.python.org (James Emerton)
Date: Thu, 02 Aug 2018 04:31:21 +0000
Subject: [issue33731] string formatting that produces floats with preset
 precision while respecting locale
In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za>
Message-ID: <1533184281.81.0.56676864532.issue33731@psf.upfronthosting.co.za>


James Emerton <james at emerton.info> added the comment:

@rhettinger See #34311 about formatting Decimals using locale.format(). I'd like to see the problem fixed in one place or the other.

Also, this is seems relatively straightforward to implement as it's really just a combination of the fixed precision 'f' and the locale specific 'n' format types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33731>
_______________________________________

From report at bugs.python.org  Thu Aug  2 00:35:20 2018
From: report at bugs.python.org (chipstuff)
Date: Thu, 02 Aug 2018 04:35:20 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1533184520.48.0.56676864532.issue32545@psf.upfronthosting.co.za>


chipstuff <kamil.a at live.com> added the comment:

Experienced the same issue, this is either Permissions or Antivirus blocking Python from being installed.

After uninstall third party AV (avast) and running the following commands to update Defender's signature files the installation was completed.


?%PROGRAMFILES%\Windows Defender\MPCMDRUN.exe? -RemoveDefinitions -All

?%PROGRAMFILES%\Windows Defender\MPCMDRUN.exe? -SignatureUpdate

Source: https://appuals.com/

----------
nosy: +chipstuff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Aug  2 01:52:59 2018
From: report at bugs.python.org (Raman)
Date: Thu, 02 Aug 2018 05:52:59 +0000
Subject: [issue34315] Regex not evalauated correctly
Message-ID: <1533189179.81.0.56676864532.issue34315@psf.upfronthosting.co.za>


New submission from Raman <s_raman002 at yahoo.com>:

Sample code below

import re

regex = r'DELETE\s*(?P<table_alias>[a-zA-z_0-9]*)\s*FROM\s*(?P<table_name>[a-zA-z_0-9]+)\s*([a-zA-Z0-9_]*)\s*(?P<where_statement>WHERE){0,1}(\s.)*?'

test_str = 'DELETE FROM my_table1 t_ WHERE id in (1,2,3)'

matches = re.finditer(regex, test_str, re.MULTILINE)

print([m.groupdict() for m in matches])

Below is the expected output.

[{'table_alias': '', 'table_name': 'my_table1', 'where_statement': 'WHERE'}]

But in Win Server 2012 R2, the output is
[{'table_alias': '', 'table_name': 'mytable1', 'where_statement': None}]

Using 3.7 in Win Server 2012 R2 also the output is not as expected. But in Win 10 and other linux variants, expected output is obtained.

----------
components: Regular Expressions
messages: 322916
nosy: ezio.melotti, mrabarnett, ram, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Regex not evalauated correctly
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34315>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:18:34 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 06:18:34 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533190714.28.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 10ea9409ceb5da83cb380b610750551e26561044 by Tal Einat in branch 'master':
bpo-34120: fix IDLE freezing after closing dialogs (GH-8603)
https://github.com/python/cpython/commit/10ea9409ceb5da83cb380b610750551e26561044


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:19:18 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 06:19:18 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533190758.1.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8119

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:34:15 2018
From: report at bugs.python.org (Eric Wieser)
Date: Thu, 02 Aug 2018 06:34:15 +0000
Subject: [issue1764286] inspect.getsource does not work with decorated
 functions
Message-ID: <1533191655.08.0.56676864532.issue1764286@psf.upfronthosting.co.za>


Eric Wieser <wieser.eric+pybug at gmail.com> added the comment:

New issue opened at https://bugs.python.org/issue34305, along with a PR linked there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1764286>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:34:30 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 06:34:30 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533191670.26.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8120

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:37:53 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 06:37:53 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533191873.41.0.56676864532.issue34120@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d9fc795487f74531ea43760469cc215858d0d908 by Miss Islington (bot) in branch '3.7':
bpo-34120: fix IDLE freezing after closing dialogs (GH-8603)
https://github.com/python/cpython/commit/d9fc795487f74531ea43760469cc215858d0d908


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:42:34 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Aug 2018 06:42:34 +0000
Subject: [issue34315] Regex not evalauated correctly
In-Reply-To: <1533189179.81.0.56676864532.issue34315@psf.upfronthosting.co.za>
Message-ID: <1533192154.6.0.56676864532.issue34315@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34315>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:46:31 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 06:46:31 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1533192391.03.0.56676864532.issue32545@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

After reading everything here, I'm not sure there's anything wrong or to be improved with Python's Windows installers in this regard.  All of the installation errors reported here appear to be caused by external circumstances breaking MSI installation in general.

IMO this should be resolved as "not a bug".

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:49:34 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 06:49:34 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533192574.15.0.56676864532.issue34312@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:55:58 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 06:55:58 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533192958.82.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8121

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 02:58:02 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Aug 2018 06:58:02 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1533193082.51.0.56676864532.issue32545@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Given that Steve  has not found anything useful in the logs, I agree.  In any case, the 3.7.0a4 installer has be superceded by multiple installers, including finally, 3.7.0.  Anyone wanting 3.7 now should use that (and report problems with the same).

By the way, we appreciate people following up and given feedback on our responses, so we can learn too.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:14:20 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 07:14:20 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533194060.35.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8122

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:14:27 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 07:14:27 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533194067.28.0.56676864532.issue34120@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9fcfb7b010bd41d4ebaeed372df92b6962253fed by Miss Islington (bot) in branch '3.6':
bpo-34120: fix IDLE freezing after closing dialogs (GH-8603)
https://github.com/python/cpython/commit/9fcfb7b010bd41d4ebaeed372df92b6962253fed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:21:52 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 07:21:52 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533194512.53.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 894940b1099677c1ca0aa527dbb935e47d3d591a by Tal Einat in branch '2.7':
[2.7] bpo-34120: fix IDLE freezing after closing dialogs (GH-8603)
https://github.com/python/cpython/commit/894940b1099677c1ca0aa527dbb935e47d3d591a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:30:10 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 07:30:10 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533195010.24.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset dd74369cb7b230b07ac3a031563406c8f2aae17f by Tal Einat in branch 'master':
bpo-34120: fix text viewer to call grab_release() only when needed (GH-8616)
https://github.com/python/cpython/commit/dd74369cb7b230b07ac3a031563406c8f2aae17f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:30:31 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 07:30:31 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533195031.03.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:31:18 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 07:31:18 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533195078.61.0.56676864532.issue34120@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8124

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:52:08 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 02 Aug 2018 07:52:08 +0000
Subject: [issue29502] Should PyObject_Call() call the profiler on C functions, 
 use C_TRACE() macro?
In-Reply-To: <1486568378.9.0.904847418882.issue29502@psf.upfronthosting.co.za>
Message-ID: <1533196328.74.0.56676864532.issue29502@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I would prefer to wait with this issue until PEP 580 has been decided. If it's accepted, it will change function calling code a lot. As I wrote in PEP 580, I was planning to have a PEP on profiling anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29502>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:52:28 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 07:52:28 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533196348.24.0.56676864532.issue34120@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 60586de02de074a33c015e5a013d85d0b17e7e61 by Miss Islington (bot) in branch '3.7':
bpo-34120: fix text viewer to call grab_release() only when needed (GH-8616)
https://github.com/python/cpython/commit/60586de02de074a33c015e5a013d85d0b17e7e61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 03:53:00 2018
From: report at bugs.python.org (Christopher Schramm)
Date: Thu, 02 Aug 2018 07:53:00 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533196380.06.0.56676864532.issue34309@psf.upfronthosting.co.za>


Change by Christopher Schramm <python at cschramm.eu>:


----------
nosy: +cschramm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Thu Aug  2 04:29:31 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Thu, 02 Aug 2018 08:29:31 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533198571.13.0.56676864532.issue34313@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

I confirm the crashes. I've tried with personal builds of python 3.5, 3.6, 3.7, with ActiveTcl and personal builds of Tcl 8.6.x, the problem does not appear with 8.5.18, but shows itself with 8.5.19 (strange, API changes?). I'll try to investigate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Thu Aug  2 04:31:24 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 08:31:24 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533198684.92.0.56676864532.issue34120@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8c4a0059accb5cb33e90ec5b2f3e9dc08e2f3048 by Miss Islington (bot) in branch '3.6':
bpo-34120: fix text viewer to call grab_release() only when needed (GH-8616)
https://github.com/python/cpython/commit/8c4a0059accb5cb33e90ec5b2f3e9dc08e2f3048


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 04:33:46 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 02 Aug 2018 08:33:46 +0000
Subject: [issue34120] IDLE: Freeze when closing Settings (& About) dialog on
 MacOS
In-Reply-To: <1531648409.88.0.56676864532.issue34120@psf.upfronthosting.co.za>
Message-ID: <1533198826.59.0.56676864532.issue34120@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Many thanks for the report and follow through, Vlad!

Thank you too, Kevin, for your help in resolving this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34120>
_______________________________________

From report at bugs.python.org  Thu Aug  2 04:51:30 2018
From: report at bugs.python.org (Fantix King)
Date: Thu, 02 Aug 2018 08:51:30 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1533199890.52.0.56676864532.issue33062@psf.upfronthosting.co.za>


Change by Fantix King <fantix.king at gmail.com>:


----------
keywords: +patch
pull_requests: +8125
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Thu Aug  2 04:57:41 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Thu, 02 Aug 2018 08:57:41 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533200261.49.0.56676864532.issue34313@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

The problem shows itself on macOS High Sierra in some Tk Demos, independently of Python's IDLE. So there is something completely different, to report to the Tcl/Tk community. Strangely, I didn't notice the issues on Sierra, but I have no Sierra Mac right now to check it again. Even in Tk 8.5.18 (ActiveState or self-compiled) there are issues (notably the cascade menus demo, the button menus demo, others to) in rendering some UI elements. Sometimes bad indexes are reported (sort of [lindex {A LIST} index $N] gives $N not found even when in range)...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Thu Aug  2 05:01:36 2018
From: report at bugs.python.org (chris)
Date: Thu, 02 Aug 2018 09:01:36 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533200496.75.0.56676864532.issue34309@psf.upfronthosting.co.za>


chris <christoph.wiedemann at hs-weingarten.de> added the comment:

Okay, completely restarting python is not really necessary. Being able to reliably unload and later on re-import python modules (extension modules as well as pure python modules) in an embedded python runtime would solve my problems. 

One way to achieve that is currently Py_Initialize / Py_Finalize, but there are the drawbacks already mentioned. Another possibility is using sub-interpreters. 

If either of these could be fixed for extension modules (possibly with unloading the shared objects / DLL's :) ) I'd be fine.

I completely understand your point about backporting and it is not an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Thu Aug  2 05:21:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 09:21:28 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1533201688.59.0.56676864532.issue1230540@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Would it be possible to modify the default implementation of sys.excepthook to have a different output when it's not called from the main thread? Mimick the current traceback from threads.

Would it be possible to call threading.current_thread() from the default sys.excepthook? The problem is to get the threading module and to decide how to handle error on getting the current thread.

An alternative would be to introduce a new hook to log exceptions in threads, ex: sys.threadexcepthook. That hoook would take a 4th parameter. But Andrey Vlasovskikh didn't like this idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Thu Aug  2 05:24:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 09:24:17 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533201857.72.0.56676864532.issue33695@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

When I worked on the os.scandir() implementation, I recall that an interesting test was NFS. Depending on the configuration, stat() in a network filesystem can be between very slow and slow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Thu Aug  2 05:46:59 2018
From: report at bugs.python.org (Nikolaus Rath)
Date: Thu, 02 Aug 2018 09:46:59 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1533203219.2.0.56676864532.issue1230540@psf.upfronthosting.co.za>


Change by Nikolaus Rath <Nikolaus at rath.org>:


----------
nosy:  -nikratio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:02:33 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:02:33 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533204153.25.0.56676864532.issue30317@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

New failure on x86 Windows7 3.x:

https://buildbot.python.org/all/#/builders/58/builds/1174

test_timeout (test.test_multiprocessing_spawn.WithThreadsTestSemaphore) ... skipped 'test not appropriate for threads'
test test_multiprocessing_spawn failed
test_import (test.test_multiprocessing_spawn._TestImportStar) ... ok
======================================================================
FAIL: test_timeout (test.test_multiprocessing_spawn.WithProcessesTestQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 1044, in test_timeout
    self.assertGreaterEqual(delta, 0.150)
AssertionError: 0.13579845428466797 not greater than or equal to 0.15
----------------------------------------------------------------------
Ran 311 tests in 495.714s
FAILED (failures=1, skipped=37)
1 test failed again:
    test_multiprocessing_spawn
== Tests result: FAILURE then FAILURE ==

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:03:37 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:03:37 +0000
Subject: [issue34292] test_compile hangs in AMD Ubuntu buildbots
In-Reply-To: <1533041303.96.0.56676864532.issue34292@psf.upfronthosting.co.za>
Message-ID: <1533204217.46.0.56676864532.issue34292@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

New failure on AMD64 Ubuntu 3.x:

https://buildbot.python.org/all/#/builders/154/builds/100

test_single_statement (test.test_compile.TestSpecifics) ... ok
Timeout (0:15:00)!
Thread 0x00007f30435d3080 (most recent call first):
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/test_compile.py", line 671 in test_stack_overflow
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/case.py", line 615 in run
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/case.py", line 663 in __call__
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/support/__init__.py", line 1883 in _run_suite
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/support/__init__.py", line 1973 in run_unittest
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/runtest.py", line 175 in test_runner
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/runtest.py", line 179 in runtest_inner
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 286 in rerun_failed_tests
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 570 in _main
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 531 in main
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 584 in main
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/runpy.py", line 193 in _run_module_as_main
make: *** [buildbottest] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34292>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:06:12 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:06:12 +0000
Subject: [issue34177] test_site fails in macOS-PR VSTS builds for 3.7 branch
In-Reply-To: <1532158324.8.0.56676864532.issue34177@psf.upfronthosting.co.za>
Message-ID: <1533204372.15.0.56676864532.issue34177@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This error is happening in the x86-64 High Sierra 3.7 buildbot:

https://buildbot.python.org/all/#/builders/147/builds/174

======================================================================
FAIL: test_startup_imports (test.test_site.StartupImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.7.billenstein-sierra/build/Lib/test/test_site.py", line 487, in test_startup_imports
    self.assertFalse(modules.intersection(collection_mods), stderr)
AssertionError: {'collections', 'heapq', 'types', 'functools', 'keyword', 'reprlib', 'operator'} is not false : import _frozen_importlib # frozen

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34177>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:06:56 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:06:56 +0000
Subject: [issue34177] test_site fails in macOS-PR VSTS builds for 3.7 branch
In-Reply-To: <1532158324.8.0.56676864532.issue34177@psf.upfronthosting.co.za>
Message-ID: <1533204416.82.0.56676864532.issue34177@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34177>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:11:39 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:11:39 +0000
Subject: [issue34316] test_socket timeouts in AMD64 Windows10 3.x buildbots
Message-ID: <1533204699.35.0.56676864532.issue34316@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Some tests in test_socket and test_asyncio are receiving timeouts in AMD64 Windows10 3.x buildbots: 

test_asyncio: https://buildbot.python.org/all/#/builders/3/builds/1192
test_socket: https://buildbot.python.org/all/#/builders/3/builds/1191

Sample error messages:

test_not_implemented (test.test_asyncio.test_events.AbstractEventLoopTests) ... ok
Timeout (0:15:00)!
Thread 0x00001a74 (most recent call first):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\socket.py", line 212 in accept
  File "D:\buildarea\3.x.bolen-windows10\build\lib\socket.py", line 528 in socketpair
  File "D:\buildarea\3.x.bolen-windows10\build\lib\asyncio\selector_events.py", line 113 in _make_self_pipe
  File "D:\buildarea\3.x.bolen-windows10\build\lib\asyncio\selector_events.py", line 66 in __init__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\asyncio\events.py", line 660 in new_event_loop
  File "D:\buildarea\3.x.bolen-windows10\build\lib\asyncio\events.py", line 762 in new_event_loop
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_asyncio\test_events.py", line 3061 in test_not_implemented_async
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 615 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 663 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\runner.py", line 176 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 1883 in _run_suite
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 1973 in run_unittest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 179 in runtest_inner
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\__main__.py", line 2 in <module>
  File "D:\buildarea\3.x.bolen-windows10\build\lib\runpy.py", line 85 in _run_code
  File "D:\buildarea\3.x.bolen-windows10\build\lib\runpy.py", line 193 in _run_module_as_main
program finished with exit code 1
elapsedTime=5350.801000
test_not_implemented_async (test.test_asyncio.test_events.AbstractEventLoopTests) ... 

and 

testTimeoutDefault (test.test_socket.NetworkConnectionAttributesTest) ... ok
Unhandled exception in thread started by <bound method ThreadableTest.clientRun of <test.test_socket.NetworkConnectionAttributesTest testMethod=testTimeoutNone>>
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_socket.py", line 336, in clientRun
    self.clientTearDown()
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_socket.py", line 4752, in clientTearDown
    self.cli.close()
AttributeError: 'NetworkConnectionAttributesTest' object has no attribute 'cli'
Timeout (0:15:00)!
Thread 0x0000184c (most recent call first):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\socket.py", line 212 in accept
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_socket.py", line 4757 in _justAccept
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 615 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\case.py", line 663 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 122 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\buildarea\3.x.bolen-windows10\build\lib\unittest\runner.py", line 176 in run
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 1883 in _run_suite
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\support\__init__.py", line 1973 in run_unittest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\test_socket.py", line 6032 in test_main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 179 in runtest_inner
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\buildarea\3.x.bolen-windows10\build\lib\test\__main__.py", line 2 in <module>
  File "D:\buildarea\3.x.bolen-windows10\build\lib\runpy.py", line 85 in _run_code
  File "D:\buildarea\3.x.bolen-windows10\build\lib\runpy.py", line 193 in _run_module_as_main
program finished with exit code 1
elapsedTime=4059.474000

----------
components: Tests
messages: 322937
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_socket timeouts in AMD64 Windows10 3.x buildbots
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34316>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:11:55 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:11:55 +0000
Subject: [issue34316] test_socket and test_asyncio timeouts in AMD64 Windows10
 3.x buildbots
In-Reply-To: <1533204699.35.0.56676864532.issue34316@psf.upfronthosting.co.za>
Message-ID: <1533204715.31.0.56676864532.issue34316@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
title: test_socket timeouts in AMD64 Windows10 3.x buildbots -> test_socket and test_asyncio timeouts in AMD64 Windows10 3.x buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34316>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:13:50 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:13:50 +0000
Subject: [issue34316] test_socket and test_asyncio timeouts in AMD64 Windows10
 3.x buildbots
In-Reply-To: <1533204699.35.0.56676864532.issue34316@psf.upfronthosting.co.za>
Message-ID: <1533204830.06.0.56676864532.issue34316@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Is possible that this are two separate issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34316>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:14:37 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 10:14:37 +0000
Subject: [issue34292] test_compile hangs in AMD Ubuntu buildbots
In-Reply-To: <1533041303.96.0.56676864532.issue34292@psf.upfronthosting.co.za>
Message-ID: <1533204877.12.0.56676864532.issue34292@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

New failure on AMD64 Ubuntu 3.7:

test_single_statement (test.test_compile.TestSpecifics) ... ok
Timeout (0:15:00)!
Thread 0x00007f5f41d9e080 (most recent call first):
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/test_compile.py", line 671 in test_stack_overflow
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/case.py", line 615 in run
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/case.py", line 663 in __call__
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/support/__init__.py", line 1882 in _run_suite
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/support/__init__.py", line 1972 in run_unittest
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/runtest.py", line 175 in test_runner
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/runtest.py", line 179 in runtest_inner
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 286 in rerun_failed_tests
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 570 in _main
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 531 in main
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/libregrtest/main.py", line 584 in main
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/home/buildbot/buildarea/3.7.einat-ubuntu/build/Lib/runpy.py", line 193 in _run_module_as_main
make: *** [buildbottest] Error 1
test_stack_overflow (test.test_compile.TestSpecifics) ... Makefile:1096: recipe for target 'buildbottest' failed
program finished with exit code 2
elapsedTime=6544.321095

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34292>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:15:21 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 02 Aug 2018 10:15:21 +0000
Subject: [issue34177] test_site fails in macOS-PR VSTS builds for 3.7 branch
In-Reply-To: <1532158324.8.0.56676864532.issue34177@psf.upfronthosting.co.za>
Message-ID: <1533204921.24.0.56676864532.issue34177@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Same fix can be applied to buildbot.

This is caused by (a) Homebrew installs Python to /usr/local with (hacky) sitecustomize, and (b) Python's default prefix is /usr/local.

I think test should be run without conflicting with another installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34177>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:18:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 10:18:32 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533205112.2.0.56676864532.issue30317@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8126

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:37:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 10:37:28 +0000
Subject: [issue34177] test_site fails in macOS-PR VSTS builds for 3.7 branch
In-Reply-To: <1532158324.8.0.56676864532.issue34177@psf.upfronthosting.co.za>
Message-ID: <1533206248.38.0.56676864532.issue34177@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

>  Same fix can be applied to buildbot.

Sure. Go ahead :-) The buildbot configuration can be found at:
https://github.com/python/buildmaster-config/

Send a pull request, and Zachary Ware (or me) will  review it. Zach is the expert here ;-)

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34177>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:51:22 2018
From: report at bugs.python.org (desbma)
Date: Thu, 02 Aug 2018 10:51:22 +0000
Subject: [issue24564] shutil.copytree fails when copying NFS to NFS
In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za>
Message-ID: <1533207082.75.0.56676864532.issue24564@psf.upfronthosting.co.za>


desbma <dutch109 at gmail.com> added the comment:

> Since the `copy_function` is customizable to switch between `copy` and `copy2`, making copystat optional on files, perhaps the `copystat` should be optional on directories, as well.

Related: https://bugs.python.org/issue32073

----------
nosy: +desbma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24564>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:53:05 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 02 Aug 2018 10:53:05 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533207185.58.0.56676864532.issue34309@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

PEP 489 (Multi-phase extension module initialization) makes it possible/easy to unload/reimport extension modules, in the sense of destroying/recreating the module object. The problem is that the modules needs to opt-in to supporting this, which is not always easy (e.g. the module needs to not use C globals, or use them carefully), and sometimes it's still nearly impossible (see the in-progress PEP 573).

Unloading the actual shared library is another matter, though. That's not currently planned. There's no good way to ensure that there no remaining objects that could reference the shared library's code.
Instead, your best bet is probably to name the new .so/DLL differently, and load an extra copy. (PEP 489 makes it possible to make the .so/DLL contain a module with a different name.) If you do go this way, I'd welcome feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Thu Aug  2 06:53:50 2018
From: report at bugs.python.org (sakamoto aya)
Date: Thu, 02 Aug 2018 10:53:50 +0000
Subject: [issue34317] Improve docstring   Environment variables in Windows NT
Message-ID: <1533207230.71.0.56676864532.issue34317@psf.upfronthosting.co.za>


New submission from sakamoto aya <aya.sakamoto at outlook.com>:

Expired link in windows.rst:  
https://support.microsoft.com/en-us/help/100843/environment-variables-in-windows-nt

May I make a suggestion?

The new link:https://www.microsoft.com/en-us/wdsi/help/folder-variables

----------
assignee: docs at python
components: Documentation
messages: 322944
nosy: HiyashiChuka, docs at python
priority: normal
severity: normal
status: open
title: Improve docstring   Environment variables in Windows NT
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:00:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Aug 2018 11:00:07 +0000
Subject: [issue34317] Improve docstring   Environment variables in Windows NT
In-Reply-To: <1533207230.71.0.56676864532.issue34317@psf.upfronthosting.co.za>
Message-ID: <1533207607.16.0.56676864532.issue34317@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8127
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:14:57 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 02 Aug 2018 11:14:57 +0000
Subject: [issue34287] bufferedio.c uses unused argument of METH_NOARGS
 functions
In-Reply-To: <1533020863.81.0.56676864532.issue34287@psf.upfronthosting.co.za>
Message-ID: <1533208497.45.0.56676864532.issue34287@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset fc512e3e0663f7f325862fcd42aef765fd34a453 by INADA Naoki (jdemeyer) in branch 'master':
bpo-34287: Do not use second argument of METH_NOARGS functions (GH-8582)
https://github.com/python/cpython/commit/fc512e3e0663f7f325862fcd42aef765fd34a453


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34287>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:15:25 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 02 Aug 2018 11:15:25 +0000
Subject: [issue34287] bufferedio.c uses unused argument of METH_NOARGS
 functions
In-Reply-To: <1533020863.81.0.56676864532.issue34287@psf.upfronthosting.co.za>
Message-ID: <1533208525.93.0.56676864532.issue34287@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34287>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:39:54 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 11:39:54 +0000
Subject: [issue34318] Convert deprecated behavior of assertRaises() etc into
 errors
Message-ID: <1533209994.63.0.56676864532.issue34318@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently assertRaises(), assertRaisesRegex(), assertWarns() and assertWarnsRegex() have some weird behavior.

    # always success if the callable is None
    self.assertRaises(SomeException, None)

    # keyword arguments except "msg" are ignored
    with self.assertRaises(SomeException, foobar=123):
        ...

    # always success because keyword arguments are ignored
    self.assertRaises(SomeException, callable=func)

Hardly any user code uses these "features" intentionally. More likely such examples are hidden bugs (see for example [1]). A DeprecationWarning is raised in these cases since 3.5 (issue24134), and it is time to make them errors.

[1] https://mail.python.org/pipermail/python-list/2018-July/736363.html

----------
components: Tests
messages: 322946
nosy: ezio.melotti, michael.foord, rbcollins, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Convert deprecated behavior of assertRaises() etc into errors
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34318>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:40:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 11:40:18 +0000
Subject: [issue34318] Convert deprecated behavior of assertRaises() etc into
 errors
In-Reply-To: <1533209994.63.0.56676864532.issue34318@psf.upfronthosting.co.za>
Message-ID: <1533210018.09.0.56676864532.issue34318@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34318>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:48:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 11:48:50 +0000
Subject: [issue34318] Convert deprecated behavior of assertRaises() etc into
 errors
In-Reply-To: <1533209994.63.0.56676864532.issue34318@psf.upfronthosting.co.za>
Message-ID: <1533210530.47.0.56676864532.issue34318@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8128
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34318>
_______________________________________

From report at bugs.python.org  Thu Aug  2 07:52:33 2018
From: report at bugs.python.org (Thomas Nyberg)
Date: Thu, 02 Aug 2018 11:52:33 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
Message-ID: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>


New submission from Thomas Nyberg <tomnyberg at gmail.com>:

This came out of the following posts:

https://mail.python.org/pipermail/python-ideas/2018-August/052549.html
https://mail.python.org/pipermail/python-ideas/2018-August/052553.html

Basically my request would be to change the documentation here:

https://docs.python.org/3.7/library/pathlib.html#pathlib.Path.read_text

I would like to add a note that the underlying file object itself is closed after the read_text() method is called. Maybe I'm just a little dense and it should be obvious that the functionality here would be different than open("filepath").read(), but given that thread I linked, I don't believe I'm the only one.

----------
assignee: docs at python
components: Documentation
messages: 322947
nosy: docs at python, thomas.nyberg
priority: normal
severity: normal
status: open
title: Clarify pathlib.Path("filepath").read_text()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Thu Aug  2 08:09:57 2018
From: report at bugs.python.org (Fantix King)
Date: Thu, 02 Aug 2018 12:09:57 +0000
Subject: [issue33062] ssl_renegotiate() doesn't seem to be exposed
In-Reply-To: <1520893582.26.0.467229070634.issue33062@psf.upfronthosting.co.za>
Message-ID: <1533211797.86.0.56676864532.issue33062@psf.upfronthosting.co.za>


Change by Fantix King <fantix.king at gmail.com>:


----------
nosy: +fantix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33062>
_______________________________________

From report at bugs.python.org  Thu Aug  2 08:28:44 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Aug 2018 12:28:44 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533212924.15.0.56676864532.issue34319@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Thu Aug  2 08:49:52 2018
From: report at bugs.python.org (Roy Belio)
Date: Thu, 02 Aug 2018 12:49:52 +0000
Subject: [issue31710] setup.py: _ctypes won't getbuilt when system ffi is only
 in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533214192.78.0.56676864532.issue31710@psf.upfronthosting.co.za>


Roy Belio <rbelio at infinidat.com> added the comment:

Also happens on suse 11 x86_64 with python 3.7
Same issue exactly building locally (but with cross compiling flag for system independency)
Building our own libffi 3.2.1 and adding it in the CPPFLAGS includes.

----------
nosy: +rbelio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:04:56 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 13:04:56 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533215096.55.0.56676864532.issue34097@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a2fe1e52eb94c41d9ebce1ab284180d7b1faa2a4 by Victor Stinner (Marcel Plch) in branch 'master':
bpo-34097: Add support for zipping files older than 1980-01-01 (GH-8270)
https://github.com/python/cpython/commit/a2fe1e52eb94c41d9ebce1ab284180d7b1faa2a4


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:05:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 13:05:41 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533215141.36.0.56676864532.issue34097@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thank you Petr Viktorin for the bug report and thanks to Marcel Plch for the implementation of the new strict_timestamps keyword-only parameter!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:12:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 13:12:23 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
Message-ID: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

>>> from collections import OrderedDict
>>> od = OrderedDict([('a', 1), ('b', 2)])
>>> od.move_to_end('a')
>>> od
OrderedDict([('b', 2), ('a', 1)])
>>> dict(od)
{'a': 1, 'b': 2}

This affects also PEP 468.

>>> def f(**kwargs): return kwargs
... 
>>> f(**od)
{'a': 1, 'b': 2}

And PEP 520.

>>> type('A', (), od).__dict__
mappingproxy({'a': 1, 'b': 2, '__module__': '__main__', '__dict__': <attribute '__dict__' of 'A' objects>, '__weakref__': <attribute '__weakref__' of 'A' objects>, '__doc__': None})

----------
components: Interpreter Core
messages: 322951
nosy: Rosuav, eric.snow, inada.naoki, rhettinger, serhiy.storchaka, steve.dower
priority: normal
severity: normal
status: open
title: Creating dict from OrderedDict doesn't preserve order
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:19:23 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Thu, 02 Aug 2018 13:19:23 +0000
Subject: [issue31710] setup.py: _ctypes won't getbuilt when system ffi is only
 in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533215963.34.0.56676864532.issue31710@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Hi Roy, mind sharing the complete build log? Either attaching the log to this issue or pasting a link is fine.

----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:22:03 2018
From: report at bugs.python.org (Manuel)
Date: Thu, 02 Aug 2018 13:22:03 +0000
Subject: [issue34321] mmap.mmap() should not necessarily clone the file
 descriptor
Message-ID: <1533216123.68.0.56676864532.issue34321@psf.upfronthosting.co.za>


New submission from Manuel <manuel.schoelling at gmx.de>:

mmap.mmap(fileno, length, flags, prot, access, offset) always clones the file descriptor that should be used [1].

The cloning of the file descriptor seems to be done to ensure that the file cannot be closed behind mmap's back, but if you are mmap()'ing a lot of memory regions of a file this can cause a 'Too many open files' error.

I would suggest to add an option to mmap.mmap() that tells it not to clone the file descriptor. This can cause an issue if the file is closed before accessing the mmapped region, so this fact should also be pointed out in the documentation.

[1] https://github.com/python/cpython/blob/master/Modules/mmapmodule.c#L1159

----------
components: Library (Lib)
messages: 322953
nosy: manuels
priority: normal
severity: normal
status: open
title: mmap.mmap() should not necessarily clone the file descriptor
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34321>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:23:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 13:23:00 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533216180.11.0.56676864532.issue34097@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If add a new option, I prefer to add it to the ZipFile constructor, similarly to allowZip64. Initially allowZip64 was False by default, because not all third-party tools supported ZIP64 extension. Later the default was changed to True, but you still can force raising an error if the archive is not compatible with old tools. I think the same policy should be applied here. Add the ability of writing date before 1980, and add an option for raising an error for date before 1980.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:28:47 2018
From: report at bugs.python.org (ppperry)
Date: Thu, 02 Aug 2018 13:28:47 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533216527.24.0.56676864532.issue31710@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: setup.py: _ctypes won't getbuilt when system ffi is only in $PREFIX -> setup.py: _ctypes won't get built when system ffi is only in $PREFIX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:36:05 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 02 Aug 2018 13:36:05 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1533216965.44.0.56676864532.issue34320@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +8129
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Thu Aug  2 09:51:46 2018
From: report at bugs.python.org (Roy Belio)
Date: Thu, 02 Aug 2018 13:51:46 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533217906.55.0.56676864532.issue31710@psf.upfronthosting.co.za>


Roy Belio <rbelio at infinidat.com> added the comment:

Sure, I'll attach it. one more thing to mention is that during configure it printed: configure: WARNING: --with(out)-system-ffi is ignored on this platform

We are also providing all the dependency libraries ourselves (building, linking, h files and what not) so that should tkae into consideration.
on Suse 11 x86 build is working fine.
and we are using gcc 4.3.4
configure arguments passed:
--prefix=/root/rc3/dist --enable-shared --enable-ipv6 --with-dbmliborder=gdbm --with-gcc --with-system-ffi --with-openssl=/root/rc3/dist

----------
Added file: https://bugs.python.org/file47728/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:02:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:02:57 +0000
Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za>
Message-ID: <1533218577.42.0.56676864532.issue29565@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8130

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29565>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:02:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:02:57 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1533218577.66.0.665841612001.issue20160@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:05:54 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:05:54 +0000
Subject: [issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64)
 architecture
In-Reply-To: <1489413054.1.0.4012026352.issue29804@psf.upfronthosting.co.za>
Message-ID: <1533218754.27.0.56676864532.issue29804@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

This issue is mentioned from https://bugzilla.redhat.com/show_bug.cgi?id=1336557 but it seems like the bug has not been fixed in Python 2.7.

I created PR 8625 to backport the fix to Python 2.7.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29804>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:23:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:23:24 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533219804.03.0.56676864532.issue34097@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Serhiy:
>  If add a new option, I prefer to add it to the ZipFile constructor, similarly to allowZip64. 

Aha, that would make sense. I'm not sure that it's useful to control the parameter per added file, it's enough to control the parameter per ZIP archive.

Marcel: would you mind to try to move the strict_timestamps parameter  from ZipFile.write() to ZipFile constructor?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:28:26 2018
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Aug 2018 14:28:26 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533220106.95.0.56676864532.issue24255@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Conrad: thanks for the effort, but using f-strings with logging is counterproductive.  The idea behind logging is that the logged strings are not materialized unless something actually wants to output them.  Using fstrings means you are doing all the work of formatting the string regardless of whether or not the string is actually going to get written anywhere.  The original patch also retains the debug guards that minimize overhead when debugging is not turned on, which it doesn't look like your patch does.

Regardless, what we need at this stage is a github PR, not a patch :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:31:18 2018
From: report at bugs.python.org (Michael Schnaitter)
Date: Thu, 02 Aug 2018 14:31:18 +0000
Subject: [issue34322] modification to Lib/distutils/ccompiler.py to simplify
 handling of compile arguments by subclasses
Message-ID: <1533220278.22.0.56676864532.issue34322@psf.upfronthosting.co.za>


New submission from Michael Schnaitter <schnaitterm at knights.ucf.edu>:

Discussion on details in the referenced PR is needed.

----------
components: Library (Lib)
messages: 322959
nosy: schnaitterm
priority: normal
pull_requests: 8132
severity: normal
status: open
title: modification to Lib/distutils/ccompiler.py to simplify handling of compile arguments by subclasses
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34322>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:31:42 2018
From: report at bugs.python.org (Marcel Plch)
Date: Thu, 02 Aug 2018 14:31:42 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533220302.17.0.56676864532.issue34097@psf.upfronthosting.co.za>


Marcel Plch <gmarcel.plch at gmail.com> added the comment:

It seems reasonable, I'll have a look at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:35:40 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Thu, 02 Aug 2018 14:35:40 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533220540.41.0.56676864532.issue31710@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

A possible case might be that pkg-config on your build machine is not properly configured. Could you check the value of LIBFFI_INCLUDEDIR in config.log? It shuold either be an empty string or /root/rc3/dist/lib/libffi-3.2.1/include.

As a reference, the following command is used to compute LIBFFI_INCLUDEDIR: https://github.com/python/cpython/blob/v3.7.0/configure.ac#L2936

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:35:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 14:35:55 +0000
Subject: [issue34322] modification to Lib/distutils/ccompiler.py to simplify
 handling of compile arguments by subclasses
In-Reply-To: <1533220278.22.0.56676864532.issue34322@psf.upfronthosting.co.za>
Message-ID: <1533220555.46.0.56676864532.issue34322@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +dstufft, eric.araujo
stage:  -> patch review
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34322>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:36:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2018 14:36:11 +0000
Subject: [issue34322] modification to Lib/distutils/ccompiler.py to simplify
 handling of compile arguments by subclasses
In-Reply-To: <1533220278.22.0.56676864532.issue34322@psf.upfronthosting.co.za>
Message-ID: <1533220571.23.0.56676864532.issue34322@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34322>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:47:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:47:30 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1533221250.54.0.56676864532.issue20160@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 3243f8c1fb16b6de73f1d7a30f5d09047553bce3 by Victor Stinner in branch '2.7':
bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64 (GH-168) (GH-8625)
https://github.com/python/cpython/commit/3243f8c1fb16b6de73f1d7a30f5d09047553bce3


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:47:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:47:31 +0000
Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za>
Message-ID: <1533221251.04.0.902498594338.issue29565@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 3243f8c1fb16b6de73f1d7a30f5d09047553bce3 by Victor Stinner in branch '2.7':
bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64 (GH-168) (GH-8625)
https://github.com/python/cpython/commit/3243f8c1fb16b6de73f1d7a30f5d09047553bce3


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29565>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:48:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:48:27 +0000
Subject: [issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64)
 architecture
In-Reply-To: <1489413054.1.0.4012026352.issue29804@psf.upfronthosting.co.za>
Message-ID: <1533221307.62.0.56676864532.issue29804@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

New changeset 3243f8c1fb16b6de73f1d7a30f5d09047553bce3 by Victor Stinner in branch '2.7':
bpo-29565: Corrected ctypes passing of large structs by value on Windows AMD64 (GH-168) (GH-8625)
https://github.com/python/cpython/commit/3243f8c1fb16b6de73f1d7a30f5d09047553bce3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29804>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:49:24 2018
From: report at bugs.python.org (Roy Belio)
Date: Thu, 02 Aug 2018 14:49:24 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533221364.69.0.56676864532.issue31710@psf.upfronthosting.co.za>


Roy Belio <rbelio at infinidat.com> added the comment:

as seen in the config.log:
LIBFFI_INCLUDEDIR='/root/rc3/dist/lib/libffi-3.2.1/include'

I'm attaching the config.log just in case

----------
Added file: https://bugs.python.org/file47729/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 10:49:59 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 14:49:59 +0000
Subject: [issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64)
 architecture
In-Reply-To: <1489413054.1.0.4012026352.issue29804@psf.upfronthosting.co.za>
Message-ID: <1533221399.57.0.56676864532.issue29804@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I backported commit a86339b83fbd0932e0529a3c91935e997a234582 from master: commit 3243f8c1fb16b6de73f1d7a30f5d09047553bce3, but I don't have access to arm64, so I cannot test if the backport fixes test_ctypes on arm64.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29804>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:08:05 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Thu, 02 Aug 2018 15:08:05 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1533222485.17.0.56676864532.issue31710@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Thanks for providing the info. However, I'm sorry as the case is beyond my knowledge. Here's the relevant section in CPython that handles LIBFFI path searching: https://github.com/python/cpython/blob/v3.7.0/setup.py#L1984-L2002. You may want to examine variables there to see if there's something unusual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:12:59 2018
From: report at bugs.python.org (Eryn Wells)
Date: Thu, 02 Aug 2018 15:12:59 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533222779.67.0.56676864532.issue24255@psf.upfronthosting.co.za>


Eryn Wells <eryn at erynwells.me> added the comment:

Hi, it sounds like my original patch is the preferred approach. I can put up a GitHub PR for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:20:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 15:20:21 +0000
Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za>
Message-ID: <1533223221.86.0.56676864532.issue29565@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8133

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29565>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:25:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 15:25:31 +0000
Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za>
Message-ID: <1533223531.73.0.56676864532.issue29565@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum, the compilation succeeded on AppVeyor:
https://ci.appveyor.com/project/python/cpython/build/2.7build20258

But it fails on AMD64 Windows8 2.7:
https://buildbot.python.org/all/#/builders/74/builds/194

It seems like this buildbot uses Visual Studio 2008 ("VS 9.0")... but it seems like AppVeyor also uses Visual Studio 2008. No idea why AppVeyor missed the compilation error :-(

Anyway, I proposed PR 8626 to fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29565>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:38:11 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 02 Aug 2018 15:38:11 +0000
Subject: [issue34309] Embedding Python; Py_Initialize / Py_Finalize cycles
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533224291.69.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@chris, I can't promise that anything will happen right away, but I'll be sure to look into this further when I work on improving extension module usage in subinterpreters in the next few months.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:40:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 15:40:23 +0000
Subject: [issue29565] Still broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1487152114.39.0.2484958241.issue29565@psf.upfronthosting.co.za>
Message-ID: <1533224423.06.0.56676864532.issue29565@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 6a6b2483479a1ad0ab82300452f0ce71fa90b2d7 by Victor Stinner in branch '2.7':
bpo-29565: Fix compilation for C89 (GH-8626)
https://github.com/python/cpython/commit/6a6b2483479a1ad0ab82300452f0ce71fa90b2d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29565>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:56:19 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 02 Aug 2018 15:56:19 +0000
Subject: [issue34309] Trouble when reloading extension modules.
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533225379.33.0.56676864532.issue34309@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I've changed the issue title to reflect where things stand.

Hmm, doing so reminded me of an important consideration here.  A module object is effectively a fairly light wrapper around a dict.  When you call importlib.reload() the loader from the module's spec is used to re-execute the module's existing dict. [1][2]  A new module is not created and the existing module namespace is not reset.  So during reload the module is responsible for deleting anything in its namespace that wouldn't get replaced when re-executed (including attributes that were added to the namespace externally).  For most modules this isn't an issue.  However, it's something to consider when reloading a module.  See the docs for more explanation and caveats. [3]

[1] https://github.com/python/cpython/blob/master/Lib/importlib/__init__.py#L169
[2] https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py#L610
[3] https://docs.python.org/3/library/importlib.html#importlib.reload

----------
title: Embedding Python; Py_Initialize / Py_Finalize cycles -> Trouble when reloading extension modules.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Thu Aug  2 11:57:41 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 15:57:41 +0000
Subject: [issue30984] traceback.print_exc return value documentation
In-Reply-To: <1500651170.07.0.787106480078.issue30984@psf.upfronthosting.co.za>
Message-ID: <1533225461.33.0.56676864532.issue30984@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The documentation you've quoted is for traceback.extract_tb(). traceback.format_tb() documentation only says:

    A shorthand for ``format_list(extract_tb(tb, limit))``.

Issue 27910 is about updating the documentation of extract_tb(), format_list(), and StackSummary.from_list().

I'm closing this as a duplicate of issue 27910.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Doc/library/traceback.rst ? references to tuples should be replaced with new FrameSummary object
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30984>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:09:02 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 16:09:02 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1533226142.61.0.56676864532.issue27910@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset f394ee5eaf6d6d8f45e0478e77d4dbff25c6bea7 by Berker Peksag (torsava) in branch 'master':
bpo-27910: Update documentation of traceback module (GH-6116)
https://github.com/python/cpython/commit/f394ee5eaf6d6d8f45e0478e77d4dbff25c6bea7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:09:24 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 16:09:24 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1533226164.81.0.56676864532.issue27910@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8134

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:10:20 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Aug 2018 16:10:20 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533226220.0.0.56676864532.issue33695@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Yes, file copy (open() + read() + write()) is of course more expensive than just "reading" a tree (os.walk(), glob()) or deleting it (rmtree()) and the "pure file copy" time adds up to the benchmark. And indeed it's not an coincidence that #33671 (which replaced read() + write() with sendfile()) shaved off a 5% gain from the benchmark I posted initially for Linux.

Still, in a 8k small-files-tree scenario we're seeing ~9% gain on Linux, 20% on Windows and 30% on a SMB share on localhost vs. VirtualBox. I do not consider this a "hardly noticeable gain" as you imply: it is noticeable, exponential and measurable, even with cache being involved (as it is). 

Note that the number of stat() syscalls per file is being reduced from 6 to 1 (or more if follow_symlinks=False), and that is the real gist here. That *does* make a difference on a regular Windows fs and makes a huge difference with network filesystems in general, as a simple stat() call implies access to the network, not the disk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:10:20 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 02 Aug 2018 16:10:20 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1533226220.35.0.56676864532.issue27910@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8135

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:15:46 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Aug 2018 16:15:46 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533226546.17.0.56676864532.issue34313@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Kevin, more tk mac issues.

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:16:06 2018
From: report at bugs.python.org (Eryn Wells)
Date: Thu, 02 Aug 2018 16:16:06 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533226566.03.0.56676864532.issue24255@psf.upfronthosting.co.za>


Eryn Wells <eryn at erynwells.me> added the comment:

Actually, I spoke too soon. My current employer isn't too keen on us contributing to open source, so I can't do this. Sorry!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:22:14 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 02 Aug 2018 16:22:14 +0000
Subject: [issue34309] Trouble when reloading extension modules.
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533226934.05.0.56676864532.issue34309@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

a) Probably not something to fix in released versions any more, so increasing version from 3.5 to 3.8.

b) Regarding shared library unloading and the problems mentioned, I'm also not sure if there is a way to safely unload transitively imported libraries, e.g. if the extension module is a wrapper for an external C library (which then might come with its own dependencies again, which might still be in use by other extension modules, etc.).

----------
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:25:22 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Aug 2018 16:25:22 +0000
Subject: [issue33782] VSTS Windows-PR: internal error
In-Reply-To: <1528283564.84.0.592728768989.issue33782@psf.upfronthosting.co.za>
Message-ID: <1533227122.13.0.56676864532.issue33782@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A quick follow-up commit can happen if one uses the web editor to edit more than one file.

Editing a news file in Misc/News/next should not trigger any of the normal tests, only a blurb check if there is such.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33782>
_______________________________________

From report at bugs.python.org  Thu Aug  2 12:51:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 16:51:51 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1533228711.89.0.56676864532.issue27910@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 0f9df886d6d1c6b239a2861a0ad0d56bb59e3922 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-27910: Update documentation of traceback module (GH-6116)
https://github.com/python/cpython/commit/0f9df886d6d1c6b239a2861a0ad0d56bb59e3922


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:01:00 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 17:01:00 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1533229260.77.0.56676864532.issue27910@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 295342adbfd905d5b4a77f960ea39649df7d9997 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-27910: Update documentation of traceback module (GH-6116)
https://github.com/python/cpython/commit/295342adbfd905d5b4a77f960ea39649df7d9997


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:01:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 17:01:18 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533229278.55.0.56676864532.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8136

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:01:28 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 17:01:28 +0000
Subject: =?utf-8?q?=5Bissue27910=5D_Doc/library/traceback=2Erst_=E2=80=94_referenc?=
 =?utf-8?q?es_to_tuples_should_be_replaced_with_new_FrameSummary_object?=
In-Reply-To: <1472637889.08.0.384463773035.issue27910@psf.upfronthosting.co.za>
Message-ID: <1533229287.99.0.56676864532.issue27910@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27910>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:34:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 02 Aug 2018 17:34:23 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533231263.16.0.56676864532.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 72ec3193b5118a2ccc8be8bf03d7b74691c6a264 by Victor Stinner in branch 'master':
bpo-34170: Cleanup pymain_run_filename() (GH-8631)
https://github.com/python/cpython/commit/72ec3193b5118a2ccc8be8bf03d7b74691c6a264


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:46:01 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 02 Aug 2018 17:46:01 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533231961.43.0.56676864532.issue24255@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

That's okay Eryn. We really appreciate all your help.

I will take this patch forward :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:46:45 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 17:46:45 +0000
Subject: [issue26502] traceback.extract_tb breaks compatibility by returning
 FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1533232005.17.0.56676864532.issue26502@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8137
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26502>
_______________________________________

From report at bugs.python.org  Thu Aug  2 13:54:06 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 17:54:06 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1533232446.34.0.56676864532.issue25573@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:02:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 02 Aug 2018 18:02:38 +0000
Subject: [issue33695] Have shutil.copytree(),
 copy() and copystat() use cached scandir() stat()s
In-Reply-To: <1527682955.69.0.682650639539.issue33695@psf.upfronthosting.co.za>
Message-ID: <1533232958.07.0.56676864532.issue33695@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Depending on the configuration, stat() in a network filesystem can be between very slow and slow.

+1.  I also quickly glanced over the patch and I think it looks like a clear win.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33695>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:08:18 2018
From: report at bugs.python.org (Conrad Ho)
Date: Thu, 02 Aug 2018 18:08:18 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533233298.46.0.56676864532.issue24255@psf.upfronthosting.co.za>


Conrad Ho <conrad.alwin.ho at gmail.com> added the comment:

Thanks Eryn!

@Sanyam if you apply the original patch directly that will currently result in some merge failures, and there are test fixes etc that I did on the second patch. Think we should combine them.

I just made the chgs suggested by David on my own forked repo. Do you want me to submit a PR directly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:15:11 2018
From: report at bugs.python.org (Conrad Ho)
Date: Thu, 02 Aug 2018 18:15:11 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533233711.57.0.56676864532.issue24255@psf.upfronthosting.co.za>


Conrad Ho <conrad.alwin.ho at gmail.com> added the comment:

@Eryn in the news blurb thing I'm going to say
"original patch done by Eryn Wells." Your employer should be okay with that right? :D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:25:13 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 02 Aug 2018 18:25:13 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533234313.28.0.56676864532.issue24255@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +8138
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:34:18 2018
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 02 Aug 2018 18:34:18 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533234858.64.0.56676864532.issue34105@psf.upfronthosting.co.za>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Is this expected behaviour, should the tests be changes, or is it a bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:37:19 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 18:37:19 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533235039.42.0.56676864532.issue18540@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Thu Aug  2 14:50:45 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 18:50:45 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533235845.06.0.56676864532.issue34105@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Thu Aug  2 15:00:20 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 02 Aug 2018 19:00:20 +0000
Subject: [issue28940] __length_hint__ isn't a hint for list()
In-Reply-To: <1481489596.88.0.223371500433.issue28940@psf.upfronthosting.co.za>
Message-ID: <1533236420.26.0.56676864532.issue28940@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +8140
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28940>
_______________________________________

From report at bugs.python.org  Thu Aug  2 15:01:33 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Aug 2018 19:01:33 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533236493.27.0.56676864532.issue34312@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Teammate of mine tripped up against this because he tried to use a list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Thu Aug  2 15:04:22 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 02 Aug 2018 19:04:22 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533236662.14.0.56676864532.issue24255@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Sure Conrad,

Yeah, indeed. The patch didn't apply cleanly, so I"ve done it manually.

I've raised the PR here: https://github.com/python/cpython/pull/8633

I'll check your patch and merge :)

Thanks for your help too!

I'm adding Python 3.7 and Python 3.8 for this patch.

----------
stage: patch review -> needs patch
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Thu Aug  2 16:08:49 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 02 Aug 2018 20:08:49 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533240529.39.0.56676864532.issue34105@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is not expected, but I don't know where the problem is.

On my machine I get:

>>> socket.gethostbyname('0.1.1.~1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.gaierror: [Errno 8] nodename nor servname provided, or not known

This is on a machine running 10.13.6:

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65

I'm using a checkout of master of about a week all, and get the same exception with 3.7.0.  I also get the same exception on the current beta of macOS 10.14 (With python 3.7.0)

I'm currently building the current master to check if that changes anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Thu Aug  2 16:11:08 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Aug 2018 20:11:08 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533240668.18.0.56676864532.issue34319@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

How about if we add "The file is opened and then closed." before "The optional parameters have the same meaning as in open()."

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Thu Aug  2 16:12:26 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 02 Aug 2018 20:12:26 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533240746.56.0.56676864532.issue34105@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Note that the test itself has the following comment:

def test_host_resolution_bad_address(self):
        # These are all malformed IP addresses and expected not to resolve to
        # any result.  But some ISPs, e.g. AWS, may successfully resolve these
        # IPs.


Does the following shell command give an error? : host '0.1.1.~1'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Thu Aug  2 16:12:46 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 02 Aug 2018 20:12:46 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533240766.98.0.56676864532.issue34105@psf.upfronthosting.co.za>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Thu Aug  2 16:29:46 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 20:29:46 +0000
Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject
In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za>
Message-ID: <1533241786.39.0.56676864532.issue27419@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The workaround was removed in https://github.com/berkerpeksag/cpython/commit/133138a284be1985ebd9ec9014f1306b9a425d98 Can this issue be closed now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27419>
_______________________________________

From report at bugs.python.org  Thu Aug  2 18:50:13 2018
From: report at bugs.python.org (John Nelson)
Date: Thu, 02 Aug 2018 22:50:13 +0000
Subject: [issue34323] False timeout log message on proactor close
Message-ID: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>


New submission from John Nelson <john at jnelson.ca>:

Repro:
 1. Run the attached script ('repro.py')

Expected output:

2018-07-31 16:39:57,069 - asyncio - DEBUG - Using proactor: IocpProactor
2018-07-31 16:39:57,084 - root - INFO - Starting
2018-07-31 16:39:58,100 - root - INFO - Sleep done
2018-07-31 16:39:58,100 - root - INFO - Loop closed

Actual output:

2018-07-31 16:37:58,583 - asyncio - DEBUG - Using proactor: IocpProactor
2018-07-31 16:37:58,599 - root - INFO - Starting
2018-07-31 16:37:59,614 - root - INFO - Sleep done
2018-07-31 16:37:59,614 - asyncio - DEBUG - taking long time to close proactor
2018-07-31 16:37:59,614 - root - INFO - Loop closed

----------
components: asyncio
files: repro.py
messages: 322994
nosy: asvetlov, johnboy2, yselivanov
priority: normal
severity: normal
status: open
title: False timeout log message on proactor close
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file47730/repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Thu Aug  2 18:55:55 2018
From: report at bugs.python.org (John Nelson)
Date: Thu, 02 Aug 2018 22:55:55 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1533250555.31.0.56676864532.issue34323@psf.upfronthosting.co.za>


John Nelson <john at jnelson.ca> added the comment:

I *suspect* the issue is down to a discrepancy between:
- IocpProactor.close(), and
- IocpProactor._poll()

When the former calls the latter, it seems to be expecting a truth value response from _poll() to indicate that no timeout occurred. However, the latter only ever returns None.

Of note is that `ms != 0` whenever a timeout occurs, potentially giving a simple test point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Thu Aug  2 18:59:21 2018
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 02 Aug 2018 22:59:21 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533250761.93.0.56676864532.issue34105@psf.upfronthosting.co.za>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

When running the terminal command host '0.1.1.~1' I get the following output:

0.1.1.~1 has address 62.138.239.45
0.1.1.~1 has address 62.138.238.45
Host 0.1.1.~1 not found: 3(NXDOMAIN)
Host 0.1.1.~1 not found: 3(NXDOMAIN)

If I ping the above IP address 62.138.239.45, it does not respond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Thu Aug  2 19:19:01 2018
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 02 Aug 2018 23:19:01 +0000
Subject: [issue34324] Doc README wrong directory name for vent
Message-ID: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

In the Doc README there is the following sentence after the make venv command:
Assuming the virtual environment was created in the env directory (the default; configurable with the VENVDIR variable)

Should't it be venv directory instead? In the makefile the VENVDIR variable is set to venv by default.

----------
assignee: docs at python
components: Documentation
messages: 322997
nosy: docs at python, lys.nikolaou
priority: normal
severity: normal
status: open
title: Doc README wrong directory name for vent
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  2 19:19:47 2018
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 02 Aug 2018 23:19:47 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533251987.85.0.56676864532.issue34324@psf.upfronthosting.co.za>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
title: Doc README wrong directory name for vent -> Doc README wrong directory name for venv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  2 19:52:19 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 02 Aug 2018 23:52:19 +0000
Subject: [issue32046] 2to3 fix for operator.isCallable()
In-Reply-To: <1510823372.85.0.213398074469.issue32046@psf.upfronthosting.co.za>
Message-ID: <1533253939.28.0.56676864532.issue32046@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> I suppose stable branches should be left alone?

We do backport lib2to3 PRs to maintenance branches, but since this is already in 3.7 and 3.6 is four months away from being in security-fix-only mode, I think we can close this as 'fixed' now.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32046>
_______________________________________

From report at bugs.python.org  Thu Aug  2 19:52:26 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 23:52:26 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
Message-ID: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_zipfile gets OverflowError in multiple buildbots:

https://buildbot.python.org/all/#/builders/106/builds/1374
https://buildbot.python.org/all/#/builders/106/builds/1375
https://buildbot.python.org/all/#/builders/106/builds/1376

Example error log:


======================================================================
ERROR: test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/ssd/buildbot/buildarea/3.x.gps-ubuntu-exynos5-armv7l/build/Lib/test/test_zipfile.py", line 559, in test_add_file_after_2107
    os.utime(TESTFN, (4386268800, 4386268800))
OverflowError: timestamp out of range for platform time_t
----------------------------------------------------------------------
Ran 208 tests in 39.261s
FAILED (errors=1, skipped=1)
1 test failed again:

----------
components: Tests
messages: 322999
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_zipfile gets OverflowError in multiple buildbots
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Thu Aug  2 19:53:47 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 23:53:47 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533254027.66.0.56676864532.issue34325@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

More failures on x86 Gentoo Installed with X 3.x:

https://buildbot.python.org/all/#/builders/103/builds/1240
https://buildbot.python.org/all/#/builders/103/builds/1241
https://buildbot.python.org/all/#/builders/103/builds/1242

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Thu Aug  2 19:57:08 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Aug 2018 23:57:08 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
Message-ID: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_subprocess.POSIXProcessTestCase fails in AMD64 Ubuntu 3.x buildbots:

https://buildbot.python.org/all/#/builders/154/builds/104

It seems that it has some problems with (unclosed?) file descriptors:

test_terminate_dead (test.test_subprocess.Win32ProcessTestCase) ... skipped 'Windows specific tests'
======================================================================
FAIL: test_close_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/test_subprocess.py", line 2378, in test_close_fds
    "Some fds were left open")
AssertionError: {3} is not false : Some fds were left open
======================================================================
FAIL: test_close_fds_after_preexec (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/test_subprocess.py", line 2653, in test_close_fds_after_preexec
    self.assertNotIn(fd, remaining_fds)
AssertionError: 3 unexpectedly found in {0, 1, 2, 3}
======================================================================
FAIL: test_pass_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/support/__init__.py", line 615, in wrapper
    return func(*args, **kw)
  File "/home/buildbot/buildarea/3.x.einat-ubuntu/build/Lib/test/test_subprocess.py", line 2503, in test_pass_fds
    "fd to be closed passed")
AssertionError: {4} is not false : fd to be closed passed
----------------------------------------------------------------------
Ran 285 tests in 68.129s
FAILED (failures=3, skipped=28)
1 test failed again:
    test_subprocess

----------
components: Tests
messages: 323001
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_subprocess.POSIXProcessTestCase fails in AMD64 Ubuntu 3.x
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:02:22 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 00:02:22 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533254542.52.0.56676864532.issue34326@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This also happens on x86-64 High Sierra 3.x buildbot:

https://buildbot.python.org/all/#/builders/145/builds/265

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:04:10 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 00:04:10 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533254650.63.0.56676864532.issue30317@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Seems the same issue as in:

https://buildbot.python.org/all/#/builders/58/builds/1181

test_fd_transfer (test.test_multiprocessing_spawn.WithThreadsTestConnection) ... skipped 'only makes sense with processes'
Timeout (0:15:00)!
Thread 0x000008d4 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 56 in startTest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 588 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1883 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1973 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 179 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\__main__.py", line 2 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
program finished with exit code 1
elapsedTime=5998.222000
test_large_fd_transfer (test.test_multiprocessing_spawn.WithThreadsTestConnection) ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:05:10 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 00:05:10 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533254710.85.0.56676864532.issue34326@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

More failures on AMD64 Debian PGO 3.x:

https://buildbot.python.org/all/#/builders/47/builds/1362

test_terminate (test.test_subprocess.Win32ProcessTestCase) ... skipped 'Windows specific tests'
test test_subprocess failed
test_terminate_dead (test.test_subprocess.Win32ProcessTestCase) ... skipped 'Windows specific tests'
======================================================================
FAIL: test_close_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_subprocess.py", line 2378, in test_close_fds
    "Some fds were left open")
AssertionError: {3} is not false : Some fds were left open
======================================================================
FAIL: test_close_fds_after_preexec (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_subprocess.py", line 2653, in test_close_fds_after_preexec
    self.assertNotIn(fd, remaining_fds)
AssertionError: 3 unexpectedly found in {0, 1, 2, 3}
======================================================================
FAIL: test_pass_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/support/__init__.py", line 615, in wrapper
    return func(*args, **kw)
  File "/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_subprocess.py", line 2503, in test_pass_fds
    "fd to be closed passed")
AssertionError: {4} is not false : fd to be closed passed
----------------------------------------------------------------------
Ran 285 tests in 27.876s
FAILED (failures=3, skipped=28)
1 test failed again:
    test_subprocess

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:09:05 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 00:09:05 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533254945.04.0.56676864532.issue30317@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 5640d030e100aade54210034828b711c3b506b18 by Pablo Galindo (Victor Stinner) in branch 'master':
bpo-30317: Fix multiprocessing test_timeout() (GH-8621)
https://github.com/python/cpython/commit/5640d030e100aade54210034828b711c3b506b18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:09:40 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 00:09:40 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533254980.0.0.56676864532.issue30317@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8141

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:11:47 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 00:11:47 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533255107.54.0.56676864532.issue30317@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:27:01 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 00:27:01 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533256021.83.0.56676864532.issue30317@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 50d78677899d315c17dc9a14d2f94a013046c71a by Miss Islington (bot) in branch '3.7':
bpo-30317: Fix multiprocessing test_timeout() (GH-8621)
https://github.com/python/cpython/commit/50d78677899d315c17dc9a14d2f94a013046c71a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:55:31 2018
From: report at bugs.python.org (Asher Mancinelli)
Date: Fri, 03 Aug 2018 00:55:31 +0000
Subject: [issue34327] CPython make test crash
Message-ID: <1533257731.89.0.56676864532.issue34327@psf.upfronthosting.co.za>


New submission from Asher Mancinelli <ashermancinelli at gmail.com>:

Cloned master (v3.8) from github. os: Arch x86_64, kernel: 4.14.56-1-lts. successfully ran `./configure --enable-optimizations` and `make`, but failed with this error message when running `make test` 

```
======================================================================
FAIL: test_close_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/asher/sources/cpython3.8/Lib/test/test_subprocess.py", line 2378, in test_close_fds
    "Some fds were left open")
AssertionError: {3} is not false : Some fds were left open

======================================================================
FAIL: test_close_fds_after_preexec (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/asher/sources/cpython3.8/Lib/test/test_subprocess.py", line 2653, in test_close_fds_after_preexec
    self.assertNotIn(fd, remaining_fds)
AssertionError: 3 unexpectedly found in {0, 1, 2, 3}

======================================================================
FAIL: test_pass_fds (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/asher/sources/cpython3.8/Lib/test/support/__init__.py", line 615, in wrapper
    return func(*args, **kw)
  File "/home/asher/sources/cpython3.8/Lib/test/test_subprocess.py", line 2503, in test_pass_fds
    "fd to be closed passed")
AssertionError: {4} is not false : fd to be closed passed

----------------------------------------------------------------------
Ran 285 tests in 23.861s

FAILED (failures=3, skipped=28)
test test_subprocess failed
1 test failed again:
    test_subprocess

== Tests result: FAILURE then FAILURE ==

404 tests OK.

1 test failed:
    test_subprocess

13 tests skipped:
    test_devpoll test_gdb test_kqueue test_msilib test_ossaudiodev
    test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio
    test_winreg test_winsound test_zipfile64

1 re-run test:
    test_subprocess

Total duration: 3 min 59 sec
Tests result: FAILURE then FAILURE
make: *** [Makefile:1058: test] Error 2
```

----------
components: Build
messages: 323007
nosy: ashermancinelli
priority: normal
severity: normal
status: open
title: CPython make test crash
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34327>
_______________________________________

From report at bugs.python.org  Thu Aug  2 20:57:47 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 03 Aug 2018 00:57:47 +0000
Subject: [issue34327] test_subprocess fails
In-Reply-To: <1533257731.89.0.56676864532.issue34327@psf.upfronthosting.co.za>
Message-ID: <1533257867.92.0.56676864532.issue34327@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
components: +Tests -Build
title: CPython make test crash -> test_subprocess fails
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34327>
_______________________________________

From report at bugs.python.org  Thu Aug  2 21:08:11 2018
From: report at bugs.python.org (paul j3)
Date: Fri, 03 Aug 2018 01:08:11 +0000
Subject: [issue34299] argparse description formatting
In-Reply-To: <1533065087.6.0.56676864532.issue34299@psf.upfronthosting.co.za>
Message-ID: <1533258491.19.0.56676864532.issue34299@psf.upfronthosting.co.za>


Change by paul j3 <ajipanca at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34299>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:00:18 2018
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 03 Aug 2018 02:00:18 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533261618.45.0.56676864532.issue34313@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

The crash reported by the OP did show up at times in recent releases of Tk 8.6.x, but a lot of work went into refactoring memory management in 8.6.8 and those problems do not seem present in the current release (8.6.7 is a year old). I'd try updating to 8.6.8 and seeing if that fixes things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:13:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 02:13:42 +0000
Subject: [issue34275] Problems with tkinter and tk8.6 on MacOS
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533262422.19.0.56676864532.issue34275@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified for my machine also that adding .update_idletasks(), as in calltips_2-2.diff works for my 3.7.0 installation.  I will assume until someone says otherwise that this is generally sufficient.

I am preparing a PR with the patch and will separately deal with the merge conflict I expect for PR7683.

----------
assignee:  -> terry.reedy
stage: needs patch -> patch review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:21:31 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 02:21:31 +0000
Subject: [issue34275] Problems with tkinter and tk8.6 on MacOS
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533262891.63.0.56676864532.issue34275@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8143

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:27:35 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 02:27:35 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533263255.75.0.56676864532.issue34275@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components:  -Tkinter
title: Problems with tkinter and tk8.6 on MacOS -> IDLE: no calltips on MacOS with tk 8.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:44:08 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 03 Aug 2018 02:44:08 +0000
Subject: [issue34317] Improve docstring   Environment variables in Windows NT
In-Reply-To: <1533207230.71.0.56676864532.issue34317@psf.upfronthosting.co.za>
Message-ID: <1533264248.78.0.56676864532.issue34317@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 46ebe61c7f3511b97268b44d5373a9e9cf0b5cc7 by Mariatta (HiyashiChuka) in branch 'master':
bpo-34317: Fix a dead url to Windows documentation (GH-8622)
https://github.com/python/cpython/commit/46ebe61c7f3511b97268b44d5373a9e9cf0b5cc7


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:44:32 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 02:44:32 +0000
Subject: [issue34317] Improve docstring   Environment variables in Windows NT
In-Reply-To: <1533207230.71.0.56676864532.issue34317@psf.upfronthosting.co.za>
Message-ID: <1533264272.81.0.56676864532.issue34317@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8144

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:50:11 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 02:50:11 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533264611.12.0.56676864532.issue34275@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8145

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 22:50:19 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 02:50:19 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533264619.84.0.56676864532.issue34275@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8146

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:01:17 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 03 Aug 2018 03:01:17 +0000
Subject: [issue34317] Improve docstring   Environment variables in Windows NT
In-Reply-To: <1533207230.71.0.56676864532.issue34317@psf.upfronthosting.co.za>
Message-ID: <1533265277.58.0.56676864532.issue34317@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:07:35 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 03:07:35 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533265655.57.0.56676864532.issue34275@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:29:43 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 03:29:43 +0000
Subject: [issue34317] Improve docstring   Environment variables in Windows NT
In-Reply-To: <1533207230.71.0.56676864532.issue34317@psf.upfronthosting.co.za>
Message-ID: <1533266983.5.0.56676864532.issue34317@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 34f59a7a7843d8e2c1922c830a99b5b7a022f4be by Miss Islington (bot) in branch '3.7':
bpo-34317: Fix a dead url to Windows documentation (GH-8622)
https://github.com/python/cpython/commit/34f59a7a7843d8e2c1922c830a99b5b7a022f4be


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34317>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:33:50 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 03:33:50 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533267230.21.0.56676864532.issue34275@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 363105e546709339e3419ada9daf5efa0b3b1e18 by Miss Islington (bot) in branch '3.6':
bpo-34275: Make IDLE calltips always visible on Mac.  (GH-8639)
https://github.com/python/cpython/commit/363105e546709339e3419ada9daf5efa0b3b1e18


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:39:40 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 03:39:40 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533267580.92.0.56676864532.issue34275@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ffd6364745dbeb7269c0e4376b63bf76bc44bcc6 by Miss Islington (bot) in branch '3.7':
bpo-34275: Make IDLE calltips always visible on Mac.  (GH-8639)
https://github.com/python/cpython/commit/ffd6364745dbeb7269c0e4376b63bf76bc44bcc6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:40:23 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 03:40:23 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533267623.73.0.56676864532.issue34275@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 24a54da9452efb21d30dc56c6b9d0977d08ae452 by Terry Jan Reedy in branch '2.7':
 [2.7] bpo-34275: Make IDLE calltips always visible on Mac. (GH-8639) (GH-8644)
https://github.com/python/cpython/commit/24a54da9452efb21d30dc56c6b9d0977d08ae452


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Thu Aug  2 23:50:43 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 03:50:43 +0000
Subject: [issue34275] IDLE: no calltips on MacOS with tk 8.6
In-Reply-To: <1532917001.14.0.56676864532.issue34275@psf.upfronthosting.co.za>
Message-ID: <1533268243.8.0.56676864532.issue34275@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you again, Kevin.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34275>
_______________________________________

From report at bugs.python.org  Fri Aug  3 00:30:00 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 04:30:00 +0000
Subject: [issue34327] test_subprocess fails
In-Reply-To: <1533257731.89.0.56676864532.issue34327@psf.upfronthosting.co.za>
Message-ID: <1533270600.4.0.56676864532.issue34327@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Related issue : https://bugs.python.org/issue34326

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34327>
_______________________________________

From report at bugs.python.org  Fri Aug  3 00:35:48 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Aug 2018 04:35:48 +0000
Subject: [issue33782] VSTS Windows-PR: internal error
In-Reply-To: <1528283564.84.0.592728768989.issue33782@psf.upfronthosting.co.za>
Message-ID: <1533270948.34.0.56676864532.issue33782@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> A quick follow-up commit can happen if one uses the web editor to edit more than one file

I hadn't thought of that one. Hopefully they'll just fix their bug though :)

I spent a bit of time at the EuroPython sprints making the changes to quickly finish the build if nothing relevant has changed, but ironically it was so backed up with testing doc changes that I couldn't check it! Hopefully sometime next week I can finish that off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33782>
_______________________________________

From report at bugs.python.org  Fri Aug  3 00:44:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 04:44:52 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533271492.84.0.56676864532.issue34326@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Some of VSTS Mac OS and Linux builds also have the same failure 

Sample Linux : https://python.visualstudio.com/cpython/_build/results?buildId=21154&view=logs
Sample Mac OS : https://python.visualstudio.com/cpython/_build/results?buildId=21155&view=logs

Test case failure reported in Arch : https://bugs.python.org/issue34327

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 00:52:37 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 04:52:37 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533271957.16.0.56676864532.issue34319@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +8148
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:12:47 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Aug 2018 05:12:47 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533273167.78.0.56676864532.issue34312@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Teammate of mine tripped up against this because he tried to use a list.

Then, I recommend we close this.  Accepting a list would have encouraged inefficient code (a tuple of constants can be peephole optimized but a list of constants is rebuilt on every call).  Also, the error message is very clear, so it is unlikely he was "tripped-up" for more than a few seconds.

    >>> 'hello'.startswith(['he', 'go'])
    Traceback (most recent call last):
      File "<pyshell#1>", line 1, in <module>
        'hello'.startswith(['he', 'go'])
    TypeError: startswith first arg must be str or a tuple of str, not list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:16:26 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Aug 2018 05:16:26 +0000
Subject: [issue27419] Bugs in PyImport_ImportModuleLevelObject
In-Reply-To: <1467275301.6.0.860119433525.issue27419@psf.upfronthosting.co.za>
Message-ID: <1533273386.86.0.56676864532.issue27419@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it can. Thanks Berker for reminder.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27419>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:19:45 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Aug 2018 05:19:45 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533273585.36.0.56676864532.issue34325@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is the result of issue34097.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:20:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Aug 2018 05:20:43 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533273643.69.0.56676864532.issue34097@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tests are failed on some buildbots. See issue34325.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:21:37 2018
From: report at bugs.python.org (sakamotoaya)
Date: Fri, 03 Aug 2018 05:21:37 +0000
Subject: [issue34328] Question Incorrect URL for the Visual C++ Build Tools
Message-ID: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>


New submission from sakamotoaya <aya.sakamoto at outlook.com>:

I try "python setup.py". 
The following issue has occurred.

Excerpt from Error
?????????????????????
reading manifest template 'MANIFEST.in'
writing manifest file 'scikit_learn.egg-info\SOURCES.txt'
running build_ext
No module named 'numpy.distutils._msvccompiler' in numpy.distutils; trying from
distutils
customize MSVCCompiler
Missing compiler_cxx fix for MSVCCompiler
customize MSVCCompiler using build_clib
building 'libsvm-skl' library
compiling C sources
error: Microsoft Visual C++ 14.0 is required. Get it with "Microsoft Visual C++
Build Tools": http://landinghub.visualstudio.com/visual-cpp-build-tools
?????????????????????

Expired link:  
http://landinghub.visualstudio.com/visual-cpp-build-tools

I think The new link:
https://download.microsoft.com/download/5/F/7/5F7ACAEB-8363-451F-9425-68A90F98B238/visualcppbuildtools_full.exe


Please give me advice on how I should correct those error message.

----------
components: Windows
messages: 323024
nosy: HiyashiChuka, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Question Incorrect URL for the Visual C++ Build Tools
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:22:38 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 05:22:38 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533273758.96.0.56676864532.issue34325@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:22:39 2018
From: report at bugs.python.org (sakamotoaya)
Date: Fri, 03 Aug 2018 05:22:39 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533273759.88.0.56676864532.issue34328@psf.upfronthosting.co.za>


Change by sakamotoaya <aya.sakamoto at outlook.com>:


----------
title: Question Incorrect URL for the Visual C++ Build Tools -> Incorrect URL for the Visual C++ Build Tools

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:45:10 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 03 Aug 2018 05:45:10 +0000
Subject: [issue34105] test_socket.test_host_resolution_bad_address fails on
 Mac OS X 10.13.6
In-Reply-To: <1531421390.98.0.56676864532.issue34105@psf.upfronthosting.co.za>
Message-ID: <1533275110.9.0.56676864532.issue34105@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

For some reason your system resolves invalid names, likely due to some upstream nameserver misbehaving.

Is your Internet provider T-Online in Germany? The address 62.138.239.45 is registered to that company, the IP address also appears to host some kind of search page. This is sadly behaviour of some Internet provider: provide a DNS server to customers that won't return "domain not found", but returns a search page with advertising instead.

All in all I think this is not a bug in Python.

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34105>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:56:29 2018
From: report at bugs.python.org (sakamotoaya)
Date: Fri, 03 Aug 2018 05:56:29 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533275789.13.0.56676864532.issue34328@psf.upfronthosting.co.za>


Change by sakamotoaya <aya.sakamoto at outlook.com>:


----------
nosy: +CuriousLearner, ncoghlan, serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 01:57:15 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 03 Aug 2018 05:57:15 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533275835.76.0.56676864532.issue34328@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This message is generated by setuptools (in module setuptools.msvc). 

The GitHub repository for setuptools is at <https://github.com/pypa/setuptools>, please contact the developers there.

----------
nosy: +ronaldoussoren
resolution:  -> third party
stage:  -> resolved
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:00:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 06:00:30 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533276030.02.0.56676864532.issue34328@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Upstream issue was resolved : https://github.com/pypa/setuptools/issues/1394

Thanks

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:01:54 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 06:01:54 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533276114.92.0.56676864532.issue34328@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ah sorry, I don't know why it opened this bug while adding a comment. Feel free to change the status.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:05:02 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 03 Aug 2018 06:05:02 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533276302.33.0.56676864532.issue34312@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I tend to agree.  ISTM that for users, understanding the error message and passing a tuple is trivial, while realizing the performance benefit of using a tuple rather than a list or set here is certainly non-trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:10:33 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 06:10:33 +0000
Subject: [issue34327] test_subprocess fails
In-Reply-To: <1533257731.89.0.56676864532.issue34327@psf.upfronthosting.co.za>
Message-ID: <1533276633.42.0.56676864532.issue34327@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

It's a duplicate of this issue: https://bugs.python.org/issue34326

I close this issue.

Thank you for your feedback.

----------
nosy: +matrixise
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34327>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:14:15 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 06:14:15 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533276855.37.0.56676864532.issue34328@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:39:42 2018
From: report at bugs.python.org (sakamotoaya)
Date: Fri, 03 Aug 2018 06:39:42 +0000
Subject: [issue34328] Incorrect URL for the Visual C++ Build Tools
In-Reply-To: <1533273697.75.0.56676864532.issue34328@psf.upfronthosting.co.za>
Message-ID: <1533278382.03.0.56676864532.issue34328@psf.upfronthosting.co.za>


sakamotoaya <aya.sakamoto at outlook.com> added the comment:

Everyone Thank you.
That was really helpful.

Problem already been resolved.
I change status?Pending to close.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34328>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:45:26 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 06:45:26 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533278726.64.0.56676864532.issue34312@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I also agree with the problem of performance, tuple and str are immutables and from that, we can optimize the generation of the bytecode.

Raymond, @Brett & @Serhiy, Can we close this issue?

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:51:45 2018
From: report at bugs.python.org (Thomas Nyberg)
Date: Fri, 03 Aug 2018 06:51:45 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533279105.89.0.56676864532.issue34319@psf.upfronthosting.co.za>


Thomas Nyberg <tomnyberg at gmail.com> added the comment:

For what it's worth as the original opener of the bug report, I think Terry's recommendation clarifies things quite well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:53:02 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Aug 2018 06:53:02 +0000
Subject: [issue34314] Like __hash__,
 allow setting MyClass.__init__ to None to prevent it being called by
 type.__call__
In-Reply-To: <1533178926.29.0.56676864532.issue34314@psf.upfronthosting.co.za>
Message-ID: <1533279182.11.0.56676864532.issue34314@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34314>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:54:22 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 06:54:22 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533279262.92.0.56676864532.issue34324@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +8149
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:54:54 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 06:54:54 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533279294.58.0.56676864532.issue34324@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I just pushed a PR.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Fri Aug  3 02:59:20 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 03 Aug 2018 06:59:20 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533279560.91.0.56676864532.issue34325@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:00:40 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 03 Aug 2018 07:00:40 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533279640.71.0.56676864532.issue34325@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy: +Dormouse759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:08:00 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 07:08:00 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1533280080.61.0.56676864532.issue34323@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi johnboy2,

thank you for your issue, but could you send us more information about your platform?

thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:12:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Aug 2018 07:12:12 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1533280332.46.0.56676864532.issue34207@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I tried the tests on FreeBSD 11.x and FreeBSD 10.x digitalocean droplets with master branch and the tests pass. Adding information that might be helpful.

# FreeBSD 11.2-RELEASE

root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # uname -a
FreeBSD freebsd-s-1vcpu-1gb-blr1-01 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018     root at releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # ./python
Python 3.8.0a0 (heads/master:b6efc2c, Aug  3 2018, 06:26:53)
[Clang 6.0.0 (tags/RELEASE_600/final 326565)] on freebsd11
Type "help", "copyright", "credits" or "license" for more information.
>>>
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # setenv PYTHONIOENCODING utf-8
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # setenv PYTHONWARNINGS ignore:Deprecaci?nWarning
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # setenv PYTHONDEVMODE ""
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # ./python -c "import sys; sys.stdout.write(str(sys.warnoptions))"
['ignore:Deprecaci?nWarning']
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # ./python -m unittest -v test.test_warnings test.test_cmd_line test.test_utf8_mode
test_issue_8766 (test.test_warnings.BootstrapTest) ... ok
test_catch_warnings_defaults (test.test_warnings.CCatchWarningTests) ... ok
test_catch_warnings_recording (test.test_warnings.CCatchWarningTests) ... ok
test_catch_warnings_reentry_guard (test.test_warnings.CCatchWarningTests) ... ok
test_catch_warnings_restore (test.test_warnings.CCatchWarningTests) ... ok
test_check_warnings (test.test_warnings.CCatchWarningTests) ... ok
test_record_override_showwarning_before (test.test_warnings.CCatchWarningTests) ... ok
test_record_override_showwarning_inside (test.test_warnings.CCatchWarningTests) ... ok
test_comma_separated_warnings (test.test_warnings.CEnvironmentVariableTests) ... ok
test_conflicting_envvar_and_command_line (test.test_warnings.CEnvironmentVariableTests) ... ok
test_default_filter_configuration (test.test_warnings.CEnvironmentVariableTests) ... ok
test_envvar_and_command_line (test.test_warnings.CEnvironmentVariableTests) ... ok
test_nonascii (test.test_warnings.CEnvironmentVariableTests) ... ok
test_single_warning (test.test_warnings.CEnvironmentVariableTests) ... ok
test_always (test.test_warnings.CFilterTests) ... ok
test_always_after_default (test.test_warnings.CFilterTests) ... ok
test_append_duplicate (test.test_warnings.CFilterTests) ... ok
test_default (test.test_warnings.CFilterTests) ... ok
test_error (test.test_warnings.CFilterTests) ... ok
test_error_after_default (test.test_warnings.CFilterTests) ... ok
test_filterwarnings (test.test_warnings.CFilterTests) ... ok
test_filterwarnings_duplicate_filters (test.test_warnings.CFilterTests) ... ok
test_ignore (test.test_warnings.CFilterTests) ... ok
test_ignore_after_default (test.test_warnings.CFilterTests) ... ok
test_inheritance (test.test_warnings.CFilterTests) ... ok
test_message_matching (test.test_warnings.CFilterTests) ... ok
test_module (test.test_warnings.CFilterTests) ... ok
test_module_globals (test.test_warnings.CFilterTests) ... ok
test_mutate_filter_list (test.test_warnings.CFilterTests) ... ok
test_once (test.test_warnings.CFilterTests) ... ok
test_ordering (test.test_warnings.CFilterTests) ... ok
test_simplefilter_duplicate_filters (test.test_warnings.CFilterTests) ... ok
test_module_all_attribute (test.test_warnings.CPublicAPITests) ... ok
test_improper_input (test.test_warnings.CWCmdLineTests) ... ok
test_accelerated (test.test_warnings.CWarnTests) ... ok
test_bad_str (test.test_warnings.CWarnTests) ... ok
test_exec_filename (test.test_warnings.CWarnTests) ... ok
test_filename (test.test_warnings.CWarnTests) ... ok
test_message (test.test_warnings.CWarnTests) ... ok
test_stacklevel (test.test_warnings.CWarnTests) ... ok
test_stacklevel_import (test.test_warnings.CWarnTests) ... ok
test_warn_explicit_non_ascii_filename (test.test_warnings.CWarnTests) ... ok
test_warn_explicit_type_errors (test.test_warnings.CWarnTests) ... ok
test_warn_nonstandard_types (test.test_warnings.CWarnTests) ... ok
test_warning_classes (test.test_warnings.CWarnTests) ... ok
test_formatwarning (test.test_warnings.CWarningsDisplayTests) ... ok
test_showwarning (test.test_warnings.CWarningsDisplayTests) ... ok
test_finalization (test.test_warnings.FinalizationTest) ... ok
test_late_resource_warning (test.test_warnings.FinalizationTest) ... ok
test_catch_warnings_defaults (test.test_warnings.PyCatchWarningTests) ... ok
test_catch_warnings_recording (test.test_warnings.PyCatchWarningTests) ... ok
test_catch_warnings_reentry_guard (test.test_warnings.PyCatchWarningTests) ... ok
test_catch_warnings_restore (test.test_warnings.PyCatchWarningTests) ... ok
test_check_warnings (test.test_warnings.PyCatchWarningTests) ... ok
test_record_override_showwarning_before (test.test_warnings.PyCatchWarningTests) ... ok
test_record_override_showwarning_inside (test.test_warnings.PyCatchWarningTests) ... ok
test_comma_separated_warnings (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_conflicting_envvar_and_command_line (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_default_filter_configuration (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_envvar_and_command_line (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_nonascii (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_single_warning (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_always (test.test_warnings.PyFilterTests) ... ok
test_always_after_default (test.test_warnings.PyFilterTests) ... ok
test_append_duplicate (test.test_warnings.PyFilterTests) ... ok
test_default (test.test_warnings.PyFilterTests) ... ok
test_error (test.test_warnings.PyFilterTests) ... ok
test_error_after_default (test.test_warnings.PyFilterTests) ... ok
test_filterwarnings (test.test_warnings.PyFilterTests) ... ok
test_filterwarnings_duplicate_filters (test.test_warnings.PyFilterTests) ... ok
test_ignore (test.test_warnings.PyFilterTests) ... ok
test_ignore_after_default (test.test_warnings.PyFilterTests) ... ok
test_inheritance (test.test_warnings.PyFilterTests) ... ok
test_message_matching (test.test_warnings.PyFilterTests) ... ok
test_module (test.test_warnings.PyFilterTests) ... ok
test_module_globals (test.test_warnings.PyFilterTests) ... ok
test_mutate_filter_list (test.test_warnings.PyFilterTests) ... ok
test_once (test.test_warnings.PyFilterTests) ... ok
test_ordering (test.test_warnings.PyFilterTests) ... ok
test_simplefilter_duplicate_filters (test.test_warnings.PyFilterTests) ... ok
test_module_all_attribute (test.test_warnings.PyPublicAPITests) ... ok
test_improper_input (test.test_warnings.PyWCmdLineTests) ... ok
test_improper_option (test.test_warnings.PyWCmdLineTests) ... ok
test_warnings_bootstrap (test.test_warnings.PyWCmdLineTests) ... ok
test_bad_str (test.test_warnings.PyWarnTests) ... ok
test_exec_filename (test.test_warnings.PyWarnTests) ... ok
test_filename (test.test_warnings.PyWarnTests) ... ok
test_message (test.test_warnings.PyWarnTests) ... ok
test_pure_python (test.test_warnings.PyWarnTests) ... ok
test_stacklevel (test.test_warnings.PyWarnTests) ... ok
test_stacklevel_import (test.test_warnings.PyWarnTests) ... ok
test_warn_explicit_non_ascii_filename (test.test_warnings.PyWarnTests) ... ok
test_warn_explicit_type_errors (test.test_warnings.PyWarnTests) ... ok
test_warn_nonstandard_types (test.test_warnings.PyWarnTests) ... ok
test_warning_classes (test.test_warnings.PyWarnTests) ... ok
test_formatwarning (test.test_warnings.PyWarningsDisplayTests) ... ok
test_showwarning (test.test_warnings.PyWarningsDisplayTests) ... ok
test_tracemalloc (test.test_warnings.PyWarningsDisplayTests) ... ok
test_default_action (test.test_warnings._WarningsTests) ... ok
test_filename_none (test.test_warnings._WarningsTests) ... ok
test_filter (test.test_warnings._WarningsTests) ... ok
test_issue31285 (test.test_warnings._WarningsTests) ... ok
test_issue31411 (test.test_warnings._WarningsTests) ... ok
test_issue31416 (test.test_warnings._WarningsTests) ... ok
test_issue31566 (test.test_warnings._WarningsTests) ... ok
test_onceregistry (test.test_warnings._WarningsTests) ... ok
test_show_warning_output (test.test_warnings._WarningsTests) ... ok
test_showwarning_missing (test.test_warnings._WarningsTests) ... ok
test_showwarning_not_callable (test.test_warnings._WarningsTests) ... ok
test_showwarnmsg_missing (test.test_warnings._WarningsTests) ... ok
test_stderr_none (test.test_warnings._WarningsTests) ... ok
test_argv0_normalization (test.test_cmd_line.CmdLineTest) ... skipped 'bpo-32457 only applies on Windows'
test_builtin_input (test.test_cmd_line.CmdLineTest) ... ok
test_closed_stdout (test.test_cmd_line.CmdLineTest) ... ok
test_del___main__ (test.test_cmd_line.CmdLineTest) ... ok
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_displayhook_unencodable (test.test_cmd_line.CmdLineTest) ... ok
test_empty_PYTHONPATH_issue16309 (test.test_cmd_line.CmdLineTest) ... ok
test_hash_randomization (test.test_cmd_line.CmdLineTest) ... ok
test_isolatedmode (test.test_cmd_line.CmdLineTest) ... ok
test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest) ... ok
test_no_std_streams (test.test_cmd_line.CmdLineTest) ... ok
test_no_stderr (test.test_cmd_line.CmdLineTest) ... ok
test_no_stdin (test.test_cmd_line.CmdLineTest) ... ok
test_no_stdout (test.test_cmd_line.CmdLineTest) ... ok
test_non_ascii (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_osx_android_utf8 (test.test_cmd_line.CmdLineTest) ... skipped 'test specific to Mac OS X and Android'
test_output_newline (test.test_cmd_line.CmdLineTest) ... ok
test_pythondevmode_env (test.test_cmd_line.CmdLineTest) ... ok
test_pythonmalloc (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... ok
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_set_pycache_prefix (test.test_cmd_line.CmdLineTest) ... ok
test_showrefcount (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_stdin_readline (test.test_cmd_line.CmdLineTest) ... ok
test_stdout_flush_at_shutdown (test.test_cmd_line.CmdLineTest) ... ok
test_sys_flags_set (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_undecodable_code (test.test_cmd_line.CmdLineTest) ... ok
test_unknown_options (test.test_cmd_line.CmdLineTest) ... ok
test_unmached_quote (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok
test_warnings_filter_precedence (test.test_cmd_line.CmdLineTest) ... ok
test_xdev (test.test_cmd_line.CmdLineTest) ... ok
test_xoptions (test.test_cmd_line.CmdLineTest) ... ok
test_ignore_PYTHONHASHSEED (test.test_cmd_line.IgnoreEnvironmentTest) ... ok
test_ignore_PYTHONPATH (test.test_cmd_line.IgnoreEnvironmentTest) ... ok
test_sys_flags_not_set (test.test_cmd_line.IgnoreEnvironmentTest) ... ok
test_cmd_line (test.test_utf8_mode.UTF8ModeTests) ... ok
test_env_var (test.test_utf8_mode.UTF8ModeTests) ... ok
test_filesystemencoding (test.test_utf8_mode.UTF8ModeTests) ... ok
test_io (test.test_utf8_mode.UTF8ModeTests) ... ok
test_io_encoding (test.test_utf8_mode.UTF8ModeTests) ... ok
test_locale_getpreferredencoding (test.test_utf8_mode.UTF8ModeTests) ... ok
test_optim_level (test.test_utf8_mode.UTF8ModeTests) ... ok
test_posix_locale (test.test_utf8_mode.UTF8ModeTests) ... ok
test_stdio (test.test_utf8_mode.UTF8ModeTests) ... ok
test_xoption (test.test_utf8_mode.UTF8ModeTests) ... ok

----------------------------------------------------------------------
Ran 164 tests in 6.439s

# FreeBSD 10.4-RELEASE

root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # uname -a
FreeBSD freebsd-s-1vcpu-1gb-blr1-01 10.4-RELEASE FreeBSD 10.4-RELEASE #0 r324094: Fri Sep 29 01:45:44 UTC 2017     root at releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd6
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # ./python
Python 3.8.0a0 (heads/master:b6efc2c, Aug  3 2018, 06:58:22)
[Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)] on freebsd10
Type "help", "copyright", "credits" or "license" for more information.
>>>
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # setenv PYTHONIOENCODING utf-8
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # setenv PYTHONWARNINGS ignore:Deprecaci?nWarning
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # setenv PYTHONDEVMODE ""
root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # ./python -c "import sys; sys.stdout.write(str(sys.warnoptions))"
['ignore:Deprecaci?nWarning']

# Ran as a separate session on the same machine to ignore environment variables

root at freebsd-s-1vcpu-1gb-blr1-01:~/cpython # ./python -m unittest -v test.test_warnings test.test_cmd_line test.test_utf8_mode
test_issue_8766 (test.test_warnings.BootstrapTest) ... ok
test_catch_warnings_defaults (test.test_warnings.CCatchWarningTests) ... ok
test_catch_warnings_recording (test.test_warnings.CCatchWarningTests) ... ok
test_catch_warnings_reentry_guard (test.test_warnings.CCatchWarningTests) ... ok
test_catch_warnings_restore (test.test_warnings.CCatchWarningTests) ... ok
test_check_warnings (test.test_warnings.CCatchWarningTests) ... ok
test_record_override_showwarning_before (test.test_warnings.CCatchWarningTests) ... ok
test_record_override_showwarning_inside (test.test_warnings.CCatchWarningTests) ... ok
test_comma_separated_warnings (test.test_warnings.CEnvironmentVariableTests) ... ok
test_conflicting_envvar_and_command_line (test.test_warnings.CEnvironmentVariableTests) ... ok
test_default_filter_configuration (test.test_warnings.CEnvironmentVariableTests) ... ok
test_envvar_and_command_line (test.test_warnings.CEnvironmentVariableTests) ... ok
test_nonascii (test.test_warnings.CEnvironmentVariableTests) ... ok
test_single_warning (test.test_warnings.CEnvironmentVariableTests) ... ok
test_always (test.test_warnings.CFilterTests) ... ok
test_always_after_default (test.test_warnings.CFilterTests) ... ok
test_append_duplicate (test.test_warnings.CFilterTests) ... ok
test_default (test.test_warnings.CFilterTests) ... ok
test_error (test.test_warnings.CFilterTests) ... ok
test_error_after_default (test.test_warnings.CFilterTests) ... ok
test_filterwarnings (test.test_warnings.CFilterTests) ... ok
test_filterwarnings_duplicate_filters (test.test_warnings.CFilterTests) ... ok
test_ignore (test.test_warnings.CFilterTests) ... ok
test_ignore_after_default (test.test_warnings.CFilterTests) ... ok
test_inheritance (test.test_warnings.CFilterTests) ... ok
test_message_matching (test.test_warnings.CFilterTests) ... ok
test_module (test.test_warnings.CFilterTests) ... ok
test_module_globals (test.test_warnings.CFilterTests) ... ok
test_mutate_filter_list (test.test_warnings.CFilterTests) ... ok
test_once (test.test_warnings.CFilterTests) ... ok
test_ordering (test.test_warnings.CFilterTests) ... ok
test_simplefilter_duplicate_filters (test.test_warnings.CFilterTests) ... ok
test_module_all_attribute (test.test_warnings.CPublicAPITests) ... ok
test_improper_input (test.test_warnings.CWCmdLineTests) ... ok
test_accelerated (test.test_warnings.CWarnTests) ... ok
test_bad_str (test.test_warnings.CWarnTests) ... ok
test_exec_filename (test.test_warnings.CWarnTests) ... ok
test_filename (test.test_warnings.CWarnTests) ... ok
test_message (test.test_warnings.CWarnTests) ... ok
test_stacklevel (test.test_warnings.CWarnTests) ... ok
test_stacklevel_import (test.test_warnings.CWarnTests) ... ok
test_warn_explicit_non_ascii_filename (test.test_warnings.CWarnTests) ... ok
test_warn_explicit_type_errors (test.test_warnings.CWarnTests) ... ok
test_warn_nonstandard_types (test.test_warnings.CWarnTests) ... ok
test_warning_classes (test.test_warnings.CWarnTests) ... ok
test_formatwarning (test.test_warnings.CWarningsDisplayTests) ... ok
test_showwarning (test.test_warnings.CWarningsDisplayTests) ... ok
test_finalization (test.test_warnings.FinalizationTest) ... ok
test_late_resource_warning (test.test_warnings.FinalizationTest) ... ok
test_catch_warnings_defaults (test.test_warnings.PyCatchWarningTests) ... ok
test_catch_warnings_recording (test.test_warnings.PyCatchWarningTests) ... ok
test_catch_warnings_reentry_guard (test.test_warnings.PyCatchWarningTests) ... ok
test_catch_warnings_restore (test.test_warnings.PyCatchWarningTests) ... ok
test_check_warnings (test.test_warnings.PyCatchWarningTests) ... ok
test_record_override_showwarning_before (test.test_warnings.PyCatchWarningTests) ... ok
test_record_override_showwarning_inside (test.test_warnings.PyCatchWarningTests) ... ok
test_comma_separated_warnings (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_conflicting_envvar_and_command_line (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_default_filter_configuration (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_envvar_and_command_line (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_nonascii (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_single_warning (test.test_warnings.PyEnvironmentVariableTests) ... ok
test_always (test.test_warnings.PyFilterTests) ... ok
test_always_after_default (test.test_warnings.PyFilterTests) ... ok
test_append_duplicate (test.test_warnings.PyFilterTests) ... ok
test_default (test.test_warnings.PyFilterTests) ... ok
test_error (test.test_warnings.PyFilterTests) ... ok
test_error_after_default (test.test_warnings.PyFilterTests) ... ok
test_filterwarnings (test.test_warnings.PyFilterTests) ... ok
test_filterwarnings_duplicate_filters (test.test_warnings.PyFilterTests) ... ok
test_ignore (test.test_warnings.PyFilterTests) ... ok
test_ignore_after_default (test.test_warnings.PyFilterTests) ... ok
test_inheritance (test.test_warnings.PyFilterTests) ... ok
test_message_matching (test.test_warnings.PyFilterTests) ... ok
test_module (test.test_warnings.PyFilterTests) ... ok
test_module_globals (test.test_warnings.PyFilterTests) ... ok
test_mutate_filter_list (test.test_warnings.PyFilterTests) ... ok
test_once (test.test_warnings.PyFilterTests) ... ok
test_ordering (test.test_warnings.PyFilterTests) ... ok
test_simplefilter_duplicate_filters (test.test_warnings.PyFilterTests) ... ok
test_module_all_attribute (test.test_warnings.PyPublicAPITests) ... ok
test_improper_input (test.test_warnings.PyWCmdLineTests) ... ok
test_improper_option (test.test_warnings.PyWCmdLineTests) ... ok
test_warnings_bootstrap (test.test_warnings.PyWCmdLineTests) ... ok
test_bad_str (test.test_warnings.PyWarnTests) ... ok
test_exec_filename (test.test_warnings.PyWarnTests) ... ok
test_filename (test.test_warnings.PyWarnTests) ... ok
test_message (test.test_warnings.PyWarnTests) ... ok
test_pure_python (test.test_warnings.PyWarnTests) ... ok
test_stacklevel (test.test_warnings.PyWarnTests) ... ok
test_stacklevel_import (test.test_warnings.PyWarnTests) ... ok
test_warn_explicit_non_ascii_filename (test.test_warnings.PyWarnTests) ... ok
test_warn_explicit_type_errors (test.test_warnings.PyWarnTests) ... ok
test_warn_nonstandard_types (test.test_warnings.PyWarnTests) ... ok
test_warning_classes (test.test_warnings.PyWarnTests) ... ok
test_formatwarning (test.test_warnings.PyWarningsDisplayTests) ... ok
test_showwarning (test.test_warnings.PyWarningsDisplayTests) ... ok
test_tracemalloc (test.test_warnings.PyWarningsDisplayTests) ... ok
test_default_action (test.test_warnings._WarningsTests) ... ok
test_filename_none (test.test_warnings._WarningsTests) ... ok
test_filter (test.test_warnings._WarningsTests) ... ok
test_issue31285 (test.test_warnings._WarningsTests) ... ok
test_issue31411 (test.test_warnings._WarningsTests) ... ok
test_issue31416 (test.test_warnings._WarningsTests) ... ok
test_issue31566 (test.test_warnings._WarningsTests) ... ok
test_onceregistry (test.test_warnings._WarningsTests) ... ok
test_show_warning_output (test.test_warnings._WarningsTests) ... ok
test_showwarning_missing (test.test_warnings._WarningsTests) ... ok
test_showwarning_not_callable (test.test_warnings._WarningsTests) ... ok
test_showwarnmsg_missing (test.test_warnings._WarningsTests) ... ok
test_stderr_none (test.test_warnings._WarningsTests) ... ok
test_argv0_normalization (test.test_cmd_line.CmdLineTest) ... skipped 'bpo-32457 only applies on Windows'
test_builtin_input (test.test_cmd_line.CmdLineTest) ... ok
test_closed_stdout (test.test_cmd_line.CmdLineTest) ... ok
test_del___main__ (test.test_cmd_line.CmdLineTest) ... ok
test_directories (test.test_cmd_line.CmdLineTest) ... ok
test_displayhook_unencodable (test.test_cmd_line.CmdLineTest) ... ok
test_empty_PYTHONPATH_issue16309 (test.test_cmd_line.CmdLineTest) ... ok
test_hash_randomization (test.test_cmd_line.CmdLineTest) ... ok
test_isolatedmode (test.test_cmd_line.CmdLineTest) ... ok
test_large_PYTHONPATH (test.test_cmd_line.CmdLineTest) ... ok
test_no_std_streams (test.test_cmd_line.CmdLineTest) ... ok
test_no_stderr (test.test_cmd_line.CmdLineTest) ... ok
test_no_stdin (test.test_cmd_line.CmdLineTest) ... ok
test_no_stdout (test.test_cmd_line.CmdLineTest) ... ok
test_non_ascii (test.test_cmd_line.CmdLineTest) ... ok
test_optimize (test.test_cmd_line.CmdLineTest) ... ok
test_osx_android_utf8 (test.test_cmd_line.CmdLineTest) ... skipped 'test specific to Mac OS X and Android'
test_output_newline (test.test_cmd_line.CmdLineTest) ... ok
test_pythondevmode_env (test.test_cmd_line.CmdLineTest) ... ok
test_pythonmalloc (test.test_cmd_line.CmdLineTest) ... ok
test_run_code (test.test_cmd_line.CmdLineTest) ... ok
test_run_module (test.test_cmd_line.CmdLineTest) ... ok
test_run_module_bug1764407 (test.test_cmd_line.CmdLineTest) ... ok
test_set_pycache_prefix (test.test_cmd_line.CmdLineTest) ... ok
test_showrefcount (test.test_cmd_line.CmdLineTest) ... ok
test_site_flag (test.test_cmd_line.CmdLineTest) ... ok
test_stdin_readline (test.test_cmd_line.CmdLineTest) ... ok
test_stdout_flush_at_shutdown (test.test_cmd_line.CmdLineTest) ... ok
test_sys_flags_set (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_input (test.test_cmd_line.CmdLineTest) ... ok
test_unbuffered_output (test.test_cmd_line.CmdLineTest) ... ok
test_undecodable_code (test.test_cmd_line.CmdLineTest) ... ok
test_unknown_options (test.test_cmd_line.CmdLineTest) ... ok
test_unmached_quote (test.test_cmd_line.CmdLineTest) ... ok
test_usage (test.test_cmd_line.CmdLineTest) ... ok
test_verbose (test.test_cmd_line.CmdLineTest) ... ok
test_version (test.test_cmd_line.CmdLineTest) ... ok
test_warnings_filter_precedence (test.test_cmd_line.CmdLineTest) ... ok
test_xdev (test.test_cmd_line.CmdLineTest) ... ok
test_xoptions (test.test_cmd_line.CmdLineTest) ... ok
test_ignore_PYTHONHASHSEED (test.test_cmd_line.IgnoreEnvironmentTest) ... ok
test_ignore_PYTHONPATH (test.test_cmd_line.IgnoreEnvironmentTest) ... ok
test_sys_flags_not_set (test.test_cmd_line.IgnoreEnvironmentTest) ... ok
test_cmd_line (test.test_utf8_mode.UTF8ModeTests) ... ok
test_env_var (test.test_utf8_mode.UTF8ModeTests) ... ok
test_filesystemencoding (test.test_utf8_mode.UTF8ModeTests) ... ok
test_io (test.test_utf8_mode.UTF8ModeTests) ... ok
test_io_encoding (test.test_utf8_mode.UTF8ModeTests) ... ok
test_locale_getpreferredencoding (test.test_utf8_mode.UTF8ModeTests) ... ok
test_optim_level (test.test_utf8_mode.UTF8ModeTests) ... ok
test_posix_locale (test.test_utf8_mode.UTF8ModeTests) ... ok
test_stdio (test.test_utf8_mode.UTF8ModeTests) ... ok
test_xoption (test.test_utf8_mode.UTF8ModeTests) ... ok

----------------------------------------------------------------------
Ran 164 tests in 15.137s

OK (skipped=2)



Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:18:43 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 07:18:43 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1533280723.57.0.56676864532.issue34207@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

xtreak

in this case, it's an issue on the buildbot cluster, we have to be sure that we don't have this error again.

and for that, we have to find the origin of the crash on buildbot.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:20:34 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 07:20:34 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533280834.25.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Same issue with my builds : 

* Linux -> https://python.visualstudio.com/cpython/_build/results?buildId=21273&view=logs
* macOS -> https://python.visualstudio.com/cpython/_build/results?buildId=21274&view=logs

----------
nosy: +matrixise, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:33:47 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 03 Aug 2018 07:33:47 +0000
Subject: [issue34022] 6 tests fail using SOURCE_DATE_EPOCH env var
In-Reply-To: <1530533915.92.0.56676864532.issue34022@psf.upfronthosting.co.za>
Message-ID: <1533281627.53.0.56676864532.issue34022@psf.upfronthosting.co.za>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34022>
_______________________________________

From report at bugs.python.org  Fri Aug  3 03:36:22 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 07:36:22 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533281782.21.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

same problem here:
linux: https://python.visualstudio.com/8e426817-76c0-4b99-ba9e-a48a1e4bd5db/_build/index?buildId=21241
macOS: https://python.visualstudio.com/8e426817-76c0-4b99-ba9e-a48a1e4bd5db/_build/index?buildId=21242

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 04:27:26 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 03 Aug 2018 08:27:26 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533284846.03.0.56676864532.issue34313@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

I was telling only that I've seen myself the issues with some Tcl/Tk versions. As I often build Tcl/Tk on macOS, I can confirm that on 8.6.8 I didn't see issues (those were effectively present in (ActiveState or not) Tcl 8.5.18, 8.5.19, 8.6.6, 8.6.7. The only issue I had was an @autoreleasepool after several open/close of the Preferences dialog in IDLE (see the 34120 issue), related probably to a partial release of resources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Fri Aug  3 04:29:59 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 08:29:59 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533284999.54.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

When I try to find the issue with git bisect, I have one commit.

72ec3193b5118a2ccc8be8bf03d7b74691c6a264 is the first bad commit
commit 72ec3193b5118a2ccc8be8bf03d7b74691c6a264
Author: Victor Stinner <vstinner at redhat.com>
Date:   Thu Aug 2 19:34:20 2018 +0200

    bpo-34170: Cleanup pymain_run_filename() (GH-8631)
    
    * Inline pymain_run_file() and pymain_open_filename() into
      pymain_run_filename()
    * Created pymain_run_stdin() which is pymain_run_filename() with
      filename=NULL
    * Rename pymain_run_filename() to pymain_run_file()

:040000 040000 6e49f5791bc63c3bf67a3674ccc00a412b5f089a 1b93e169af3afb07daaf06e2247a3eae6a88cac5 M	Modules

with ./python -m test test_subprocess -v

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 05:58:05 2018
From: report at bugs.python.org (Stefan Otte)
Date: Fri, 03 Aug 2018 09:58:05 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
Message-ID: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>


New submission from Stefan Otte <stefan.otte at gmail.com>:

Hello folks!

I didn't realize that you can remove a suffix with the `with_suffix` function of the `Path` class of `pathlib` and I always used a little utility function that I wrote.
I wanted to add that functionality (removing of a suffix) and submit a PR but then I saw that `with_suffix` has you covered already. I'm just documenting this feature with the PR I'll submit.

----------
assignee: docs at python
components: Documentation
messages: 323042
nosy: docs at python, sotte
priority: normal
severity: normal
status: open
title: Document how to remove a suffix with pathlib.Path.with_suffix
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 06:01:13 2018
From: report at bugs.python.org (Stefan Otte)
Date: Fri, 03 Aug 2018 10:01:13 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533290473.37.0.56676864532.issue34329@psf.upfronthosting.co.za>


Change by Stefan Otte <stefan.otte at gmail.com>:


----------
keywords: +patch
pull_requests: +8150
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 06:01:47 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 10:01:47 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533290507.5.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I continue to work on this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 06:54:08 2018
From: report at bugs.python.org (Jens Troeger)
Date: Fri, 03 Aug 2018 10:54:08 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1533293648.54.0.56676864532.issue24218@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

So that?s interesting. I thought that setting `international = True` (see line https://github.com/python/cpython/blob/master/Lib/smtplib.py#L947) would be a neat workaround, but the opposite.

When delivering those emails to Gmail I started seeing 

    Failed to send email: (555, b'5.5.2 Syntax error, goodbye. s53-v6sm1864855qts.5 - gsmtp', 'foo at bar.com')

and it turns out (according to the IETF message linter, https://tools.ietf.org/tools/msglint/) that:

-----------
UNKNOWN: unknown header 'User-Agent' at line 4
ERROR: missing mandatory header 'date' lines 1-7
ERROR: missing mandatory header 'return-path' lines 1-7
OK: found part text/plain line 9
WARNING: line 13 too long (109 chars); text/plain shouldn't need folding (RFC 
         2046-4.1.1)
WARNING: line 15 too long (124 chars); text/plain shouldn't need folding (RFC 
         2046-4.1.1)
WARNING: Character set mislabelled as 'utf-8' when 'us-ascii' suffices, body 
         part ending line 22
-----------

It seems that now ?Date? and ?Return-Path? header entries are missing when the email is generated.

I reverted the initial change. Any updates on the multiple CR problem when flattening?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Fri Aug  3 08:11:17 2018
From: report at bugs.python.org (Marcel Plch)
Date: Fri, 03 Aug 2018 12:11:17 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533298277.7.0.56676864532.issue34325@psf.upfronthosting.co.za>


Change by Marcel Plch <gmarcel.plch at gmail.com>:


----------
keywords: +patch
pull_requests: +8151
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 08:39:35 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 12:39:35 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533299975.0.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I think there is an issue with pymain_run_file, in the new code of Victor, a file descriptor is not closed but I don't know why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 08:56:12 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 12:56:12 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533300972.75.0.56676864532.issue34326@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Maybe we can strace a failing test and cross check the opens and the closes to see which one is not being closed. Or monitor /proc/PID/fd while the test runs. I can investigate later today myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 09:02:16 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 13:02:16 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533301336.57.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Pablo, the main issue comes after this commit, you can strace the call 
for example 

./python -m unittest test.test_subprocess.POSIXProcessTestCase.test_pass_fds

on this test function and you will see than there is a opened file descriptor.

I tried to rewrite the patch of victor and see what was the difference, and there is no issue with pymain_run_stdin but I have the issue with pymain_run_file.

after that, I don't know how to find the leaked file.

Any idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 09:12:55 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 13:12:55 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533301975.04.0.56676864532.issue34329@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Good catch, thank you.
Could you sign the CLA, without the CLA, we can't process your PR.

Thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 09:33:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 13:33:57 +0000
Subject: [issue34301] Add _PyInterpreterState_Get() helper function
In-Reply-To: <1533081199.4.0.56676864532.issue34301@psf.upfronthosting.co.za>
Message-ID: <1533303237.05.0.56676864532.issue34301@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset caba55b3b735405b280273f7d99866a046c18281 by Victor Stinner in branch 'master':
bpo-34301: Add _PyInterpreterState_Get() helper function (GH-8592)
https://github.com/python/cpython/commit/caba55b3b735405b280273f7d99866a046c18281


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34301>
_______________________________________

From report at bugs.python.org  Fri Aug  3 09:35:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 13:35:06 +0000
Subject: [issue34301] Add _PyInterpreterState_Get() helper function
In-Reply-To: <1533081199.4.0.56676864532.issue34301@psf.upfronthosting.co.za>
Message-ID: <1533303306.88.0.56676864532.issue34301@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34301>
_______________________________________

From report at bugs.python.org  Fri Aug  3 09:59:56 2018
From: report at bugs.python.org (Stefan Otte)
Date: Fri, 03 Aug 2018 13:59:56 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533304796.68.0.56676864532.issue34329@psf.upfronthosting.co.za>


Stefan Otte <stefan.otte at gmail.com> added the comment:

I'm waiting for the CLA to be accepted. I'll get back to you ASAP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:01:47 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 14:01:47 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533304907.79.0.56676864532.issue34329@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

yep, it's a manual modification in b.p.o but after that, we can check your PR. thank you for your patience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:04:13 2018
From: report at bugs.python.org (Stefan Otte)
Date: Fri, 03 Aug 2018 14:04:13 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533305053.69.0.56676864532.issue34329@psf.upfronthosting.co.za>


Stefan Otte <stefan.otte at gmail.com> added the comment:

No problem, I'm just excited to contribute to python (as small as the contribution might be) :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:12:18 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 14:12:18 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533305538.95.0.56676864532.issue34329@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

It's the same thing for everything, for example, in Karate, you will start with the white belt and with practice, you will get the black belt.

Thank you again for your contribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:25:01 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 14:25:01 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533306301.18.0.56676864532.issue34329@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

This seems like a reasonable request. The feature was added in https://github.com/python/cpython/commit/e50dafcd636ba32db890600164698bb070d40d97 (issue 20639) in Python 3.4.

I'd normally suggest adding a ".. versionchanged:: 3.4" marker, but since the change is quite old and it's already in all of the current maintenance releases, I think we don't need to add it.

----------
nosy: +berker.peksag
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:36:57 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 03 Aug 2018 14:36:57 +0000
Subject: [issue32073] Add copy_directory_metadata parameter to shutil.copytree
In-Reply-To: <1511032407.02.0.213398074469.issue32073@psf.upfronthosting.co.za>
Message-ID: <1533307017.31.0.56676864532.issue32073@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What function raises ENOTSUPP exactly (traceback would be welcome)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32073>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:40:05 2018
From: report at bugs.python.org (=?utf-8?b?0JLQu9Cw0LQg0Jo=?=)
Date: Fri, 03 Aug 2018 14:40:05 +0000
Subject: [issue34330] The decode_header function does not always work
 correctly.
Message-ID: <1533307205.91.0.56676864532.issue34330@psf.upfronthosting.co.za>


New submission from ???? ? <kisly.va at gmail.com>:

The decode_header function does not always work correctly.

me at Serv:~$ python3
Python 3.6.5 (default, Apr  1 2018, 05:46:30)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.header import decode_header
>>> s = '=?windows-1251?B?zeDp5Oj46ujtINDu7ODtIMLr4OTo7Ojw7uLo9w==?=\r\n\t<Roman at mail.ru>'
>>> decode_header(s)
[(b'\xcd\xe0\xe9\xe4\xe8\xf8\xea\xe8\xed \xd0\xee\xec\xe0\xed \xc2\xeb\xe0\xe4\xe8\xec\xe8\xf0\xee\xe2\xe8\xf7', 'windows                                                                                                             -1251'), (b'<Roman at mail.ru>', None)]
>>> exit()

me at Serv:~$ python
Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.header import decode_header
>>> s = '=?windows-1251?B?zeDp5Oj46ujtINDu7ODtIMLr4OTo7Ojw7uLo9w==?=\r\n\t<Roman at mail.ru>'
>>> decode_header(s)
[('=?windows-1251?B?zeDp5Oj46ujtINDu7ODtIMLr4OTo7Ojw7uLo9w==?=\r\n\t<Roman at mail.ru>', None)]
>>> exit()

----------
components: email
messages: 323056
nosy: barry, r.david.murray, ???? ?2
priority: normal
severity: normal
status: open
title: The decode_header function does not always work correctly.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34330>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:52:06 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 03 Aug 2018 14:52:06 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1533307926.05.0.56676864532.issue34171@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

It seems that this file is left by test_trace after commit 47ab15470d72367694d7758004067313ae022f0e.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Fri Aug  3 10:57:10 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 03 Aug 2018 14:57:10 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1533308230.94.0.56676864532.issue31908@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

This change causes test_trace to leave a trace.cover file in the Lib directory (see #34171).

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Fri Aug  3 11:56:31 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 03 Aug 2018 15:56:31 +0000
Subject: [issue34331] Incorrectly pluralized abstract class error message
Message-ID: <1533311791.76.0.56676864532.issue34331@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

>>> class abstract(abc.ABC):
...     @abc.abstractmethod
...     def meth():
...         pass
...
>>> x()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't instantiate abstract class x with abstract methods meth

Error should be "Can't instantiate abstract class abstract with abstract method meth" in the singular, because there is only one abstract method.

----------
components: Interpreter Core, Library (Lib)
messages: 323059
nosy: Anjali Bansal, ppperry, rhettinger, serhiy.storchaka, terry.reedy, xtreak
priority: normal
severity: normal
status: open
title: Incorrectly pluralized abstract class error message
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34331>
_______________________________________

From report at bugs.python.org  Fri Aug  3 11:59:23 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 03 Aug 2018 15:59:23 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533311963.51.0.56676864532.issue34325@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 7b41dbad78c6b03ca2f98800a92a1977d3946643 by Petr Viktorin (Marcel Plch) in branch 'master':
bpo-34325: Skip zipfile test for large timestamps when filesystem don't support them. (GH-8656)
https://github.com/python/cpython/commit/7b41dbad78c6b03ca2f98800a92a1977d3946643


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 12:39:27 2018
From: report at bugs.python.org (Eric Fahlgren)
Date: Fri, 03 Aug 2018 16:39:27 +0000
Subject: [issue34252] Bunch of path leaks on Python 3.7 on Release
In-Reply-To: <1532721942.43.0.56676864532.issue34252@psf.upfronthosting.co.za>
Message-ID: <1533314367.92.0.56676864532.issue34252@psf.upfronthosting.co.za>


Eric Fahlgren <ericfahlgren at gmail.com> added the comment:

I believe that the CL command line switch is /FC, not /FP:

https://msdn.microsoft.com/en-us/library/027c4t2s.aspx

----------
nosy: +eric.fahlgren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34252>
_______________________________________

From report at bugs.python.org  Fri Aug  3 13:07:54 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 03 Aug 2018 17:07:54 +0000
Subject: [issue34312] Allow str.endswith and str.startswith to accept an
 iterable
In-Reply-To: <1533156462.08.0.56676864532.issue34312@psf.upfronthosting.co.za>
Message-ID: <1533316074.48.0.56676864532.issue34312@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34312>
_______________________________________

From report at bugs.python.org  Fri Aug  3 13:08:39 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 03 Aug 2018 17:08:39 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533316119.18.0.56676864532.issue32797@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan, petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Fri Aug  3 13:33:47 2018
From: report at bugs.python.org (Erik Bray)
Date: Fri, 03 Aug 2018 17:33:47 +0000
Subject: [issue34211] Cygwin build broken due to use of &PyType_Type in static
 declaration in _abc module
In-Reply-To: <1532451616.3.0.56676864532.issue34211@psf.upfronthosting.co.za>
Message-ID: <1533317627.92.0.56676864532.issue34211@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

> What makes functions different from variables? Aren't they essentially just pointers?

You're on the right track by noting a difference between functions and data variables.  I can tell you off the bat that when it comes to data imported from DLLs, non-functions are handled (somewhat by necessity) quite differently from functions.

That said, since you asked, I struggled to articulate *exactly* why this exact problem occurs on Cygwin (actually on Windows in general), so I thought about it for a while and wrote up an explanation in a blog post: http://iguananaut.net/blog/programming/windows-data-import.html

The TL;DR though is that limitations of how the runtime dynamic loader on Windows works are such that it's impossible to initialize static data with a pointer to some data in an external library.  The compiler knows this and prevents you from doing it.  The workaround is simple enough for most cases: Complete the initialization at runtime.  In the case of PyType_Type objects, PyType_Ready can set their base type at runtime just fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34211>
_______________________________________

From report at bugs.python.org  Fri Aug  3 14:56:25 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 18:56:25 +0000
Subject: [issue33161] Refactor of pathlib's _WindowsBehavior.gethomedir
In-Reply-To: <1522198041.64.0.467229070634.issue33161@psf.upfronthosting.co.za>
Message-ID: <1533322585.75.0.56676864532.issue33161@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the PR, but we usually avoid unnecessary churn in Python codebase.

Both versions look fine, and deciding which one to use is just a matter of personal taste.

----------
components:  -Windows
nosy: +berker.peksag -paul.moore, steve.dower, tim.golden, zach.ware
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33161>
_______________________________________

From report at bugs.python.org  Fri Aug  3 15:27:16 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 19:27:16 +0000
Subject: [issue34253] Tkinter- On windows,
 calling filedialog or messagebox before the window is drawn causes
 focus issues
In-Reply-To: <1532734093.09.0.56676864532.issue34253@psf.upfronthosting.co.za>
Message-ID: <1533324436.94.0.56676864532.issue34253@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You only need to run .update_idletasks(), as there are no pending events to process.

This is not a tkinter issue.  It is a known fact that there are undocumented annoying differences in tk behavior on different systems and even different versions thereof.  In #34275, for instance, we had to add .update_idletasks for IDLE calltips to appear on Macs with recent tk versions.

For Windows, your code also needs entry.focus_set to be able to enter text, after the mbox is dismissed, without activating the widget with a click.

Indeed, the call is needed here on Mac with Python 3.7.0 and tk 8.6.8.  Without it, the root window partially keeps the focus, in that the traffic lights remain light, and the messagebox only partially get the focus, in that the title and OK button are dimmed.  One has to click on the box to highlight the title and OK.  With the call, the root lights go out and the box is active, and can be dismissed with <Enter>.

There is an additional issue on current Mac.  When the mbox is dismissed, focus does not return properly to the root and entry.  They have to be clicked on.  Since this is similar to the problem in #34120, and since Novel's issue on Windows is exactly like the 'have to go away and come back' part of #34120, I wonder if the model mbox needs an explicit grab release.

Kevin, since the mbox is created and destroyed within a call to the tk messageBox function we have no control of its operation.  Perhaps you could check the tcl/tk code and see it if needs updating, as did the IDLE code.

----------
nosy: +serhiy.storchaka, terry.reedy, wordtech
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34253>
_______________________________________

From report at bugs.python.org  Fri Aug  3 15:28:12 2018
From: report at bugs.python.org (Happy Fakeboulder)
Date: Fri, 03 Aug 2018 19:28:12 +0000
Subject: [issue34332] Suggestion for a new loop type
Message-ID: <1533324492.86.0.56676864532.issue34332@psf.upfronthosting.co.za>


New submission from Happy Fakeboulder <weird1152 at gmail.com>:

A "while-except" loop, in which it acts like a do-while loop from other languages, except the condition is "did an exception occur during the execution of the iteration". One could specify a type of exception at the top, similar to an except block header. (sorry, I'm an idiot)
Example (the keyword might be different):

# asks for a number until the user gives one properly, then
# calculates the square of it.
whexc ValueError:
    num = int(input("Enter a number: "))
print("The square of your number is " + str(num * num)) # assuming whexc works, this will not cause an error

----------
messages: 323065
nosy: Happy Fakeboulder
priority: normal
severity: normal
status: open
title: Suggestion for a new loop type
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34332>
_______________________________________

From report at bugs.python.org  Fri Aug  3 15:47:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 19:47:21 +0000
Subject: [issue34256] Python treats ASCII record separator ('\x1e') as a
 newline
In-Reply-To: <1532772549.2.0.56676864532.issue34256@psf.upfronthosting.co.za>
Message-ID: <1533325641.56.0.56676864532.issue34256@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A database record is equivalent to a logical line, possible wrapped onto multiple physical lines. So it is plausible.

The 7643 in the test name refers to issue #7643, What is a Unicode line break character?"  It contains this:
"
> We may add some words to the documentation for str.splitlines() and bytes.splitlines() to explain what is considered a line break character.

For ASCII we should make the list of characters explicit.
For Unicode, we should mention the above definition and give
the table as example list (the Unicode database may add more
such characters in the future).
"
The test was added but the doc not.  I agree that it would be useful.  Feel free to suggest a doc change.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
title: Python treats ASCII record seperator ('\x1e') as a newline -> Python treats ASCII record separator ('\x1e') as a newline
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34256>
_______________________________________

From report at bugs.python.org  Fri Aug  3 15:52:12 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 03 Aug 2018 19:52:12 +0000
Subject: [issue34332] Suggestion for a new loop type
In-Reply-To: <1533324492.86.0.56676864532.issue34332@psf.upfronthosting.co.za>
Message-ID: <1533325932.45.0.56676864532.issue34332@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Ideas like this are better sent to the python-ideas at python.org mailing list for discussion rather than immediately opening an issue.  Note though that I think this has a low chance of acceptance; there's a very high bar to clear to add syntax, even higher for new keywords, and this doesn't seem to buy much over:

   while True:
       try:
           num = int(input("Enter a number: "))
       except ValueError:
           print("I said a *number*")
       else:
           break
   print("The square of your number is", num**2)

Especially considering that this version allows you to handle the error however you want, and handle different errors differently, rather than just silently restarting the loop no matter the error.

Also, this will be valid in 3.8 and achieve exactly what you're asking for:

   while not (ans := input("Enter a number: ")).isnumeric():
       pass
   print("The square of your number is", int(ans) ** 2)


Do feel free to send your idea to python-ideas anyway, I'm just one opinion :)

----------
nosy: +zach.ware
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34332>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:09:10 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 20:09:10 +0000
Subject: [issue34327] test_subprocess fails
In-Reply-To: <1533257731.89.0.56676864532.issue34327@psf.upfronthosting.co.za>
Message-ID: <1533326950.06.0.56676864532.issue34327@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
superseder:  -> test_subprocess.POSIXProcessTestCase fails in AMD64 Ubuntu 3.x

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34327>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:19:14 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:19:14 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533327554.42.0.56676864532.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8152

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:23:39 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 03 Aug 2018 20:23:39 +0000
Subject: [issue34126] Profiling certain invalid calls crashes Python
In-Reply-To: <1531761430.57.0.56676864532.issue34126@psf.upfronthosting.co.za>
Message-ID: <1533327819.6.0.56676864532.issue34126@psf.upfronthosting.co.za>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34126>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:25:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:25:08 +0000
Subject: [issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533327908.81.0.56676864532.issue34247@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8153

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:27:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:27:52 +0000
Subject: [issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533328072.07.0.56676864532.issue34247@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I first proposed to backport all code from master:
https://mail.python.org/pipermail/python-dev/2018-July/154882.html

But I'm not sure that it's a good idea, since I made *many* changes in the master branch since 3.7... I even added more files, and the _PyCoreConfig API is going to change anyway...

So I wrote a simpler PR 8659 which backports unit tests, adapt them for Python 3.7, and fix this issue: PYTHONOPTIMIZE and other environment variables and now read by Py_Initialize(), not only by Py_Main().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:34:49 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 03 Aug 2018 20:34:49 +0000
Subject: [issue34321] mmap.mmap() should not necessarily clone the file
 descriptor
In-Reply-To: <1533216123.68.0.56676864532.issue34321@psf.upfronthosting.co.za>
Message-ID: <1533328489.47.0.56676864532.issue34321@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Why would it "cause an issue if the file is closed before accessing the mmapped region"? As shown in your own link, the constructor performs the mmap call immediately after the descriptor is duplicated, with the GIL held; any race condition that could close the file before the mmap occurs could equally well close it before the descriptor is duplicated.

The possible issues aren't tied to accessing the memory (once the mapping has been performed, the file descriptor can be safely closed in general), but rather, to the size and resize methods of mmap objects (the former using the fd to fstat the file, the latter using it to ftruncate the file). As long as you don't use size/resize, nothing else depends on the file descriptor after construction has completed. The size method in particular seems like a strange wart on the API; it returns the total file size, not the size of the mapping (len(mapping) gets the size of the actual mapping).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34321>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:35:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:35:30 +0000
Subject: [issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533328530.01.0.56676864532.issue34247@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I tested manually attached t.c with PR 8659: I get optimize=2 as expected. Full output:

sys.flags(debug=0, inspect=0, interactive=0, optimize=2, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0, dev_mode=False, utf8_mode=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:41:07 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Aug 2018 20:41:07 +0000
Subject: [issue34331] Incorrectly pluralized abstract class error message
In-Reply-To: <1533311791.76.0.56676864532.issue34331@psf.upfronthosting.co.za>
Message-ID: <1533328867.5.0.56676864532.issue34331@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure the effort and code is justified for a trivial fix to an error message. Is this causing some actual problem?

----------
nosy: +eric.smith
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34331>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:45:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:45:08 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533329108.81.0.56676864532.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8154

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:45:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:45:08 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533329108.91.0.665841612001.issue34326@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8155
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:46:59 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 03 Aug 2018 20:46:59 +0000
Subject: [issue34331] Incorrectly pluralized abstract class error message
In-Reply-To: <1533311791.76.0.56676864532.issue34331@psf.upfronthosting.co.za>
Message-ID: <1533329219.02.0.56676864532.issue34331@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

No, this isn't causing me an actual problem, however the related issue34127 was accepted, and this one should be no harder to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34331>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:49:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 20:49:10 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533329350.2.0.56676864532.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5a953fd0ab4d0f792f4c1537616b2ce8ee40d976 by Victor Stinner in branch 'master':
bpo-34170: _PyCoreConfig_Read() don't replace coerce_c_locale (GH-8658)
https://github.com/python/cpython/commit/5a953fd0ab4d0f792f4c1537616b2ce8ee40d976


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:49:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 20:49:44 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533329384.56.0.56676864532.issue34329@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 46dc4e34ed8005a688d7f3512844ef227a3465f4 by Berker Peksag (Stefan Otte) in branch 'master':
bpo-34329: Doc'd how to remove suffix of pathlib.Path() (GH-8655)
https://github.com/python/cpython/commit/46dc4e34ed8005a688d7f3512844ef227a3465f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:50:29 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 20:50:29 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533329429.83.0.56676864532.issue34329@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8156

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:50:40 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Aug 2018 20:50:40 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533329440.62.0.56676864532.issue34329@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 16:56:38 2018
From: report at bugs.python.org (desbma)
Date: Fri, 03 Aug 2018 20:56:38 +0000
Subject: [issue32073] Add copy_directory_metadata parameter to shutil.copytree
In-Reply-To: <1511032407.02.0.213398074469.issue32073@psf.upfronthosting.co.za>
Message-ID: <1533329798.72.0.56676864532.issue32073@psf.upfronthosting.co.za>


desbma <dutch109 at gmail.com> added the comment:

Traceback is not very useful in that case:

mkdir /tmp/a
touch /tmp/a/b 

python
Python 3.6.6 (default, Jun 27 2018, 13:11:40) 
[GCC 8.1.1 20180531] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, shutil
>>> os.getcwd()
'/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C006%5D/sdcard1'
>>> shutil.copytree("/tmp/a", os.path.join(os.getcwd(), "test"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/desbma/py-venvs/main/lib/python3.6/shutil.py", line 359, in copytree
    raise Error(errors)
shutil.Error: [('/tmp/a/b', '/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C006%5D/sdcard1/test/b', '[Errno 95] Operation not supported'), ('/tmp/a', '/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C006%5D/sdcard1/test', '[Errno 95] Operation not supported')]
>>> shutil.copytree("/tmp/a", os.path.join(os.getcwd(), "test2"), copy_function=shutil.copy)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/desbma/py-venvs/main/lib/python3.6/shutil.py", line 359, in copytree
    raise Error(errors)
shutil.Error: [('/tmp/a/b', '/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C006%5D/sdcard1/test2/b', "[Errno 95] Operation not supported: '/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C006%5D/sdcard1/test2/b'"), ('/tmp/a', '/run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C006%5D/sdcard1/test2', '[Errno 95] Operation not supported')]

The exception is thrown from here https://github.com/python/cpython/blob/9bb6fe52742340f6c92f0dda18599a4577a94e18/Lib/shutil.py#L359

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32073>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:00:58 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Aug 2018 21:00:58 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533330058.45.0.56676864532.issue30317@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset f0e3da8814259283e8f3d53ad3d9735ffc273e00 by Pablo Galindo in branch '3.6':
bpo-30317: Fix multiprocessing test_timeout() (GH-8621)
https://github.com/python/cpython/commit/f0e3da8814259283e8f3d53ad3d9735ffc273e00


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:01:03 2018
From: report at bugs.python.org (desbma)
Date: Fri, 03 Aug 2018 21:01:03 +0000
Subject: [issue32073] Add copy_directory_metadata parameter to shutil.copytree
In-Reply-To: <1511032407.02.0.213398074469.issue32073@psf.upfronthosting.co.za>
Message-ID: <1533330063.4.0.56676864532.issue32073@psf.upfronthosting.co.za>


desbma <dutch109 at gmail.com> added the comment:

Note that in the examples above both copytree calls actually succeed (only metadata copy failed).

The user can disable file metadata copy by passing 'copy_function=shutil.copy', but there is no way to do the same for directories and the directory copystat call https://github.com/python/cpython/blob/9bb6fe52742340f6c92f0dda18599a4577a94e18/Lib/shutil.py#L353 fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32073>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:03:07 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:03:07 +0000
Subject: [issue34333] Path.with_suffix() raises TypeError when doing
 %-formatting
Message-ID: <1533330187.01.0.56676864532.issue34333@psf.upfronthosting.co.za>


New submission from Berker Peksag <berker.peksag at gmail.com>:

import pathlib

path = pathlib.Path('TR')
with_suffix = path.with_suffix(('/', '.md'))

The snippet I shared above will raise:

    TypeError: not all arguments converted during string formatting

While we are relying on duck typing, I think this can be considered as a bug in this case.

----------
assignee: berker.peksag
components: Library (Lib)
messages: 323078
nosy: berker.peksag, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Path.with_suffix() raises TypeError when doing %-formatting
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34333>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:07:43 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:07:43 +0000
Subject: [issue34333] Path.with_suffix() raises TypeError when doing
 %-formatting
In-Reply-To: <1533330187.01.0.56676864532.issue34333@psf.upfronthosting.co.za>
Message-ID: <1533330463.37.0.56676864532.issue34333@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8158
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34333>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:15:22 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 03 Aug 2018 21:15:22 +0000
Subject: [issue32773] distutils should NOT preserve timestamps
In-Reply-To: <1517846476.27.0.467229070634.issue32773@psf.upfronthosting.co.za>
Message-ID: <1533330922.02.0.56676864532.issue32773@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I started a discussion at https://mail.python.org/mm3/archives/list/distutils-sig at python.org/thread/4FHEGHZYWCDRWVPGYLAU5VUS5BAX73MO/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32773>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:21:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 21:21:57 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533331317.96.0.56676864532.issue34273@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The closest anchor is https://docs.python.org/3.8/library/string.html#format-specification-mini-language.

The table title is "The available presentation types for floating point and decimal values are:".

This is slightly confusing to me.  Does this mean instances of 'float' and 'decimal' classes?  or 'floating point numbers (floats and decimals)  and integral numbers, sometimes called decimals since usually written with decimal digits'?

Within the table, 'number' refers to whatever the title refers to. So I think adding '(floating point)' would be confusing and wrong, as it excludes 'decimals' whatever they are.  On the other hand, changing 'Fixed point' to 'Fixed point notation', in parallel with 'Exponential notation', is correct and should be helpful.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:25:43 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 03 Aug 2018 21:25:43 +0000
Subject: [issue32073] Add copy_directory_metadata parameter to shutil.copytree
In-Reply-To: <1511032407.02.0.213398074469.issue32073@psf.upfronthosting.co.za>
Message-ID: <1533331543.41.0.56676864532.issue32073@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

It's not clear where the exception originates from. Try to use copy2() instead of copytree().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32073>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:27:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:27:11 +0000
Subject: [issue26818] trace CLI doesn't respect -s option
In-Reply-To: <1461248919.65.0.631004346458.issue26818@psf.upfronthosting.co.za>
Message-ID: <1533331631.87.0.56676864532.issue26818@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8159

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26818>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:27:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:27:11 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1533331631.96.0.665841612001.issue31908@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8160

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:34:55 2018
From: report at bugs.python.org (desbma)
Date: Fri, 03 Aug 2018 21:34:55 +0000
Subject: [issue32073] Add copy_directory_metadata parameter to shutil.copytree
In-Reply-To: <1511032407.02.0.213398074469.issue32073@psf.upfronthosting.co.za>
Message-ID: <1533332095.62.0.56676864532.issue32073@psf.upfronthosting.co.za>


desbma <dutch109 at gmail.com> added the comment:

copy2 always raises "OSError: [Errno 95] Operation not supported" here https://github.com/python/cpython/blob/9bb6fe52742340f6c92f0dda18599a4577a94e18/Lib/shutil.py#L258 but I can work around that by passing copy_function=shutil.copy to copytree as I did above.

The problem is that there is currently no way to avoid the copystat call made on the directory itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32073>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:45:24 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:45:24 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533332724.31.0.56676864532.issue34329@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 764f9d09b03654d7cd70d59afafafd51d24f2750 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-34329: Doc'd how to remove suffix of pathlib.Path() (GH-8655)
https://github.com/python/cpython/commit/764f9d09b03654d7cd70d59afafafd51d24f2750


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:45:49 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:45:49 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533332749.88.0.56676864532.issue34329@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 39fcd9949832323b672f7ff05fd1498b8844a329 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-34329: Doc'd how to remove suffix of pathlib.Path() (GH-8655)
https://github.com/python/cpython/commit/39fcd9949832323b672f7ff05fd1498b8844a329


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:46:15 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:46:15 +0000
Subject: [issue34329] Document how to remove a suffix with
 pathlib.Path.with_suffix
In-Reply-To: <1533290285.58.0.56676864532.issue34329@psf.upfronthosting.co.za>
Message-ID: <1533332775.84.0.56676864532.issue34329@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34329>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:54:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 21:54:08 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533333248.3.0.56676864532.issue34326@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d8078626770a8d358eb83d7928c12d75ff4e821a by Victor Stinner in branch 'master':
bpo-34170: Fix pymain_run_file() (GH-8660)
https://github.com/python/cpython/commit/d8078626770a8d358eb83d7928c12d75ff4e821a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:54:08 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 21:54:08 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1533333248.45.0.902498594338.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d8078626770a8d358eb83d7928c12d75ff4e821a by Victor Stinner in branch 'master':
bpo-34170: Fix pymain_run_file() (GH-8660)
https://github.com/python/cpython/commit/d8078626770a8d358eb83d7928c12d75ff4e821a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:54:54 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 03 Aug 2018 21:54:54 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1533333294.21.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8161
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Fri Aug  3 17:56:35 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 21:56:35 +0000
Subject: [issue34279] RFC: issue a warning in regrtest when no tests have been
 executed?
In-Reply-To: <1532947707.98.0.56676864532.issue34279@psf.upfronthosting.co.za>
Message-ID: <1533333395.96.0.56676864532.issue34279@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A test file that runs no test functions should pass on the buildbots.  (If it imports the target file, it is not completely empty.  And I can think of a use case for WIP PRs that intentionally do not run anything.)  

But I also would like a visually different display, having been fooled more than once. For one thing, one can omit '(unittest.testCase)' from test class definitions ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34279>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:08:26 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 03 Aug 2018 22:08:26 +0000
Subject: [issue34331] Incorrectly pluralized abstract class error message
In-Reply-To: <1533311791.76.0.56676864532.issue34331@psf.upfronthosting.co.za>
Message-ID: <1533334106.8.0.56676864532.issue34331@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Actually, this one is probably easier to fix. In my opinion, #34127 is more important to fix, since it's seen much more often than the message about abstract base classes.

I wouldn't necessarily object to fixing this one, I just personally think it's not worth the hassle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34331>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:11:55 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 22:11:55 +0000
Subject: [issue34286] lib2to3 tests fail on the 3.7 branch (used to work with
 3.7.0)
In-Reply-To: <1533007091.73.0.56676864532.issue34286@psf.upfronthosting.co.za>
Message-ID: <1533334315.54.0.56676864532.issue34286@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

test_lib2to3 passes for me on Win 10 for both installed 3.7.0 (in home directory) and repository 3.7 (in clone directory) compiled yesterday.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34286>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:13:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 22:13:42 +0000
Subject: [issue30317] test_timeout() of
 test_multiprocessing_spawn.WithManagerTestBarrier fails randomly on x86
 Windows7 3.x buildbot
In-Reply-To: <1494345179.69.0.743787858569.issue30317@psf.upfronthosting.co.za>
Message-ID: <1533334422.37.0.56676864532.issue30317@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh. Now I understand why I'm confused. _test_multiprocessing.py in master has not less than 5 methods with the same name: test_timeout()!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30317>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:18:06 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 22:18:06 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533334686.6.0.56676864532.issue34296@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We are aware that startup time is a issue, especially for quick scripts.  I don't know if your ideas have been considered, so I added a couple of people who might.  The python-ideas list would likely be a better place for discussion until there is some idea about a concrete patch.

----------
nosy: +ncoghlan, terry.reedy, vstinner
type: enhancement -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:21:14 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 22:21:14 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533334874.68.0.56676864532.issue34326@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Thanks Victor, I don't know enough the API C-Python :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:24:37 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Aug 2018 22:24:37 +0000
Subject: [issue34297] Windows py.exe launcher fail to handle quote correctly
In-Reply-To: <1533058834.14.0.56676864532.issue34297@psf.upfronthosting.co.za>
Message-ID: <1533335077.71.0.56676864532.issue34297@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified this much:
F:\dev\37>py "-3" -m test.test_idle
(null): can't open file '3 -m test.test_idle': [Errno 2] No such file or directory

----------
components:  -Demos and Tools, Distutils
nosy: +eryksun, terry.reedy -dstufft, eric.araujo
stage:  -> test needed
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34297>
_______________________________________

From report at bugs.python.org  Fri Aug  3 18:31:31 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 03 Aug 2018 22:31:31 +0000
Subject: [issue34326] test_subprocess.POSIXProcessTestCase fails in AMD64
 Ubuntu 3.x
In-Reply-To: <1533254228.03.0.56676864532.issue34326@psf.upfronthosting.co.za>
Message-ID: <1533335491.38.0.56676864532.issue34326@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34326>
_______________________________________

From report at bugs.python.org  Fri Aug  3 19:09:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 23:09:07 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533337747.22.0.56676864532.issue34325@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The two buildbots are back to green.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 19:09:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 23:09:34 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533337774.96.0.56676864532.issue34097@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Tests are failed on some buildbots. See issue34325.

Marcel Plch already fixed it: commit 7b41dbad78c6b03ca2f98800a92a1977d3946643. The two buildbots are back to green.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Fri Aug  3 19:11:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2018 23:11:18 +0000
Subject: [issue34325] test_zipfile gets OverflowError in multiple buildbots
In-Reply-To: <1533253946.81.0.56676864532.issue34325@psf.upfronthosting.co.za>
Message-ID: <1533337878.91.0.56676864532.issue34325@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

A possible enhancement is to mock os.stat() instead of really modifying the real filesystem modification time, it would allow to test the bug on any platform. But I'm not sure that it's worth it, and if anyone is interested, I would suggest to discuss on bpo-34097.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34325>
_______________________________________

From report at bugs.python.org  Fri Aug  3 19:55:15 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 03 Aug 2018 23:55:15 +0000
Subject: [issue34256] Python treats ASCII record separator ('\x1e') as a
 newline
In-Reply-To: <1532772549.2.0.56676864532.issue34256@psf.upfronthosting.co.za>
Message-ID: <1533340515.32.0.56676864532.issue34256@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

What documentation were you looking at? I remember adding 0x1E and others to the list in Issue 12855. See <https://docs.python.org/3.5/library/stdtypes.html#str.splitlines>:

???
str.splitlines([keepends])
  . . .
  
  This method splits on the following line boundaries. . . .
  
  Representation  Description
  ==============  ===========
  . . .
  \x1e            Record Separator
  . . .
???

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34256>
_______________________________________

From report at bugs.python.org  Fri Aug  3 20:37:25 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 04 Aug 2018 00:37:25 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533343045.22.0.56676864532.issue34296@psf.upfronthosting.co.za>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Sat Aug  4 03:41:45 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Aug 2018 07:41:45 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533368505.23.0.56676864532.issue34296@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It isn't currently feasible to do anything along these lines, as the CPython runtime is highly configurable, so it's far from clear what, if anything, could be shared from run to run, and nor is it clear how the interpreter could check whether or not the current configuration settings matched those of the pre-warmed one.

However, the work taking place for PEP 432 (issue dependency added) will potentially make it possible to revisit this, as there may be a way to cache preconfigured interpreters in a fashion that means calculating the cache key from the current configuration and then loading the cached interpreter state is faster that imperatively initialising a fresh interpreter.

Even if it isn't possible to cache an entire interpreter state, there may at least be opportunities to optimise particular configuration substeps.

----------
dependencies: +PEP 432: Redesign the interpreter startup sequence

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Sat Aug  4 03:51:47 2018
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Sat, 04 Aug 2018 07:51:47 +0000
Subject: [issue34331] Incorrectly pluralized abstract class error message
In-Reply-To: <1533311791.76.0.56676864532.issue34331@psf.upfronthosting.co.za>
Message-ID: <1533369107.96.0.56676864532.issue34331@psf.upfronthosting.co.za>


Change by Daniel Andrade Groppe <dagroppe at gmail.com>:


----------
keywords: +patch
pull_requests: +8162
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34331>
_______________________________________

From report at bugs.python.org  Sat Aug  4 03:53:14 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 04 Aug 2018 07:53:14 +0000
Subject: [issue34332] Suggestion for a new loop type
In-Reply-To: <1533324492.86.0.56676864532.issue34332@psf.upfronthosting.co.za>
Message-ID: <1533369194.13.0.56676864532.issue34332@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

You can also use a context manager and the `with` statement.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34332>
_______________________________________

From report at bugs.python.org  Sat Aug  4 06:08:13 2018
From: report at bugs.python.org (Adrian Dries)
Date: Sat, 04 Aug 2018 10:08:13 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
Message-ID: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>


New submission from Adrian Dries <adries at gmail.com>:

Since Python 3.7 logging.handlers.QueueHandler logs tracebacks twice::


>>> import logging
>>> from logging.handlers import QueueHandler, QueueListener
>>> from queue import Queue
>>> q = Queue()
>>> logging.getLogger().addHandler(QueueHandler(q))
>>> listener = QueueListener(q, logging.StreamHandler())
>>> listener.start()
>>> try: 1/0
... except: logging.exception('Look out!')
... 
Look out!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero


Patching QueueHandler.prepare() to set exc_text to None seems to fix this.

----------
components: Library (Lib)
messages: 323100
nosy: avdd
priority: normal
severity: normal
status: open
title: QueueHandler logs exc_info twice
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Sat Aug  4 07:36:11 2018
From: report at bugs.python.org (Erik Janssens)
Date: Sat, 04 Aug 2018 11:36:11 +0000
Subject: [issue20596] Support for alternate wcstok syntax for Windows compilers
In-Reply-To: <1392123816.37.0.457546149708.issue20596@psf.upfronthosting.co.za>
Message-ID: <1533382571.16.0.56676864532.issue20596@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

Would anyone mind if I create a new issue to reflect the current situation and create a PR to handle it with a Py_WCSTOK ?

----------
nosy: +erikjanss

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20596>
_______________________________________

From report at bugs.python.org  Sat Aug  4 07:54:17 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Aug 2018 11:54:17 +0000
Subject: [issue33898] pathlib issues with Windows device paths
In-Reply-To: <1529361630.0.0.56676864532.issue33898@psf.upfronthosting.co.za>
Message-ID: <1533383657.1.0.56676864532.issue33898@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8163
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33898>
_______________________________________

From report at bugs.python.org  Sat Aug  4 08:53:01 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 04 Aug 2018 12:53:01 +0000
Subject: [issue28009] core logic of uuid.getnode() is broken for AIX - all
 versions
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1533387181.36.0.56676864532.issue28009@psf.upfronthosting.co.za>


Change by Michael Felt <michael at felt.demon.nl>:


----------
pull_requests: +8164

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28009>
_______________________________________

From report at bugs.python.org  Sat Aug  4 09:08:41 2018
From: report at bugs.python.org (Michael Fischer)
Date: Sat, 04 Aug 2018 13:08:41 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533388121.91.0.56676864532.issue34273@psf.upfronthosting.co.za>


Michael Fischer <michael-fischer89 at web.de> added the comment:

Terry: I absolutely agree with you. Changing 'Fixed point' to 'Fixed point notation' is the optimal solution here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Sat Aug  4 09:10:34 2018
From: report at bugs.python.org (tzickel)
Date: Sat, 04 Aug 2018 13:10:34 +0000
Subject: [issue34172] multiprocessing.Pool and ThreadPool leak resources after
 being deleted
In-Reply-To: <1532105129.76.0.56676864532.issue34172@psf.upfronthosting.co.za>
Message-ID: <1533388234.49.0.56676864532.issue34172@psf.upfronthosting.co.za>


tzickel <icebreak at yahoo.com> added the comment:

It actually makes tons of sense that while the thread is running, that the object representing it is alive. After the thread finishes its work, the object dies.

>>> import time, threading, weakref, gc
>>> t = threading.Thread(target=time.sleep, args=(10,))
>>> wr = weakref.ref(t)
>>> t.start()
>>> del t
>>> gc.collect()
>>> wr()
<Thread(Thread-1, started 139937234327296)>
Wait 10 seconds...
>>> gc.collect()
>>> wr()

The thread is gone (which doesn't happen with the pool).

Anyhow, I've submitted a patch to fix the bug that was introduced 9 years ago on GH, feel free to check it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34172>
_______________________________________

From report at bugs.python.org  Sat Aug  4 09:40:17 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Aug 2018 13:40:17 +0000
Subject: [issue34172] multiprocessing.Pool and ThreadPool leak resources after
 being deleted
In-Reply-To: <1532105129.76.0.56676864532.issue34172@psf.upfronthosting.co.za>
Message-ID: <1533390017.0.0.56676864532.issue34172@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks a lot tzickle, I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34172>
_______________________________________

From report at bugs.python.org  Sat Aug  4 09:59:44 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Sat, 04 Aug 2018 13:59:44 +0000
Subject: [issue21914] Create unit tests for Turtle guionly
In-Reply-To: <1404442037.11.0.611165319303.issue21914@psf.upfronthosting.co.za>
Message-ID: <1533391184.16.0.56676864532.issue21914@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hey Rajalakshmi,

Are you still working on this issue? Is there anything we can help you with?

----------
nosy: +CuriousLearner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21914>
_______________________________________

From report at bugs.python.org  Sat Aug  4 10:17:50 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Aug 2018 14:17:50 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533392270.13.0.56676864532.issue32797@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This problem isn't unique to Cython extension modules - it exists for pyc-only distribution of pure Python files as well.

The underlying problem is that we don't currently have a mechanism comparable to JavaScript source maps, whereby a preprocessed runtime artifact can provide a reference back to a more debugging-friendly representation that's stored somewhere else (whether that's adjacent to the compiled form, in a different directory elsewhere on the same machine, or even on a remote web server).

So I think asking how ExtensionFileLoader.get_source() should behave is likely looking at the problem at the wrong level: a better question may be to ask what feature *linecache* is missing to allow it to correctly report source lines for modules that do *not* include their source code when installed, but do have that source code available in a shadow directory, where the only things that change are the root location (which could potentially even be a HTTP or HTTPS URL), and a fixed transformation on the module filename itself (e.g. replacing "*.so" with "*.c", or "*.pyc" with "*.py").

Given such a feature in Python 3.8, and support for it in Cython, the enhanced linecache module could then be published to PyPI as backports.linecache, providing access to this improved behaviour on all Python 3 versions that SageMath wants to support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 10:35:15 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Aug 2018 14:35:15 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533393315.26.0.56676864532.issue32797@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As a completely minimal strawman design that's the closest fit to what SafeMath is already doing: what if there was a "linecache.fallback_source_path" attribute that linecache searched with importlib whenever a loader returned None to indicate that the module existed, but not in a format that provided source code?

Then instead of adding the source directory to sys.path (which was only working because the legacy import system never implemented PEP 302 properly), SageMath could instead add the source directory to that new linecache.fallback_source_path list.

(Given a separate linecache.fallback_metapath, a suitably clever Finder implementation could then even provide the URL source lookup feature)

There'd be some API design issues to work out around ensuring that directories added to linecache.fallback_source_path are added in the same relative order as directories on sys.path, but the end result would likely be more reliable and resilient than relying on "additional directory installed later in sys.path" as the fallback strategy for handling sourceless modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 10:37:03 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 04 Aug 2018 14:37:03 +0000
Subject: [issue34194] test_ssl, AIX, and defaults for _ssl connections
In-Reply-To: <1532328016.0.0.56676864532.issue34194@psf.upfronthosting.co.za>
Message-ID: <1533393423.72.0.56676864532.issue34194@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

I "guess" it is somewhere in this code. But I am getting lost in all the macros that call other macros.

Some help would really be appreciated!

Currently looking in _ssl.c at:

/*[clinic input]
_ssl.get_default_verify_paths

Return search paths and environment vars that are used by SSLContext's set_default_verify_paths() to load defa
ult CAs.

The values are 'cert_file_env', 'cert_file', 'cert_dir_env', 'cert_dir'.
[clinic start generated code]*/

static PyObject *
_ssl_get_default_verify_paths_impl(PyObject *module)
/*[clinic end generated code: output=e5b62a466271928b input=5210c953d98c3eb5]*/
{
    PyObject *ofile_env = NULL;
    PyObject *ofile = NULL;
    PyObject *odir_env = NULL;
    PyObject *odir = NULL;

#define CONVERT(info, target) { \
        const char *tmp = (info); \
        target = NULL; \
        if (!tmp) { Py_INCREF(Py_None); target = Py_None; } \
        else if ((target = PyUnicode_DecodeFSDefault(tmp)) == NULL) { \
            target = PyBytes_FromString(tmp); } \
        if (!target) goto error; \
    }

    CONVERT(X509_get_default_cert_file_env(), ofile_env);
    CONVERT(X509_get_default_cert_file(), ofile);
    CONVERT(X509_get_default_cert_dir_env(), odir_env);
    CONVERT(X509_get_default_cert_dir(), odir);
#undef CONVERT

    return Py_BuildValue("NNNN", ofile_env, ofile, odir_env, odir);

  error:
    Py_XDECREF(ofile_env);
    Py_XDECREF(ofile);
    Py_XDECREF(odir_env);
    Py_XDECREF(odir);
    return NULL;
}

What I would like to know is what environment variable is being used. Not clear to me from the code here.

Thx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34194>
_______________________________________

From report at bugs.python.org  Sat Aug  4 11:01:25 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 04 Aug 2018 15:01:25 +0000
Subject: [issue13574] refresh example in doc for Extending and Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1533394885.07.0.56676864532.issue13574@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The documentation has been modernized in https://github.com/python/cpython/commit/1d80a561734b9932961c546b0897405a3bfbf3e6 and the "Weak Reference Support" section has been updated to show the modern way of adding weakref support:

    https://github.com/python/cpython/commit/1d80a561734b9932961c546b0897405a3bfbf3e6#diff-1ace1cc14bb5b7f4ee77f22238ede084R556

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13574>
_______________________________________

From report at bugs.python.org  Sat Aug  4 11:34:15 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 04 Aug 2018 15:34:15 +0000
Subject: [issue33736] Improve the documentation of asyncio stream API
In-Reply-To: <1528472164.69.0.592728768989.issue33736@psf.upfronthosting.co.za>
Message-ID: <1533396855.17.0.56676864532.issue33736@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33736>
_______________________________________

From report at bugs.python.org  Sat Aug  4 11:44:41 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Aug 2018 15:44:41 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1533397481.74.0.56676864532.issue34284@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looking at the code in https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Python/sysmodule.c#L2360, I think the underlying problem here is that the code to make these PyStructSequence subclasses uninstantiable isn't really right - rather than clearing those fields in the subclass (which still allows dynamic method lookup to fall back to the parent class, even though fast C level dispatch fails), it would be more consistent and reliable to replace them with implementations that always raise a TypeError with a suitable message.

(An alternative may be to implement the same behaviour as the builtin singleton types used for None and Ellipsis: replace __new__ with an implementation that always returns the original singleton instance. However, there isn't a compelling use case, so raising a descriptive exception along the lines of what ppperry suggests seems most appropriate)

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34284>
_______________________________________

From report at bugs.python.org  Sat Aug  4 11:46:54 2018
From: report at bugs.python.org (Andrey Vlasovskikh)
Date: Sat, 04 Aug 2018 15:46:54 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1533397614.09.0.56676864532.issue1230540@psf.upfronthosting.co.za>


Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> added the comment:

> Would it be possible to modify the default implementation of sys.excepthook to have a different output when it's not called from the main thread? Mimick the current traceback from threads.

I agree it's a good idea to mimic what `_thread` does in case of both handled and unhandled exceptions. Why would you want to do it in `sys.excepthook`? The code for handling unhandled exceptions in `_thread` threads is located in `_threadmodule.c` itself, so there is no dependency from `sys` to `_thread`. By following the same logic, the code for handling unhandled exceptions in `threading` should be located in `threading.py`, like it does now. So the only thing that's missing in the pull request compared to `_thread` is the output:

   Unhandled exception in thread started by <function <lambda> at 0x7f6769ca8e18>


for all the exceptions: not caught by the sys.excepthook **and** caught by the sys.exceptook.

> An alternative would be to introduce a new hook to log exceptions in threads, ex: sys.threadexcepthook. That hoook would take a 4th parameter. But Andrey Vlasovskikh didn't like this idea.

I'm overall OK with this idea, but I would prefer to make the existing `sys.excepthook` API applicable to all the exceptions: for the main thread (works well), for `_thread` threads (works well) and for `threading` threads (doesn't work).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Sat Aug  4 12:06:27 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 04 Aug 2018 16:06:27 +0000
Subject: [issue34309] Trouble when reloading extension modules.
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533398787.68.0.56676864532.issue34309@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As others have noted, dynamically reloading CPython extension modules is akin to dynamically reloading any other C/C++ shared library, so it has enough opportunities for things to go wrong that we consider allowing the shared state to persist across initialize/finalize cycles the less problematic of two problematic options (at least for now).

Reliable hot reloading support is typically a property of pure Python modules (and even at that higher level, inter-module dependencies can still cause problems at runtime).

(FWIW, this problem is currently also the main reason we don't offer an in-REPL package installation command - while PEP 489 offers significant opportunities for improvement, it's likely to be years before we see widespread adoption of that, so we prefer to advise folks to run an installer outside the REPL, then restart and replay their interactive session)

If subinterpreters are an option though, then yeah, that has far more potential to be viable. It wouldn't be trivial, as we'd need to add dlmopen support (thanks Stack Overflow [1]) to give the subinterpreter a truly independent copy of the shared library (and also work out whatever the equivalent to dlmopen might be on other platforms), but going down that path could also potentially provide a way around the known problems with global state leaking between subinterpreters via extension modules.

[1] https://stackoverflow.com/questions/48864659/loading-shared-library-twice/48888598#48888598

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Sat Aug  4 12:25:38 2018
From: report at bugs.python.org (ppperry)
Date: Sat, 04 Aug 2018 16:25:38 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1533399938.09.0.56676864532.issue34284@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

The problem doesn't just happen with `sys.flags`, though. It happens with all types that can't be created directly by python. Ex: frame objects, generators, cells, etc. The bug is that in types whose c-level tp_new is null, the python-level __new__ is inherited from the superclass (and since object defines a `__new__`, such a function always exists), instead of being defined to always raise an error, like calling the type directly does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34284>
_______________________________________

From report at bugs.python.org  Sat Aug  4 13:17:22 2018
From: report at bugs.python.org (Martin Altmayer)
Date: Sat, 04 Aug 2018 17:17:22 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1533403042.76.0.56676864532.issue33649@psf.upfronthosting.co.za>


Change by Martin Altmayer <martin.altmayer at web.de>:


----------
nosy: +MartinAltmayer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Sat Aug  4 13:36:26 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 04 Aug 2018 17:36:26 +0000
Subject: [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1533404186.4.0.56676864532.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Status update: I'm working on a first rewrite. I expect to have something to review on a couple of weeks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33649>
_______________________________________

From report at bugs.python.org  Sat Aug  4 13:39:49 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 04 Aug 2018 17:39:49 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533404389.7.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Then instead of adding the source directory to sys.path

What's wrong with that? Installing the .pyx sources together with the .so compiled modules makes a lot of sense to me: it is very analogous to installing the .py sources together with the .pyc byte-compiled files. In https://bugs.python.org/issue32797#msg315965 Paul Moore disagreed with that analogy, but I don't quite understand why.

And if ${prefix}/lib/pythonX.Y/site-packages/PKGNAME is not a good place to store the installed sources, where would you want to install them otherwise?

> (which was only working because the legacy import system never implemented PEP 302 properly)

Not sure what you mean here...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 14:01:00 2018
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sat, 04 Aug 2018 18:01:00 +0000
Subject: [issue23876] Fix mkdir() call for Watcom compilers on UNIX-like
 platforms
In-Reply-To: <1428324075.5.0.672514551353.issue23876@psf.upfronthosting.co.za>
Message-ID: <1533405660.6.0.56676864532.issue23876@psf.upfronthosting.co.za>


Change by Jeffrey Armstrong <jeffrey.armstrong at approximatrix.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23876>
_______________________________________

From report at bugs.python.org  Sat Aug  4 14:25:00 2018
From: report at bugs.python.org (Paul Moore)
Date: Sat, 04 Aug 2018 18:25:00 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533407100.28.0.56676864532.issue32797@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

> What's wrong with that? Installing the .pyx sources together with the .so compiled modules makes a lot of sense to me: it is very analogous to installing the .py sources together with the .pyc byte-compiled files. In https://bugs.python.org/issue32797#msg315965 Paul Moore disagreed with that analogy, but I don't quite understand why.

Because if someone deletes the .pyc file, the interpreter can (and will) regenerate it using the .py file. If someone deletes the .so file, you're stuck. Having the .pyx file present won't help you.

In my view (and that of the documentation for sys.path), sys.path is where you put things that the Python interpreter can load - .so files, .pyc files and .py files.

Looking for source to report as part of a traceback is a separate process, and there's no immediate reason why it should involve sys.path. The fact that historically it did (because that worked for pure Python modules that shipped with source) doesn't mean it's the right solution. I'd rather see a well-designed protocol for "find me the source for this module" that tools like Cython can support, than trying to patch up the loader protocol and sys.path to do something they weren't ever designed for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 14:52:55 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 04 Aug 2018 18:52:55 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533408775.28.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> In my view (and that of the documentation for sys.path), sys.path is where you put things that the Python interpreter can load - .so files, .pyc files and .py files.

It's quite typical for packages to install stuff in site-packages which the interpreter cannot load. In fact, that's the exactly the point of the package_data argument to setup(), see https://packaging.python.org/guides/distributing-packages-using-setuptools/#package-data

Just as an example, Numpy installs tons of stuff inside site-packages/numpy/ (header files, configuration files, data files for the testsuite)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 15:22:32 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Aug 2018 19:22:32 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533410552.17.0.56676864532.issue34273@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +8165
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Sat Aug  4 15:48:24 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Sat, 04 Aug 2018 19:48:24 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
In-Reply-To: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>
Message-ID: <1533412104.41.0.56676864532.issue33187@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hello Anjali,

As far as I remember, you started this in a PyDelhi Dev Sprint. So, just wanted to check around, if you're looking for any help :)

----------
nosy: +CuriousLearner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Sat Aug  4 16:15:38 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 04 Aug 2018 20:15:38 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1533408775.28.0.56676864532.issue32797@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W5k4uP5UNDtONYshaBwfTqAG2R6tVHD+wNKsvFwC_t+KQ@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sat, Aug 4, 2018, 11:52 Jeroen Demeyer, <report at bugs.python.org> wrote:

>
> Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:
>
> > In my view (and that of the documentation for sys.path), sys.path is
> where you put things that the Python interpreter can load - .so files, .pyc
> files and .py files.
>
> It's quite typical for packages to install stuff in site-packages which
> the interpreter cannot load. In fact, that's the exactly the point of the
> package_data argument to setup(), see
> https://packaging.python.org/guides/distributing-packages-using-setuptools/#package-data
>
> Just as an example, Numpy installs tons of stuff inside
> site-packages/numpy/ (header files, configuration files, data files for the
> testsuite)
>

I think the key point no one is saying is that .pyc files are no longer on
sys.path because they are in __pycache__ and those aren't importable unless
you access them as namespace packages. So we have been moving to keeping
artifacts like .pyc files off of sys.path.

As Nick said, we have no generalized concept of source maps and I think
coming up with that is what will be required to solve this as i personally
don't view Loader.get_source() is not meant to be a generalized concept of
some form of source code but Python source code.

> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32797>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 16:33:19 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 04 Aug 2018 20:33:19 +0000
Subject: [issue26171] heap overflow in zipimporter module
In-Reply-To: <1453348353.03.0.314168195173.issue26171@psf.upfronthosting.co.za>
Message-ID: <1533414799.41.0.56676864532.issue26171@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26171>
_______________________________________

From report at bugs.python.org  Sat Aug  4 17:47:48 2018
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 04 Aug 2018 21:47:48 +0000
Subject: [issue33731] string formatting that produces floats with preset
 precision while respecting locale
In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za>
Message-ID: <1533419268.35.0.56676864532.issue33731@psf.upfronthosting.co.za>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33731>
_______________________________________

From report at bugs.python.org  Sat Aug  4 18:07:37 2018
From: report at bugs.python.org (James Emerton)
Date: Sat, 04 Aug 2018 22:07:37 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1533420457.82.0.56676864532.issue34311@psf.upfronthosting.co.za>


Change by James Emerton <james at emerton.info>:


----------
keywords: +patch
pull_requests: +8166
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Sat Aug  4 18:12:52 2018
From: report at bugs.python.org (James Emerton)
Date: Sat, 04 Aug 2018 22:12:52 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1533420772.33.0.56676864532.issue34311@psf.upfronthosting.co.za>


Change by James Emerton <james at emerton.info>:


----------
pull_requests:  -8166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Sat Aug  4 18:14:21 2018
From: report at bugs.python.org (James Emerton)
Date: Sat, 04 Aug 2018 22:14:21 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1533420861.81.0.56676864532.issue34311@psf.upfronthosting.co.za>


James Emerton <james at emerton.info> added the comment:

It looks like a bot got a bit excited when I mentioned this issue in the PR for bpo-33731. I unlinked the PR but this issue still got flagged for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Sat Aug  4 18:56:22 2018
From: report at bugs.python.org (Mikhail Terekhov)
Date: Sat, 04 Aug 2018 22:56:22 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
Message-ID: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>


New submission from Mikhail Terekhov <termim at gmail.com>:

Couple of examples in in asyncio documentation mix @asyncio.coroutine decorator and await.

----------
components: asyncio
messages: 323121
nosy: asvetlov, termim, yselivanov
priority: normal
severity: normal
status: open
title: Fix examples in asyncio docs (suppliment to bpo-32258)
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Sat Aug  4 19:05:34 2018
From: report at bugs.python.org (Mikhail Terekhov)
Date: Sat, 04 Aug 2018 23:05:34 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
In-Reply-To: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>
Message-ID: <1533423934.44.0.56676864532.issue34335@psf.upfronthosting.co.za>


Change by Mikhail Terekhov <termim at gmail.com>:


----------
keywords: +patch
pull_requests: +8167
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Sat Aug  4 19:05:34 2018
From: report at bugs.python.org (Mikhail Terekhov)
Date: Sat, 04 Aug 2018 23:05:34 +0000
Subject: [issue32258] Rewrite asyncio docs to use async/await syntax
In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>
Message-ID: <1533423934.54.0.665841612001.issue32258@psf.upfronthosting.co.za>


Change by Mikhail Terekhov <termim at gmail.com>:


----------
pull_requests: +8168

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Sat Aug  4 19:07:04 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 04 Aug 2018 23:07:04 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533424024.49.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

To everybody who mentioned that Cython sources don't belong on sys.path: where *do* they belong then?

One issue which hasn't been mentioned before is packaging. By installing Cython sources along with the generated .so files, we can re-use all the existing tooling from distutils/setuptools/wheel to install those source files. If we want to install them in a different way, ideally it should be done in a way sanctioned by the PyPA and the tools should support it. We should then also change linecache to search for source files in that directory.

Unless somebody can come up with a simple suggestion, this seems to require basically a PEP. I don't plan to write that PEP and fight for it, since this can easily be fixed with essentially a 1-line patch to linecache, as I proposed in https://github.com/python/cpython/pull/6653

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 19:48:49 2018
From: report at bugs.python.org (Martin Panter)
Date: Sat, 04 Aug 2018 23:48:49 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment, ?query,
 //netloc
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1533426529.58.0.56676864532.issue22852@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I like this option. I suppose choosing which option to take is a compromise between compatiblity and simplicity. In the short term, the ?allows_none? option requires user code to be updated. In the long term it may break compatibility. But the ?has_netloc? etc option is more complex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Sat Aug  4 20:06:02 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 05 Aug 2018 00:06:02 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1533424024.49.0.56676864532.issue32797@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W4rJhh+rhb-GV09YnGA1OqNT_sLxFf8RUgQP_XyDzbRjA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sat, Aug 4, 2018, 16:07 Jeroen Demeyer, <report at bugs.python.org> wrote:

>
> Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:
>
> To everybody who mentioned that Cython sources don't belong on sys.path:
> where *do* they belong then?
>

In a subdirectory similar to __pycache__.

> One issue which hasn't been mentioned before is packaging. By installing
> Cython sources along with the generated .so files, we can re-use all the
> existing tooling from distutils/setuptools/wheel to install those source
> files.

Technically this doesn't fall under our purview but that of distutils-sig.
Plus how distutils or setuptools do anything is an implementation detail
and it's more important how a wheel would handle this (if any special
support is even necessary). Remember, PEP 517 us our future and is there to
break the monopoly of setuptools.

If we want to install them in a different way, ideally it should be done in
> a way sanctioned by the PyPA and the tools should support it. We should
> then also change linecache to search for source files in that directory.
>

Yep.

> Unless somebody can come up with a simple suggestion, this seems to
> require basically a PEP.

Or at least a new API.

I don't plan to write that PEP and fight for it, since this can easily be
> fixed with essentially a 1-line patch to linecache, as I proposed in
> https://github.com/python/cpython/pull/6653
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32797>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sat Aug  4 20:35:57 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 05 Aug 2018 00:35:57 +0000
Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1533429357.04.0.56676864532.issue24937@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

It would be nice to remove PyCObject_* entries from Doc/data/refcounts.dat.

+.. _documentation: http://py3c.readthedocs.org/en/latest/capsulethunk.html

Nit: We could the HTTPS link.

----------
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24937>
_______________________________________

From report at bugs.python.org  Sat Aug  4 20:57:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 05 Aug 2018 00:57:44 +0000
Subject: [issue6952] deprecated conversion from string constant to char *
In-Reply-To: <1253446186.78.0.0648542984315.issue6952@psf.upfronthosting.co.za>
Message-ID: <1533430664.29.0.56676864532.issue6952@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

All changes (except PyUnicode_EncodeDecimal() which was deprecated in Python 3.3) have already been implemented in the following commits:

* https://github.com/python/cpython/commit/c679227e31245b0e8dec74a1f7cc77710541d985
* https://github.com/python/cpython/commit/f308132cc29eea9b7fe899deb575d29d607a48f4
* https://github.com/python/cpython/commit/f0b463ad845c7433a0c561ef2c71d350f4b508c5

Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6952>
_______________________________________

From report at bugs.python.org  Sat Aug  4 21:53:12 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Aug 2018 01:53:12 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1533433992.22.0.56676864532.issue34284@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed, but it's still a definition time bug, as the types are only nulling out tp_new after creating the singleton instance, and not preventing __new__ from resolving.

If they *don't* null out tp_new, but instead set tp_new to a common helper function that raises "TypeError: Cannot create <type name> instances", that will both prevent __new__ from working, and also ensure that `type(obj)()` and `type(obj).__new__()` give the same error.

(Changing the applicable version, as this issues combines a relatively obscure error reporting issue with a relatively intrusive fix, so the risk/reward ratio pushes it towards being a Python 3.8 only change).

----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34284>
_______________________________________

From report at bugs.python.org  Sat Aug  4 22:26:50 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Aug 2018 02:26:50 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533436010.73.0.56676864532.issue32797@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Regarding PEP 302 compliance: until Python 3.3, the builtin import system wasn't present on sys.metapath - it was its own implicit legacy thing. The change in Python 3.3 was to fix that, and make it work based on a handful of default sys.metapath entries. Not coincidentally, 3.3 was also the first release where the import system was finally added to the language reference rather than being wholly implementation dependent: https://docs.python.org/3/reference/import.html

I think that also points the way forward for providing a useful import spec compliant fallback for sourceless files in linecache in a way that could be backported to earlier Python 3 versions: it's possible to create a FileFinder [1] instance that only looks for source files, and ignores files that don't provide source code.

Given that, the changes needed to make SageMath tracebacks "just work" the way they currently do in Python 2 would be:

1. Enhance PathFinder [2] to allow specification of which path importer cache and path_hooks entries to use
2. Set up a source-only metapath in linecache with a single default entry: a PathFinder configured with a source-only FileFinder instance as a path hook
3. Fall back to the source-only metapath if the main import system indicates the module is being loaded from a sourceless format.

[1] https://docs.python.org/3/library/importlib.html#importlib.machinery.FileFinder
[2] https://docs.python.org/3/library/importlib.html#importlib.machinery.PathFinder

----------
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 01:03:04 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Aug 2018 05:03:04 +0000
Subject: [issue34330] The decode_header function does not always work
 correctly.
In-Reply-To: <1533307205.91.0.56676864532.issue34330@psf.upfronthosting.co.za>
Message-ID: <1533445384.28.0.56676864532.issue34330@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34330>
_______________________________________

From report at bugs.python.org  Sun Aug  5 01:51:09 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 05 Aug 2018 05:51:09 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533448269.57.0.56676864532.issue32797@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

FWIW, I can see that Cython is a special case because it can control the source line mapping and reporting through the C-API. Other code generators might not be able to do that, e.g. for a DSL or template language that gets translated to Python code, for which an explicit source mapping would be required.

But, I definitely see the analogy between .py files and .pyx files. In fact, .pyx files often originate from renaming .py files. And keep in mind that Cython can also compile .py files, which leads to .so files in the same package directory.

Installing the .pyx files alongside with the .so files is currently easy for our users because distutils does it automatically. Changing the place where they get installed would require tooling support and most likely also changes on user side in all Cython projects out there (unless it's configured through the distutils Extension object, which Cython can control).

The recommended way to structure Cython packages is to have the .pyx files where the resulting extension modules go, in their package, so that both end up next to each other with "setup.py build_ext --inplace", but also to make relative imports and inclusions work through the normal path lookup mechanism in Cython. Keeping two identical package structures in different places, one for .py files and generated .so files, and one for Cython source files (.pyx, .pxd, .pxi), is not desirable from a user perspective, and would require namespace packages for the lookup, where otherwise a simple single Python package structure would suffice. That would complicate Cython's internal compile time import lookup system quite a bit.

If we keep that single package structure (and from a user's perspective, I'm all for it), but change the way source files are looked up, we would have to additionally come up with a way to support the debugging case in a source checkout, where .pyx files and .so file are necessarily in the same package directory, together with the .py files.

This whole idea looks backwards and complicated. As Brett noted, .pyc files were moved out of the source tree, because they are build time artifacts and not sources. With that analogy, it's the .so files that would have to move, not the .pyx or .py source files, which are sources for the compiled .so files.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:21:11 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 05 Aug 2018 06:21:11 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533450071.75.0.56676864532.issue33839@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 87e59ac11ee074b0dc1bc864c74fac0660b27f6e by Tal Einat in branch 'master':
bpo-33839: refactor IDLE's tooltips & calltips, add docstrings and tests (GH-7683)
https://github.com/python/cpython/commit/87e59ac11ee074b0dc1bc864c74fac0660b27f6e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:21:35 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 06:21:35 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533450095.95.0.56676864532.issue33839@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8170

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:21:42 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 06:21:42 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533450102.97.0.56676864532.issue33839@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8171

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:47:30 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 06:47:30 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533451650.5.0.56676864532.issue33839@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e65ec491fbaa14db61a6559eb269733616b0e7f0 by Miss Islington (bot) in branch '3.7':
bpo-33839: refactor IDLE's tooltips & calltips, add docstrings and tests (GH-7683)
https://github.com/python/cpython/commit/e65ec491fbaa14db61a6559eb269733616b0e7f0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:51:25 2018
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sun, 05 Aug 2018 06:51:25 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
Message-ID: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

The documentation of typing.Optional seems to promote practices for not specifying Optional that are recommended against in PEP 484:

https://www.python.org/dev/peps/pep-0484/#union-types -- end of chapter recommends against inferring Optional.

https://docs.python.org/3.8/library/typing.html#typing.Optional -- second paragraph promotes the possibility of leaving out Optional.

I'm not sure how to improve the typing.Optional doc wording, perhaps it would be better to just remove the second paragraph altogether.

----------
assignee: docs at python
components: Documentation
messages: 323132
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Don't promote possibility to omit Optional on optional/defaulted arguments
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:53:25 2018
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sun, 05 Aug 2018 06:53:25 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533452005.13.0.56676864532.issue34336@psf.upfronthosting.co.za>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
keywords: +patch
pull_requests: +8172
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:58:08 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 06:58:08 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533452288.77.0.56676864532.issue33839@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2474cef34cd50e603c674c4856a17e3da4af71b3 by Miss Islington (bot) in branch '3.6':
bpo-33839: refactor IDLE's tooltips & calltips, add docstrings and tests (GH-7683)
https://github.com/python/cpython/commit/2474cef34cd50e603c674c4856a17e3da4af71b3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:59:48 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 05 Aug 2018 06:59:48 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533452388.69.0.56676864532.issue33839@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 02:59:56 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 05 Aug 2018 06:59:56 +0000
Subject: [issue33839] IDLE tooltips.py: refactor and add docstrings and tests
In-Reply-To: <1528747780.64.0.592728768989.issue33839@psf.upfronthosting.co.za>
Message-ID: <1533452396.63.0.56676864532.issue33839@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33839>
_______________________________________

From report at bugs.python.org  Sun Aug  5 03:04:48 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 05 Aug 2018 07:04:48 +0000
Subject: [issue34313] IDLE crashes with Tk-related error on macOS with
 ActiveTcl 8.6
In-Reply-To: <1533156582.15.0.56676864532.issue34313@psf.upfronthosting.co.za>
Message-ID: <1533452688.26.0.56676864532.issue34313@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I can confirm the these issues do *not* occur on my macOS setup when using tcl/tk 8.6.8 built from source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34313>
_______________________________________

From report at bugs.python.org  Sun Aug  5 03:40:09 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 05 Aug 2018 07:40:09 +0000
Subject: [issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533454809.58.0.56676864532.issue34247@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The PR works for me as well, and looks ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Sun Aug  5 03:44:46 2018
From: report at bugs.python.org (Yiwei Guo)
Date: Sun, 05 Aug 2018 07:44:46 +0000
Subject: [issue34337] Fail to get a right answer for 1.2%0.2
Message-ID: <1533455086.01.0.56676864532.issue34337@psf.upfronthosting.co.za>


Change by Yiwei Guo <yguo at eiu.edu>:


----------
components: Tests
nosy: qq100460045
priority: normal
severity: normal
status: open
title: Fail to get a right answer for 1.2%0.2
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34337>
_______________________________________

From report at bugs.python.org  Sun Aug  5 03:46:13 2018
From: report at bugs.python.org (Yiwei Guo)
Date: Sun, 05 Aug 2018 07:46:13 +0000
Subject: [issue34337] Fail to get a right answer for 1.2%0.2
Message-ID: <1533455173.68.0.56676864532.issue34337@psf.upfronthosting.co.za>


New submission from Yiwei Guo <yguo at eiu.edu>:

the answer of 1.2%0.2 should be zero

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34337>
_______________________________________

From report at bugs.python.org  Sun Aug  5 03:58:54 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Aug 2018 07:58:54 +0000
Subject: [issue34337] Fail to get a right answer for 1.2%0.2
In-Reply-To: <1533455173.68.0.56676864532.issue34337@psf.upfronthosting.co.za>
Message-ID: <1533455934.31.0.56676864532.issue34337@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This isn't a bug: in short, you're evaluating a discontinuous function very close to a discontinuity; the errors inherent in floating-point arithmetic put you the "wrong" side of the discontinuity.

Or more simply, with binary floating-point, What You See Is Not What You Get. When you type 1.2, the value actually stored is the closest values that's exactly representable as a float, which turns out to be 1.1999999999999999555910790149937383830547332763671875. Similarly, the value actually stored for 0.2 is 0.200000000000000011102230246251565404236316680908203125. And 1.1999999999999999555910790149937383830547332763671875 % 0.200000000000000011102230246251565404236316680908203125 is 0.199999999999999900079927783735911361873149871826171875.

Some references:

https://docs.python.org/3/tutorial/floatingpoint.html
https://docs.python.org/3/reference/expressions.html#id17

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34337>
_______________________________________

From report at bugs.python.org  Sun Aug  5 04:47:41 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 05 Aug 2018 08:47:41 +0000
Subject: [issue34310] Build error with option "--with-pydebug" on Mac OS
 10.13.6
In-Reply-To: <1533145125.37.0.56676864532.issue34310@psf.upfronthosting.co.za>
Message-ID: <1533458861.54.0.56676864532.issue34310@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I could not find the specific commit you mentioned on master branch. Maybe you are on a customized branch(what is master-dirty)?

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34310>
_______________________________________

From report at bugs.python.org  Sun Aug  5 04:51:14 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 08:51:14 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533459074.58.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> In a subdirectory similar to __pycache__.

I thought about that, but I don't like the idea because then the directory structure of the actual sources would be different from the directory structure of the installed sources. So for example, how should "pip install -e" install the sources?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 04:55:43 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 05 Aug 2018 08:55:43 +0000
Subject: [issue34310] Build error with option "--with-pydebug" on Mac OS
 10.13.6
In-Reply-To: <1533145125.37.0.56676864532.issue34310@psf.upfronthosting.co.za>
Message-ID: <1533459343.77.0.56676864532.issue34310@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Could you retry with a make distclean && ./configure --with-debug && make ?

To be sure.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34310>
_______________________________________

From report at bugs.python.org  Sun Aug  5 05:08:11 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 05 Aug 2018 09:08:11 +0000
Subject: [issue34310] Build error with option "--with-pydebug" on Mac OS
 10.13.6
In-Reply-To: <1533145125.37.0.56676864532.issue34310@psf.upfronthosting.co.za>
Message-ID: <1533460091.46.0.56676864532.issue34310@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Yu,

I am going to close this issue because

1. there is no master-dirty branch
2. your hash commit: d17fe275a3 does not exist in the CPython repository
3. I just downloaded the last revision of CPython and compile it on a 10.13.4 OSX and I don't have your issue.


Maybe you should clean your working directory with make distclean and restart with ./configure --with-debug && make

Thank you for your feedback, and re-open this issue if you have again the problem with the master branch.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34310>
_______________________________________

From report at bugs.python.org  Sun Aug  5 05:22:16 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 05 Aug 2018 09:22:16 +0000
Subject: [issue34310] Build error with option "--with-pydebug" on Mac OS
 10.13.6
In-Reply-To: <1533145125.37.0.56676864532.issue34310@psf.upfronthosting.co.za>
Message-ID: <1533460936.08.0.56676864532.issue34310@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
resolution: rejected -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34310>
_______________________________________

From report at bugs.python.org  Sun Aug  5 05:30:33 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 09:30:33 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533461433.29.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Nick: do you agree that this "source-only metapath" should by default contain an entry to look in sys.path for source files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 05:32:47 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 09:32:47 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533461567.63.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Keeping two identical package structures in different places, one for .py files and generated .so files, and one for Cython source files (.pyx, .pxd, .pxi), is not desirable from a user perspective, and would require namespace packages for the lookup, where otherwise a simple single Python package structure would suffice. That would complicate Cython's internal compile time import lookup system quite a bit.

This is an important point. You shouldn't consider these Cython files as "extra stuff", they really should be considered as part of the package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 06:32:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Aug 2018 10:32:04 +0000
Subject: [issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533465124.39.0.56676864532.issue34247@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 0c90d6f75931da4fec84d06c2efe9dd94bb96b77 by Victor Stinner in branch '3.7':
[3.7] bpo-34247: Fix Python 3.7 initialization (#8659)
https://github.com/python/cpython/commit/0c90d6f75931da4fec84d06c2efe9dd94bb96b77


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Sun Aug  5 06:33:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 05 Aug 2018 10:33:50 +0000
Subject: [issue34247] PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533465230.36.0.56676864532.issue34247@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

On my PR, Nick Coghlan wrote:

"We may want to tweak the porting note in What's New, as I believe this may read more environment variables at init time than the interpreter did previously, so embedding applications that want more complete control may now need to set Py_IgnoreEnvironmentFlag when they could previously get by without it."

https://github.com/python/cpython/pull/8659#pullrequestreview-143397378

I'm not sure about this, since it's really a bug of Python 3.7.0 and it's now fixed.

I let you decide if the issue should be closed or not, I leave it open.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Sun Aug  5 07:45:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Aug 2018 11:45:42 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533469542.35.0.56676864532.issue34247@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: PYTHONOPTIMZE ignored in 3.7.0 when using custom launcher -> PYTHONOPTIMIZE ignored in 3.7.0 when using custom launcher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Sun Aug  5 07:54:40 2018
From: report at bugs.python.org (Paul Moore)
Date: Sun, 05 Aug 2018 11:54:40 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1533448269.57.0.56676864532.issue32797@psf.upfronthosting.co.za>
Message-ID: <CACac1F-pAW__7P8DEpt7w4qGV4k6765kU2FGO1fDadgA_Br+Bw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

On Sun, 5 Aug 2018 at 06:51, Stefan Behnel <report at bugs.python.org> wrote:
> This whole idea looks backwards and complicated. As Brett noted, .pyc files were moved out of the source tree, because they are build time artifacts and not sources. With that analogy, it's the .so files that would have to move, not the .pyx or .py source files, which are sources for the compiled .so files.

I disagree. In *Python* terms:

* .py files are the executable units of Python code
* .so/.pyd files are the executable units of extension modules
* .pyc/.pyo files are runtime artifacts that cache the results of the
compilation step of loading .py code. There's no equivalent for
.so/.pyd files as there's no compilation step needed when loading
them.
* .c, .h., .pyx, ... files are the source code for .so/.pyd files.
There's no equivalent for .py files, because Python code is executable
from source.

Executable units of code go on sys.path. Cached runtime artifacts go
in __pycache__. There's no defined location for source code. Whether
you agree with the above or not, please accept that it's a consistent
view of things. Sourceless distributions of Python code are an oddball
corner case, but they do *not* demonstrate that Python is a compiled
language and the .pyc/.pyo is the "executable" and the .py file is the
"source". At least not in my opinion.

It's entirely reasonable that we want to ensure that an exception
object, whether raised from a Python file or a compiled extension
module, includes a reference to the source of the issue, and that the
traceback mechanism can, if at all possible, locate that source and
display it in the exception traceback. That's basically what the
loader "get_source" method is for - isn't the problem here simply that
get_source for .pyd/.so files returns None, which in turn is because
there's no obvious way to get to the source file for a general binary
(and so the current implementation takes the easy way out and gives
up[1])?

Note that Cython is *not* unique here. Any tool that generates
.so/.pyd files has the same problem, and we should be looking for a
general solution. C code is the obvious example, and while I doubt
anyone is going to ship C sources with a Python extension, it's still
a valid case. Doesn't CFFI have a mode where it compiles a .pyd at
wheel build time? Shouldn't that be able to locate the source? As a
separate example, consider Jython, which may want to be able to locate
the Java (or Groovy, or Scala, ...) source for a .class file on
sys.path, and would have the same problem with get_source that CPython
does with .so/.pyd files.

So basically what's needed here is a modification to
ExtensionFileLoader to return a more useful value from get_source. How
it *does* that is up for debate, and brings in questions around what
standards the packaging community want to establish for shipping
extension sources, etc. And because the resulting decisions will end
up implemented as stdlib code, they need to be properly thought
through, as the timescales to fix design mistakes are quite long.
"Bung stuff on sys.path" isn't really a well thought through solution
in that sense, at least IMO - regardless of the fact that it's in
effect what linecache supported prior to Python 3.3.

So as a way forward, how about this:

1. Agree that what we actually need a better get_source method on
ExtensionFileLoader
2. Adjourn to distutils-sig to agree a standard for where tools that
generate .pyd/.so files should put their sources, if they should
choose to ship their sources in the wheel with the final built
extension.
3. Come back here with the results of that discussion to produce a PR
that implements that change to ExtensionFileLoader

The one possible fly in the ointment is if there are use cases that we
need to support where a single .so/.pyd file is built from *multiple*
source files, as get_source doesn't allow for that. Then it's back to
the drawing board...

Paul

[1] I remember working on the original design of PEP 302 and "take the
easy way out and give up" is *precisely* the thinking behind this :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 08:12:35 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Sun, 05 Aug 2018 12:12:35 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533471155.16.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

Having 3.6.5 and 3.7.0 with Tcl/Tk 8.6.8, try to File->Open Module and open ssl module. On 3.6 everything is fine, on 3.7 the scroller sticks at the bottom. A Tk text widget with the same amount of lines shows no problem. Apple macOS 17.7.0 with 64 bit Python and Tcl/Tk. IDLE problem probably.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 08:25:14 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Sun, 05 Aug 2018 12:25:14 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533471914.38.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

The solution was very simple on my Mac. In /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/idlelib/editor.py, lines 461-462 should be:

up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
      EventType.Button: event.num == 4}

instead of:
up = {EventType.MouseWheel: event.delta >= 0 == darwin,
      EventType.Button: event.num == 4}

Does this solve the scrollbar locked down issue for anyone else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 08:42:39 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 05 Aug 2018 12:42:39 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533472959.93.0.56676864532.issue34047@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Yes! Vlad's fix resolves the "sticks at bottom of file" bug for me on macOS.  It also resolves #2 in my list of additional bugs, regarding scrolling direction.

With both 3.7.0 and current master, I still see additional bugs #1 and #3, i.e. issues dragging the scrollbar slider when it is at the top of the scrollbar and clicking slightly under the slider having no effect.  I'll open a separate issue about that as it seems like something separate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 08:45:57 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Aug 2018 12:45:57 +0000
Subject: [issue33954] float.__format__('n') fails with
 _PyUnicode_CheckConsistency assertion error
In-Reply-To: <1529915026.11.0.56676864532.issue33954@psf.upfronthosting.co.za>
Message-ID: <1533473157.0.0.56676864532.issue33954@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33954>
_______________________________________

From report at bugs.python.org  Sun Aug  5 08:48:38 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 05 Aug 2018 12:48:38 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533473318.31.0.56676864532.issue34047@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +8173
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 09:03:28 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 13:03:28 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533474208.22.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> The one possible fly in the ointment is if there are use cases that we
need to support where a single .so/.pyd file is built from *multiple*
source files, as get_source doesn't allow for that.

Yes, we must support that. A cython module may have multiple sources. The simplest solution to solve that would be a new PEP 302 API, something like get_source_from_filename(self, filename)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 09:31:16 2018
From: report at bugs.python.org (Paul Moore)
Date: Sun, 05 Aug 2018 13:31:16 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533475876.58.0.56676864532.issue32797@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

So, where is the filename coming from? Looking at exception and frame objects, I don't see a "source filename" attribute anywhere - have I missed something here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 10:25:49 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Sun, 05 Aug 2018 14:25:49 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533479149.0.0.56676864532.issue34319@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

+1 to Terry's suggestion.

I've reviewed xtreak's PR and it looks good to me.

----------
nosy: +CuriousLearner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Sun Aug  5 11:38:38 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Sun, 05 Aug 2018 15:38:38 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533483518.33.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

With:

up = {EventType.MouseWheel: (event.delta >= 0) == darwin,
      EventType.Button: (event.num == 4)}

in editor.py at 461-462 I don't see bugs #1 neither #3 on 3.7.0 but I'll try with other files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 11:48:54 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Sun, 05 Aug 2018 15:48:54 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533484134.09.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

In fact, if the first click before dragging takes place in the upper half of the scrollbar slider, the click is not received nor the drag after. Is like the scroll slider is translated down with half of the slider length (that's why I can drag the slider even when I'm a little bit lower with the pointer). I'll check the click callback and the scrollbar setup functions. Can anybody check if clicking then starting to drag the slider in the inferior half of the slider, even at the top of a file, functions well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 11:55:03 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Aug 2018 15:55:03 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533484503.6.0.56676864532.issue32797@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While I'd be inclined to agree with Paul's analysis if CPython were a greenfield project, I also think if SageMath had already been ported to Python 3.2, we would have considered this change a behavioural regression between 3.2 and 3.3 resulting from the importlib migration and worked out a way to get it to work implicitly again.

Now, though, we need a way for SageMath to get it working on releases up to and including 3.7, *without* any help from Cython or CPython, since it needs to work with existing Cython releases on existing CPython versions to avoid presenting itself to SageMath users as regression introduced by switching from Python 2 to Python 3.

To do that, I believe it can be made to work in much the same way it did in Python 2 if SageMath were to do the following:

1. Define a subclass of ExtensionModuleLoader [1] that overrides get_source() to also look for a ".pyx" file adjacent to the extension module. This would also look for any of the file suffixes in SOURCE_SUFFIXES if a .pyx file isn't found.
2. Create an instance of FileFinder [3] that uses the custom loader subclass for any of the file suffixes in EXTENSION_SUFFIXES [4]
3. Replace the regular file finding hook in sys.path_hooks with  the path_hook method from that new FileFinder instance (by default, there's only one FileFinder hook installed, and it can currently be identified as "obj.__name__ == 'path_hook_for_FileFinder')
4. Invalidate importlib's caches, so any future extension module imports will use the custom extension module loader, rather than the default one

[1] https://docs.python.org/3/library/importlib.html#importlib.machinery.ExtensionFileLoader
[2] https://docs.python.org/3/library/importlib.html#importlib.machinery.SOURCE_SUFFIXES
[3] https://docs.python.org/3/library/importlib.html#importlib.machinery.FileFinder
[4] https://docs.python.org/3/library/importlib.html#importlib.machinery.EXTENSION_SUFFIXES

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 12:07:17 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Aug 2018 16:07:17 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1533485237.63.0.56676864532.issue34247@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

My comment wasn't about the 3.7.0 -> 3.7.1 fix, but rather about the fact that I suspect that 3.7.1 is now going to respect some environment variables in this case that 3.6.x ignored. I don't know for sure though, since we didn't have a test case for this until you wrote one.

So I was thinking we could include a porting note along the lines of:

===============
- starting in 3.7.1, `Py_Initialize` now consistently reads and respects all of the same environment settings as `Py_Main` (in earlier Python versions, it respected an ill-defined subset of those environment variables, while in Python 3.7.0 it didn't read any of them due to :issue:`34247`). If this behaviour is unwanted, set `Py_IgnoreEnvironmentFlag = 1` before calling `Py_Initialize`.
===============

That note then serves two purposes:

- it lets embedders know that `Py_IgnoreEnvironmentFlag = 0` just plain doesn't work properly in 3.7.0 (without their needing to find this bug for themselves)
- it lets embedders know that they may want to set `Py_IgnoreEnvironmentFlag = 1` if their embedded interpreter is now being affected by environmental settings that it ignored in previous versions

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34247>
_______________________________________

From report at bugs.python.org  Sun Aug  5 12:29:46 2018
From: report at bugs.python.org (Michael Hooreman)
Date: Sun, 05 Aug 2018 16:29:46 +0000
Subject: [issue34338] abstractmethod can run on classes
Message-ID: <1533486586.96.0.56676864532.issue34338@psf.upfronthosting.co.za>


New submission from Michael Hooreman <mhooreman at gmail.com>:

Hello,

When I decorate a class method with abc.abstractmethod, and I call it from the class (not the instance), the call is successful.

It looks like ID 5867 which was closed years ago.

See https://stackoverflow.com/questions/51669362/python-3-6-abc-abstracmethod-on-classmethod-no-check-on-class-level-call

Thanks!

----------
components: Library (Lib)
messages: 323157
nosy: Michael Hooreman
priority: normal
severity: normal
status: open
title: abstractmethod can run on classes
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34338>
_______________________________________

From report at bugs.python.org  Sun Aug  5 12:37:04 2018
From: report at bugs.python.org (danijar)
Date: Sun, 05 Aug 2018 16:37:04 +0000
Subject: [issue34339] Argument unpacking syntax for lambdas
Message-ID: <1533487024.74.0.56676864532.issue34339@psf.upfronthosting.co.za>


New submission from danijar <mail at danijar.com>:

It would be great to support argument unpacking for lambdas. Example:

  lambda x, (y, z): x + y + z

instead of

  lambda x, y_and_z: x + y_and_z[0] + y_and_z[1]

Similar unpacking syntax is available for normal functions:

  def foo(x, y_and_z):
    y, z = y_and_z
    return x + y + z

This would greatly increase readability in some cases.

----------
components: Interpreter Core
messages: 323158
nosy: benjamin.peterson, brett.cannon, danijar, yselivanov
priority: normal
severity: normal
status: open
title: Argument unpacking syntax for lambdas

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34339>
_______________________________________

From report at bugs.python.org  Sun Aug  5 12:38:07 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 05 Aug 2018 16:38:07 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533487087.32.0.56676864532.issue34336@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 336c945858055059a65134d4c501a85037d70d99 by Ivan Levkivskyi (Ville Skytt?) in branch 'master':
bpo-34336: Don't promote possibility to leave out typing.Optional (#8677)
https://github.com/python/cpython/commit/336c945858055059a65134d4c501a85037d70d99


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 12:48:48 2018
From: report at bugs.python.org (bpypy)
Date: Sun, 05 Aug 2018 16:48:48 +0000
Subject: [issue34340] mimetypes libmagic compatibility
Message-ID: <1533487728.36.0.56676864532.issue34340@psf.upfronthosting.co.za>


New submission from bpypy <python at bzx2.com>:

An obvious use case for mimetypes would be to check if file has correct mimetype, by getting the type with some of libmagic wrappers, and then comparing to guess_type result.

But it seems that they don't always match. One example:
applicattion/rar vs application/x-rar
https://github.com/file/file/blob/b9e60f088847f885b5c9fde61ff8fc9645843506/magic/Magdir/archive#L986

Kills half the usefullness of the module.

----------
components: Extension Modules
messages: 323160
nosy: bpypy
priority: normal
severity: normal
status: open
title: mimetypes libmagic compatibility
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34340>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:04:21 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 17:04:21 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533488661.12.0.56676864532.issue34336@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8174

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:04:37 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 17:04:37 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533488677.63.0.56676864532.issue34336@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8175

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:10:16 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 05 Aug 2018 17:10:16 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1533484503.6.0.56676864532.issue32797@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W74nkt=+RgY6M5A+ptgo3=xHSLvQmPOSni8Mc+De8xQ9Q@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Aug 5, 2018, 08:55 Nick Coghlan, <report at bugs.python.org> wrote:

>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> While I'd be inclined to agree with Paul's analysis if CPython were a
> greenfield project, I also think if SageMath had already been ported to
> Python 3.2, we would have considered this change a behavioural regression
> between 3.2 and 3.3 resulting from the importlib migration and worked out a
> way to get it to work implicitly again.
>

Perhaps, but no point on dwelling on 4 releases ago. ?

One other thing I will say is that the PEP 302 APIs were seemingly designed
for working with Python source and were not necessarily oriented towards
alternative code representations that were executed, e.g. Quixote was
supported because it transpiled to Python source (although Paul is a
co-author on the PEP and could more definitively answer ?). IOW the APIs
are oriented towards the Python programming language, not the CPython
interpreter. This is why, for instance, I'm suggesting that if a more
general solution is desired to be made official, then trying to force
everything into the current APIs might not turn out well.

> Now, though, we need a way for SageMath to get it working on releases up
> to and including 3.7, *without* any help from Cython or CPython, since it
> needs to work with existing Cython releases on existing CPython versions to
> avoid presenting itself to SageMath users as regression introduced by
> switching from Python 2 to Python 3.
>
> To do that, I believe it can be made to work in much the same way it did
> in Python 2 if SageMath were to do the following:
>
> 1. Define a subclass of ExtensionModuleLoader [1] that overrides
> get_source() to also look for a ".pyx" file adjacent to the extension
> module. This would also look for any of the file suffixes in
> SOURCE_SUFFIXES if a .pyx file isn't found.
> 2. Create an instance of FileFinder [3] that uses the custom loader
> subclass for any of the file suffixes in EXTENSION_SUFFIXES [4]
> 3. Replace the regular file finding hook in sys.path_hooks with  the
> path_hook method from that new FileFinder instance (by default, there's
> only one FileFinder hook installed, and it can currently be identified as
> "obj.__name__ == 'path_hook_for_FileFinder')
> 4. Invalidate importlib's caches, so any future extension module imports
> will use the custom extension module loader, rather than the default one
>

This sounds like it would work to me and doesn't require any special
changes on our part to function.

-Brett

> [1]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.ExtensionFileLoader
> [2]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.SOURCE_SUFFIXES
> [3]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.FileFinder
> [4]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.EXTENSION_SUFFIXES
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32797>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:13:42 2018
From: report at bugs.python.org (Paul Moore)
Date: Sun, 05 Aug 2018 17:13:42 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <CAP1=2W74nkt=+RgY6M5A+ptgo3=xHSLvQmPOSni8Mc+De8xQ9Q@mail.gmail.com>
Message-ID: <CACac1F_Wyoh_b=DQpx=oc=QNU=j+1doGSRSY=XXrY_m8DFw5qw@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

On Sun, 5 Aug 2018 at 18:10, Brett Cannon <report at bugs.python.org> wrote:

> One other thing I will say is that the PEP 302 APIs were seemingly designed
> for working with Python source and were not necessarily oriented towards
> alternative code representations that were executed, e.g. Quixote was
> supported because it transpiled to Python source (although Paul is a
> co-author on the PEP and could more definitively answer ?). IOW the APIs
> are oriented towards the Python programming language, not the CPython
> interpreter. This is why, for instance, I'm suggesting that if a more
> general solution is desired to be made official, then trying to force
> everything into the current APIs might not turn out well

That's how I recall it. The only cases we really considered were Python
modules (source code plus pyc) and extension modules (no source, loader
should return None).

Paul

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:22:48 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Aug 2018 17:22:48 +0000
Subject: [issue34339] Argument unpacking syntax for lambdas
In-Reply-To: <1533487024.74.0.56676864532.issue34339@psf.upfronthosting.co.za>
Message-ID: <1533489768.01.0.56676864532.issue34339@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this is an explicit decision to remove it in Python 3 unless I am mistaking the syntax you are referring to. Please refer : https://www.python.org/dev/peps/pep-3113/ . A note on 2to3 to fix this : https://www.python.org/dev/peps/pep-3113/#transition-plan

?  cpython git:(master) python2
Python 2.7.14 (default, Mar 12 2018, 13:54:56)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda x, (y, z): [x, y])(1, (2, 3))
[1, 2]
>>> (lambda x, (y, z): [x, y, z])(1, (2, 3))
[1, 2, 3]


?  cpython git:(master) python3
Python 3.6.4 (default, Mar 12 2018, 13:42:53)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> (lambda x, (y, z): [x, y, z])(1, (2, 3))
  File "<stdin>", line 1
    (lambda x, (y, z): [x, y, z])(1, (2, 3))
               ^
SyntaxError: invalid syntax


Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34339>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:22:50 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 17:22:50 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533489770.25.0.56676864532.issue34336@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 02c4eae35cd24ab71c12b5e61ec22e993ac4839b by Miss Islington (bot) in branch '3.6':
bpo-34336: Don't promote possibility to leave out typing.Optional (GH-8677)
https://github.com/python/cpython/commit/02c4eae35cd24ab71c12b5e61ec22e993ac4839b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:27:18 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 17:27:18 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533490038.64.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> So, where is the filename coming from?

Python 3.7.0 (default, Jul 23 2018, 10:07:21)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sage.all import Integer
>>> try:
...     Integer(1)/Integer(0)
... except Exception as e:
...     E = e
>>> E.__traceback__.tb_next.tb_frame.f_code.co_filename
'sage/structure/element.pyx'

So this is the correct filename, relative to site-packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:36:07 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Aug 2018 17:36:07 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533490567.16.0.56676864532.issue34336@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e610c4f9984d50b45eb00e04c73c4208c0542a3b by Miss Islington (bot) in branch '3.7':
bpo-34336: Don't promote possibility to leave out typing.Optional (GH-8677)
https://github.com/python/cpython/commit/e610c4f9984d50b45eb00e04c73c4208c0542a3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:41:47 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 17:41:47 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533490907.51.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Now, though, we need a way for SageMath to get it working on releases up to and including 3.7, *without* any help from Cython or CPython

That's not really what I need. We already have a work-around in SageMath:

try:
    from importlib.machinery import ExtensionFileLoader
except ImportError:
    pass  # Python 2
else:
    del ExtensionFileLoader.get_source

So this issue is about finding a proper solution, which doesn't require a monkey-patch like the above. And I want it to work without any special support from the package, installing .pyx sources should "just work". This issue is not specific to SageMath, it's just that SageMath is the only project that I know which actually installs .pyx sources.

> Define a subclass of ExtensionModuleLoader [1] that overrides get_source() to also look for a ".pyx" file adjacent to the extension module.

As I mentioned before, get_source() cannot work because a single Cython module can have multiple sources. So whatever method is used to retrieve the Cython sources must know the filename; the module is not sufficient.

As you can see from the monkey-patch, not implementing get_source() at all works, but that's probably more or less by accident. I'm not sure to what extent that could be documented as the official way to look up a filename relative to sys.path entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:43:07 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 05 Aug 2018 17:43:07 +0000
Subject: [issue34336] Don't promote possibility to omit Optional on
 optional/defaulted arguments
In-Reply-To: <1533451885.05.0.56676864532.issue34336@psf.upfronthosting.co.za>
Message-ID: <1533490987.02.0.56676864532.issue34336@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34336>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:53:17 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 17:53:17 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533491597.02.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> One other thing I will say is that the PEP 302 APIs were seemingly designed for working with Python source and were not necessarily oriented towards alternative code representations that were executed

That's also my impression. I'm perfectly fine with saying that the get_source() method defined in PEP 302 only applies to Python sources.

That, together with the fact that we are really looking for *filenames* not *modules* is why the fix should involve the linecache module and not PEP 302. In https://bugs.python.org/issue32797#msg323106 Nick seemed to agree with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 13:54:55 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 05 Aug 2018 17:54:55 +0000
Subject: [issue33954] float.__format__('n') fails with
 _PyUnicode_CheckConsistency assertion error for locales with non-ascii
 thousands separator
In-Reply-To: <1529915026.11.0.56676864532.issue33954@psf.upfronthosting.co.za>
Message-ID: <1533491695.13.0.56676864532.issue33954@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error -> float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error for locales with non-ascii thousands separator

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33954>
_______________________________________

From report at bugs.python.org  Sun Aug  5 14:09:17 2018
From: report at bugs.python.org (danijar)
Date: Sun, 05 Aug 2018 18:09:17 +0000
Subject: [issue34339] Argument unpacking syntax for lambdas
In-Reply-To: <1533487024.74.0.56676864532.issue34339@psf.upfronthosting.co.za>
Message-ID: <1533492557.98.0.56676864532.issue34339@psf.upfronthosting.co.za>


danijar <mail at danijar.com> added the comment:

Thank you! Closing this.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34339>
_______________________________________

From report at bugs.python.org  Sun Aug  5 14:33:27 2018
From: report at bugs.python.org (Paul Moore)
Date: Sun, 05 Aug 2018 18:33:27 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533494007.28.0.56676864532.issue32797@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

If you're OK with that, I don't see the problem. My objection was with the claims that ExtensionLoader.get_source shouldn't return None or shouldn't exist. PEP 302 mandates that loaders have a get_source, and that get_source should return None if the loader can't supply source. And that's precisely what ExtensionLoader is doing.

So if we're agreed that there's no changes needed to PEP 302 (more accurately, the loader protocol as it exists now) or to ExtensionLoader, then I'm happy to let others work out a solution on that basis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 14:40:14 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 18:40:14 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533494414.2.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> If you're OK with that, I don't see the problem.

I recall that we already agreed several months ago, when I submitted https://github.com/python/cpython/pull/6653

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 14:58:54 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 18:58:54 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533495534.18.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I just realized the existence of https://docs.python.org/3/library/importlib.html#importlib.abc.ResourceReader

Isn't this *exactly* what we need here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 15:11:24 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 05 Aug 2018 19:11:24 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533496283.99.0.56676864532.issue32797@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> SageMath is the only project that I know which actually installs .pyx sources.

Ah, right. I wrongly remembered that they are automatically included in binary packages, but that only applies to .py source of Cython compiled Python modules (which are obviously included), not for .pyx sources. Those still need to be explicitly included, which suggests that most projects wouldn't do that (especially because it doesn't help, given this very issue).


> The one possible fly in the ointment is if there are use cases that we
> need to support where a single .so/.pyd file is built from *multiple*
> source files, as get_source doesn't allow for that.

That probably applies to many, if not most, extension modules. For Cython it's .pyx, .pxi and .pxd files, plus any external C/C++ source files, for C it's .c/.cpp and .h files, other code generators have their own (set of) source files, many wrapper extension modules out there consist of more than one source file that would be relevant, ?

I would consider .py files the exceptional case here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 16:24:35 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Sun, 05 Aug 2018 20:24:35 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533500675.96.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

Check the commands below and the results to see why the problem with the mouse wheel appeared:

>>> a = 1
>>> a >= 0 == True
False
>>> (a >= 0) == True
True
>>> a >= (0 == True)
True
>>> a >= 0 == False
True
>>> (a >= 0) == False
False
>>> a >= (0 == False)
True
>>> (a >= 0) == True
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Sun Aug  5 16:29:05 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 05 Aug 2018 20:29:05 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533500945.28.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I think I could make linecache use the ResourceReader API to find the source file instead of looking in the sys.path entries. However, that's orthogonal to PR 6653: we still need PR 6653 to continue looking for the source file in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Sun Aug  5 17:15:14 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 05 Aug 2018 21:15:14 +0000
Subject: [issue34236] Test6012 in test_capi is not run as part of make test
In-Reply-To: <1532612537.28.0.56676864532.issue34236@psf.upfronthosting.co.za>
Message-ID: <1533503714.27.0.56676864532.issue34236@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8176
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34236>
_______________________________________

From report at bugs.python.org  Sun Aug  5 17:17:11 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 05 Aug 2018 21:17:11 +0000
Subject: [issue34236] Test6012 in test_capi is not run as part of make test
In-Reply-To: <1532612537.28.0.56676864532.issue34236@psf.upfronthosting.co.za>
Message-ID: <1533503831.29.0.56676864532.issue34236@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
components: +Tests -Build
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34236>
_______________________________________

From report at bugs.python.org  Sun Aug  5 18:31:57 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 05 Aug 2018 22:31:57 +0000
Subject: [issue34254] Include type annotations in error messages for better
 errors
In-Reply-To: <1532764112.96.0.56676864532.issue34254@psf.upfronthosting.co.za>
Message-ID: <1533508317.73.0.56676864532.issue34254@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

FWIW I am rather -1 on this. More detailed errors messages are always good, but in the proposed form it looks more like a distraction. I think just showing a fully qualified name of the function would be both more concise and more informative, since the user would likely need to look at the function code/docstring anyway in order to write a correct call.

----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34254>
_______________________________________

From report at bugs.python.org  Sun Aug  5 22:57:34 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 06 Aug 2018 02:57:34 +0000
Subject: [issue26515] Update extending/embedding docs to new way to build
 modules in C
In-Reply-To: <1457491421.2.0.684118231911.issue26515@psf.upfronthosting.co.za>
Message-ID: <1533524254.96.0.56676864532.issue26515@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8177
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26515>
_______________________________________

From report at bugs.python.org  Sun Aug  5 23:05:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 06 Aug 2018 03:05:47 +0000
Subject: [issue26515] Update extending/embedding docs to new way to build
 modules in C
In-Reply-To: <1457491421.2.0.684118231911.issue26515@psf.upfronthosting.co.za>
Message-ID: <1533524747.72.0.56676864532.issue26515@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26515>
_______________________________________

From report at bugs.python.org  Mon Aug  6 01:11:21 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Aug 2018 05:11:21 +0000
Subject: [issue34254] Include type annotations in error messages for better
 errors
In-Reply-To: <1532764112.96.0.56676864532.issue34254@psf.upfronthosting.co.za>
Message-ID: <1533532281.95.0.56676864532.issue34254@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the feedback on this. Brett also gave feedback on the python-ideas mailing list as below : 

> Two things to quickly mention: one is that type hints have no run-time semantics, so adding them to such a critical exception would be escalating their meaning a bit. The other point is this TypeError has nothing to do with the cause of the exception, so I would say that it's slightly distracting from the cause of the issue.

I am closing this.

Thanks

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34254>
_______________________________________

From report at bugs.python.org  Mon Aug  6 02:28:35 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 06 Aug 2018 06:28:35 +0000
Subject: [issue34248] dbm errors should contain file names
In-Reply-To: <1532698438.31.0.56676864532.issue34248@psf.upfronthosting.co.za>
Message-ID: <1533536915.79.0.56676864532.issue34248@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

PR 8590 only changes dbm.gnu. If we do this, we should update dbm.ndbm as well:

    https://github.com/python/cpython/blob/4a745333406a4b9c5b0194bdac4a77d9fadd5457/Modules/_dbmmodule.c#L65

----------
nosy: +berker.peksag
type:  -> enhancement
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34248>
_______________________________________

From report at bugs.python.org  Mon Aug  6 02:43:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 06:43:30 +0000
Subject: [issue14315] zipfile.ZipFile() unable to open zip File with a short
 extra header
In-Reply-To: <1331810146.14.0.995585507713.issue14315@psf.upfronthosting.co.za>
Message-ID: <1533537810.25.0.56676864532.issue14315@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Just for information: the padding in APK files is added by the zipalign utility [1].

[1] https://developer.android.com/studio/command-line/zipalign

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14315>
_______________________________________

From report at bugs.python.org  Mon Aug  6 03:41:56 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Aug 2018 07:41:56 +0000
Subject: [issue25872] multithreading traceback KeyError when modifying file
In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za>
Message-ID: <1533541316.48.0.56676864532.issue25872@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems there was a major refactor in traceback module with 6bc2c1e7ebf359224e5e547f58ffc2c42cb36a39 where this was fixed in Python 3. Ignoring the KeyError seems reasonable to me.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25872>
_______________________________________

From report at bugs.python.org  Mon Aug  6 03:53:26 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Aug 2018 07:53:26 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533542006.83.0.56676864532.issue34296@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Mon Aug  6 03:57:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 07:57:50 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
Message-ID: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

When the ZIP archive is opened for appending, it reads the Central Directory at opening and writes existing entries back at closing. The Zip64 Extra Field is appended to existing Extra Fields if necessary. This leads to increasing the size of the Extra Fields data every time when append to the ZIP archive. Since the total size of Extra Fields is limited by 0xffff bytes, this can cause the failure.

The proposed PR removes the Zip64 Extra Field before adding a new Zip64 Extra Field.

----------
assignee: serhiy.storchaka
components: Library (Lib)
messages: 323181
nosy: alanmcintyre, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Appending to ZIP archive blows up existing Central Directory entries
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Aug  6 03:59:21 2018
From: report at bugs.python.org (Shahriyar Rzayev)
Date: Mon, 06 Aug 2018 07:59:21 +0000
Subject: [issue34342] Fix the broken links in CPythonVmInternals wiki page
Message-ID: <1533542361.92.0.56676864532.issue34342@psf.upfronthosting.co.za>


New submission from Shahriyar Rzayev <rzayev.sehriyar at gmail.com>:

Please see:
https://wiki.python.org/moin/CPythonVmInternals

There are some links under "Particularly useful pieces of documentation: " which are broken and should be updated respectively as follows:

[Execution Model] -> https://docs.python.org/3/reference/executionmodel.html

[GIL] -> https://docs.python.org/3/c-api/init.html#thread-state-and-the-global-interpreter-lock or this one https://wiki.python.org/moin/GlobalInterpreterLock

[Bytecodes] -> Which is now can be found in https://docs.python.org/3/library/dis.html

[Disassembler] -> same here https://docs.python.org/3/library/dis.html

----------
assignee: docs at python
components: Documentation
messages: 323182
nosy: docs at python, shako
priority: normal
severity: normal
status: open
title: Fix the broken links in CPythonVmInternals wiki page
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34342>
_______________________________________

From report at bugs.python.org  Mon Aug  6 04:07:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 08:07:41 +0000
Subject: [issue34341] Appending to ZIP archive blows up existing Central
 Directory entries
In-Reply-To: <1533542270.27.0.56676864532.issue34341@psf.upfronthosting.co.za>
Message-ID: <1533542861.2.0.56676864532.issue34341@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8178
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34341>
_______________________________________

From report at bugs.python.org  Mon Aug  6 04:07:47 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Aug 2018 08:07:47 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533542867.92.0.56676864532.issue34296@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> i did 2 implementations in both python and pure bash, python takes about 500ms to run while bash is more than 10 times faster.

VM startup + `import site` are done in 10~20ms on common Linux machine.
It won't take 500ms.

While Python VM startup is not lightning fast, library import time is much slower than VM startup in many cases.  And since "importing library" may have many important side effects, we can't "pre warm" it.

Have you tried `PYTHONPROFILEIMPORTTIME=1` environment variable added by Python 3.7?
https://dev.to/methane/how-to-speed-up-python-application-startup-time-nkf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Mon Aug  6 04:28:30 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Aug 2018 08:28:30 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1533544110.24.0.56676864532.issue19891@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset b2499669ef2e6dc9a2cdb49b4dc498e078167e26 by INADA Naoki (Anthony Sottile) in branch 'master':
bpo-19891: Ignore error while writing history file (GH-8483)
https://github.com/python/cpython/commit/b2499669ef2e6dc9a2cdb49b4dc498e078167e26


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Mon Aug  6 04:28:41 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 08:28:41 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1533544121.01.0.56676864532.issue19891@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8179

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Mon Aug  6 04:28:51 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 08:28:51 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1533544131.93.0.56676864532.issue19891@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8180

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Mon Aug  6 04:32:46 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 06 Aug 2018 08:32:46 +0000
Subject: [issue34342] Fix the broken links in CPythonVmInternals wiki page
In-Reply-To: <1533542361.92.0.56676864532.issue34342@psf.upfronthosting.co.za>
Message-ID: <1533544366.31.0.56676864532.issue34342@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report. wiki.python.org is maintained by the Python community, not by Python core developers. You can fix those broken links by creating an account and requesting edit access by emailing to pydotorg-www at python.org. See https://wiki.python.org/moin/FrontPage#Editing_pages for details.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34342>
_______________________________________

From report at bugs.python.org  Mon Aug  6 05:03:52 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 09:03:52 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1533546232.92.0.56676864532.issue19891@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 416f3435c536c5197f5c6a23504955cf717df200 by Miss Islington (bot) in branch '3.7':
bpo-19891: Ignore error while writing history file (GH-8483)
https://github.com/python/cpython/commit/416f3435c536c5197f5c6a23504955cf717df200


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Mon Aug  6 05:15:51 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 09:15:51 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1533546951.95.0.56676864532.issue19891@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e20d31cdb33bdfee68bce059f9a9c7ce71b035fe by Miss Islington (bot) in branch '3.6':
bpo-19891: Ignore error while writing history file (GH-8483)
https://github.com/python/cpython/commit/e20d31cdb33bdfee68bce059f9a9c7ce71b035fe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Mon Aug  6 05:24:31 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Mon, 06 Aug 2018 09:24:31 +0000
Subject: [issue34343] Why is turtle still present in python embedded for
 Windows?
Message-ID: <1533547471.89.0.56676864532.issue34343@psf.upfronthosting.co.za>


New submission from Vlad Tudorache <tudorache.vlad at gmail.com>:

I've just started using the embedded Python 3.6 for Windows and I find turtle.py in the archive, knowing that tkinter isn't present. There's no large space loss because of it, but it's presence may be confusing.

----------
components: Library (Lib), Windows
messages: 323188
nosy: paul.moore, steve.dower, tim.golden, vtudorache, zach.ware
priority: normal
severity: normal
status: open
title: Why is turtle still present in python embedded for Windows?
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34343>
_______________________________________

From report at bugs.python.org  Mon Aug  6 05:42:26 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Aug 2018 09:42:26 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1533548546.47.0.56676864532.issue19891@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Mon Aug  6 05:58:27 2018
From: report at bugs.python.org (Cyker Way)
Date: Mon, 06 Aug 2018 09:58:27 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533549507.54.0.56676864532.issue34296@psf.upfronthosting.co.za>


Cyker Way <cykerway at gmail.com> added the comment:

>   VM startup + `import site` are done in 10~20ms on common Linux machine.

>   While Python VM startup is not lightning fast, library import time is much slower than VM startup in many cases.

In my tests, a helloworld python script generally takes about 30-40 ms, while a similar helloworld bash script takes about 3-4 ms. Adding some common library imports (`os`, `sys`, etc.), then the python script's running time goes up to 60-70ms. I'm not sure how to compare this against bash because there are no library imports in bash. The 500ms (python) vs 50ms (bash) comparison is based on minimal implementations of the same simple job and meant to reflect the minimal amount of time needed for such a job in different languages. While it doesn't cover everything and may not even be fair enough, the result does match that of the helloworld test (10 times faster/slower). Plus, in your linked post, it shows importing pipenv takes about 700ms. Therefore I believe some hundreds of milliseconds are necessary for such scripts that do a simple but meaningful job.

I understand many things can happen while importing a library. But for a specific program, its imports are usually fixed and very much likely the same between runs. That's why I believe a zygote/fork/snapshot feature would still be helpful to help avoid the startup delay.

Finally, for simple and quick user scrips, the 30-40 ms startup time without any import statements may not be a huge problem, but it's still tangible and makes the program feel not that sleek.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:04:47 2018
From: report at bugs.python.org (Vlad Starostin)
Date: Mon, 06 Aug 2018 10:04:47 +0000
Subject: [issue34344] Fix the docstring for
 AbstractEventLoopPolicy.get_event_loop
Message-ID: <1533549887.39.0.56676864532.issue34344@psf.upfronthosting.co.za>


New submission from Vlad Starostin <drtyrsa at yandex.ru>:

The docstring says "This may be None or an instance of EventLoop". But docs explicitly state that get_event_loop "must never return None". The same docstring is also in the example in docs: https://docs.python.org/3.6/library/asyncio-eventloops.html#customizing-the-event-loop-policy

I propose changing it to:

def get_event_loop(self):
    """Get the event loop.

    Returns an instance of EventLoop or raises an exception.
    """

If the wording is ok, I'll make a PR.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 323190
nosy: asvetlov, docs at python, drtyrsa, yselivanov
priority: normal
severity: normal
status: open
title: Fix the docstring for AbstractEventLoopPolicy.get_event_loop
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34344>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:12:38 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Aug 2018 10:12:38 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533550358.03.0.56676864532.issue34296@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> In my tests, a helloworld python script generally takes about 30-40 ms.
[snip]
> Finally, for simple and quick user scrips, the 30-40 ms startup time without any import statements may not be a huge problem, but it's still tangible and makes the program feel not that sleek.

What is your environment?
I optimized startup on Python 3.7, especially on macOS (it was very slow before 3.7).

And some legacy features (e.g. legacy "namespace package" system from setuptools) will make startup much slower, because they import some heavy libraries silently even when you just run "hello world".

PYTHONPROFILEIMPORTTIME will help to find them too.  And venv allow to split out such legacy tools from your main Python environment.

> The 500ms (python) vs 50ms (bash) comparison is based on minimal implementations of the same simple job and meant to reflect the minimal amount of time needed for such a job in different languages. 

Would you give us some example script?

> Plus, in your linked post, it shows importing pipenv takes about 700ms. Therefore I believe some hundreds of milliseconds are necessary for such scripts that do a simple but meaningful job.

FYI, it compiles many regular expressions at startup time.
I want to add lazy compilation API to re module in 3.8.  (I'm waiting bpo-21145 is implemented)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:19:07 2018
From: report at bugs.python.org (Erik Bray)
Date: Mon, 06 Aug 2018 10:19:07 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533550747.88.0.56676864532.issue32797@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Brett:
> As Nick said, we have no generalized concept of source maps and I think
coming up with that is what will be required to solve this as i personally
don't view Loader.get_source() is not meant to be a generalized concept of
some form of source code but Python source code.

I see what you're saying here, but given that Loader can return Python modules that are ostensibly not actually generated from Python source code, then it's not *obvious* that Loader.get_source() must return Python source.  At the very least the documentation [1] should clarify this.  But it's also a bit arbitrarily limiting, especially given the demonstrable possibility of providing tracebacks and code inspection for *non-Python* code (as in the case of Cython) that compiles to Python modules.


Nick:
> 1. Enhance PathFinder to allow specification of which path importer cache and path_hooks entries to use

This would be good.  Perhaps veering off-topic, but in an earlier attempt to fix this issue I actually tried to implement a sys.path_hooks hook for importing Cython modules such that I could provide an appropriate Loader for them with a get_source that actually works.  This turned out to be very difficult in large part due to the difficulty of customizing the relationship between the default PathFinder on sys.meta_path and the sys.path_hooks entries.  I made a post about this to python-ideas [2] but it never gained much traction, probably in large part due to the specialized nature of the problem and the complexity of my solution :)


[1] https://docs.python.org/3/library/importlib.html#importlib.abc.InspectLoader.get_source
[2] https://mail.python.org/pipermail/python-ideas/2018-February/048905.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:25:40 2018
From: report at bugs.python.org (Erik Bray)
Date: Mon, 06 Aug 2018 10:25:40 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533551140.14.0.56676864532.issue32797@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

To add, while an enhancement just to linecache would make sense in its own right, I don't see the problem with also extending the Loader.get_source() API to be more useful as well.  Its current behavior is to just return a string (or None), but it seems to me one could keep that basic behavior, but also extend it to optionally return a more sophisticated source map data structure (that could involve multiple source files as well).

This could even be useful for built-in modules.  I would love, for example, to be able to get stack traces within extension modules integrated into Python tracebacks if they are compiled with some appropriate debug flags.  The case of Cython demonstrates that something like this is perfectly doable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:28:39 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Aug 2018 10:28:39 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533551319.92.0.56676864532.issue34296@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> I understand many things can happen while importing a library. But for a specific program, its imports are usually fixed and very much likely the same between runs. That's why I believe a zygote/fork/snapshot feature would still be helpful to help avoid the startup delay.

I agree it can be useful.  It's different from your first post.  (Snapshot whole application, rather than just Python VM).
And this idea is discussed on Python-dev ML several times.

But I think it can be implemented as 3rd party tool at first.  It is better because (1) we can battle test the idea before adding it to stdlib, and (2) we can use the tool even for Python 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:39:48 2018
From: report at bugs.python.org (Cyker Way)
Date: Mon, 06 Aug 2018 10:39:48 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533551988.88.0.56676864532.issue34296@psf.upfronthosting.co.za>


Cyker Way <cykerway at gmail.com> added the comment:

It was tested on a x86_64 Linux system. The machine is not quite new but is OK for building and running python. The test script is actually a management tool for a larger project that is not released in public so I don't have right to disclose it here. When tested on python 3.7 it did run faster than python 3.6 so there were indeed great improvements.

While optimizing standard libraries definitely makes the program start up faster, we should also note that each user program also has its own specific initialization procedure. This is in general out of control of language platform developers, but forking a user-initialized vm or using a snapshot chosen by the user still helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:43:38 2018
From: report at bugs.python.org (Erik Bray)
Date: Mon, 06 Aug 2018 10:43:38 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533552218.72.0.56676864532.issue32797@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

> To do that, I believe it can be made to work in much the same way it did in Python 2 if SageMath were to do the following:
>
> 1. Define a subclass of ExtensionModuleLoader [1] that overrides get_source() to also look for a ".pyx" file adjacent to the extension module. This would also look for any of the file suffixes in SOURCE_SUFFIXES if a .pyx file isn't found.
> 2. Create an instance of FileFinder [3] that uses the custom loader subclass for any of the file suffixes in EXTENSION_SUFFIXES [4]
> 3. Replace the regular file finding hook in sys.path_hooks with  the path_hook method from that new FileFinder instance (by default, there's only one FileFinder hook installed, and it can currently be identified as "obj.__name__ == 'path_hook_for_FileFinder')
> 4. Invalidate importlib's caches, so any future extension module imports will use the custom extension module loader, rather than the default one

This is pretty edifying, because Nick's idea is almost exactly what I did six months ago :)  https://git.sagemath.org/sage.git/diff/?id2=0a674fd488dcd7cb779101d263c10a874a13cf77&id=8b63abe731c510f0de9ef0e3ab9a0bda3669dce1

Turned out to be very non-trivial of course, and I believe it should not have been as complicated as it was.

It also still doesn't solve the problem that Loader.get_source does not support multiple source files, which Cython code may have (a .pyx and a .pxd being a common case).  I'm glad Paul Moore seems to also agree (now that I've actually read the rest of the thread) that the ExtensionLoader.get_source, at the very least, could be made more useful.  Whatever form that takes would be worth extending to other loaders that implement get_source as well...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:46:46 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 06 Aug 2018 10:46:46 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533552406.0.0.56676864532.issue32797@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Or, define a new "get_sourcemap()" method that could return additional metadata, e.g. a line number mapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Aug  6 06:50:01 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 06 Aug 2018 10:50:01 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533552601.66.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I would love, for example, to be able to get stack traces within extension modules integrated into Python tracebacks if they are compiled with some appropriate debug flags.

Awesome idea, I want to work on that :-)

This should be possible using the backtrace() and backtrace_symbols() functions, which exist at least in GNU libc and on OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:08:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 12:08:19 +0000
Subject: [issue34345] Add tests for PEP 468 and PEP 520
Message-ID: <1533557299.17.0.56676864532.issue34345@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

AFAIK there no purposed tests for PEP 468 and PEP 520. If making dict not preserving order, noting related to these PEPs is failed.

I think we need explicit tests for PEP 468 and PEP 520. At least in 3.6 the dict order is not guaranteed. And even in 3.7+ preserving the dict order doesn't guarantee implementing PEP 468 and PEP 520. The order can be broken in a meanwhile (for example by iterating a list of keys in the reversed order).

----------
components: Tests
messages: 323199
nosy: eric.snow, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add tests for PEP 468 and PEP 520
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34345>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:08:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 12:08:50 +0000
Subject: [issue34320] Creating dict from OrderedDict doesn't preserve order
In-Reply-To: <1533215543.91.0.56676864532.issue34320@psf.upfronthosting.co.za>
Message-ID: <1533557330.19.0.56676864532.issue34320@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Add tests for PEP 468 and PEP 520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34320>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:10:11 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 06 Aug 2018 12:10:11 +0000
Subject: [issue32797] Tracebacks from Cython modules no longer work
In-Reply-To: <1518090924.55.0.467229070634.issue32797@psf.upfronthosting.co.za>
Message-ID: <1533557411.28.0.56676864532.issue32797@psf.upfronthosting.co.za>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Or, define a new "get_sourcemap()" method that could return additional metadata, e.g. a line number mapping.

What's your use case for that? I am asking because it might make more sense for get_source() (or whatever its replacement is) to return the already-mapped sources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32797>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:41:26 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Aug 2018 12:41:26 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533559286.67.0.56676864532.issue34273@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 28c7f8c8ce34a0cb848822a252a9d0a761fb42d5 by Terry Jan Reedy in branch 'master':
bpo-34273: Change 'Fixed point' to 'Fixed-point notation'. (#8673)
https://github.com/python/cpython/commit/28c7f8c8ce34a0cb848822a252a9d0a761fb42d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:41:35 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 12:41:35 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533559295.8.0.56676864532.issue34273@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8181

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:41:43 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 12:41:43 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533559303.32.0.56676864532.issue34273@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8182

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:47:39 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 12:47:39 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533559659.62.0.56676864532.issue34273@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e39fb207f26f8007e95fcf120f5ff1cb7372791a by Miss Islington (bot) in branch '3.7':
bpo-34273: Change 'Fixed point' to 'Fixed-point notation'. (GH-8673)
https://github.com/python/cpython/commit/e39fb207f26f8007e95fcf120f5ff1cb7372791a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:49:37 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 12:49:37 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533559777.9.0.56676864532.issue34273@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ed8dd598ae7e0d944974af0fd73c2fbb6105fd5c by Miss Islington (bot) in branch '3.6':
bpo-34273: Change 'Fixed point' to 'Fixed-point notation'. (GH-8673)
https://github.com/python/cpython/commit/ed8dd598ae7e0d944974af0fd73c2fbb6105fd5c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 08:57:07 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Aug 2018 12:57:07 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533560227.01.0.56676864532.issue34273@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +8183

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:03:48 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Aug 2018 13:03:48 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533560628.0.0.56676864532.issue34273@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 9027502e99cba700cadb675b3b2db03c311d1c4d by Terry Jan Reedy in branch '2.7':
[2.7] bpo-34273: Change 'Fixed point' to 'Fixed-point notation'. (GH-8673)
https://github.com/python/cpython/commit/9027502e99cba700cadb675b3b2db03c311d1c4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:04:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Aug 2018 13:04:24 +0000
Subject: [issue34273] %f is confusingly associated with fixed point format
In-Reply-To: <1532899552.57.0.56676864532.issue34273@psf.upfronthosting.co.za>
Message-ID: <1533560664.5.0.56676864532.issue34273@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34273>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:47:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 13:47:52 +0000
Subject: [issue34236] Test6012 in test_capi is not run as part of make test
In-Reply-To: <1532612537.28.0.56676864532.issue34236@psf.upfronthosting.co.za>
Message-ID: <1533563272.44.0.56676864532.issue34236@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7e4ff9796cb2c5b64307a2bd928e35930e3f1b2a by Serhiy Storchaka (Zackery Spytz) in branch '2.7':
[2.7] bpo-34236: Remove mistakenly backported Test6012 in test_capi.py. (GH-8681)
https://github.com/python/cpython/commit/7e4ff9796cb2c5b64307a2bd928e35930e3f1b2a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34236>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:48:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 13:48:27 +0000
Subject: [issue34236] Test6012 in test_capi is not run as part of make test
In-Reply-To: <1532612537.28.0.56676864532.issue34236@psf.upfronthosting.co.za>
Message-ID: <1533563307.99.0.56676864532.issue34236@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Karthikeyan and Zackery!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34236>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:50:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 13:50:23 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533563422.99.0.56676864532.issue34272@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8f7bb100d0fa7fb2714f3953b5b627878277c7c6 by Serhiy Storchaka in branch 'master':
bpo-34272: Move argument parsing tests from test_capi to test_getargs2. (GH-8567)
https://github.com/python/cpython/commit/8f7bb100d0fa7fb2714f3953b5b627878277c7c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:50:38 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 13:50:38 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533563438.44.0.56676864532.issue34272@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8184

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 09:57:49 2018
From: report at bugs.python.org (Chris Fuller)
Date: Mon, 06 Aug 2018 13:57:49 +0000
Subject: [issue34346] dir() hangs interpreter
Message-ID: <1533563869.83.0.56676864532.issue34346@psf.upfronthosting.co.za>


New submission from Chris Fuller <cfuller732 at thinkingplanet.net>:

It's a little obscure. Nothing to get alarmed about, probably. It involves recursion and __getattr__() during object creation.

Only present with 2.7 new-style classes. Old-style 2.7 did not exhibit this behavior nor did 3.x. Checked on Linux/Cygwin/Windows.

----------
files: splat.py
messages: 323208
nosy: sfaleron
priority: normal
severity: normal
status: open
title: dir() hangs interpreter
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47731/splat.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34346>
_______________________________________

From report at bugs.python.org  Mon Aug  6 10:10:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 14:10:10 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533564610.14.0.56676864532.issue34272@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8185

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 10:11:08 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 14:11:08 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533564668.76.0.56676864532.issue34272@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a1ff5f9031dc81b2c368def037fc0e88f5bc48b7 by Miss Islington (bot) in branch '3.7':
bpo-34272: Move argument parsing tests from test_capi to test_getargs2. (GH-8567)
https://github.com/python/cpython/commit/a1ff5f9031dc81b2c368def037fc0e88f5bc48b7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 10:34:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 14:34:50 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533566090.96.0.56676864532.issue34272@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 278d975ce158608f6be491c561247d4701c842be by Serhiy Storchaka in branch '3.6':
[3.6] bpo-34272: Move argument parsing tests from test_capi to test_getargs2. (GH-8567). (GH-8690)
https://github.com/python/cpython/commit/278d975ce158608f6be491c561247d4701c842be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 10:49:42 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 14:49:42 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533566982.81.0.56676864532.issue34272@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8186

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 11:06:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Aug 2018 15:06:19 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1533567979.37.0.56676864532.issue34272@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d1c5e278a1a2458bc5efcdc300c17f9e39a59b6c by Serhiy Storchaka in branch '2.7':
[2.7] bpo-34272: Move argument parsing tests from test_capi to test_getargs2. (GH-8567). (GH-8691)
https://github.com/python/cpython/commit/d1c5e278a1a2458bc5efcdc300c17f9e39a59b6c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Aug  6 11:13:23 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 06 Aug 2018 15:13:23 +0000
Subject: [issue34346] dir() hangs interpreter
In-Reply-To: <1533563869.83.0.56676864532.issue34346@psf.upfronthosting.co.za>
Message-ID: <1533568403.72.0.56676864532.issue34346@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I don't think the description you give is very accurate. The description in the file splat.py says:

"Hangs/core dumps Python2 when instantiated"

(which is it? hang or core dump?)

but I can't replicate that. Instantiating A() is fine for me. (Tested in Python 2.7 on Linux.)

The whole business about "splat" is amusing but irrelevant. I can replicate the hang (no core dump) using this simpler example:

class B:
    def __getattr__(self, name):
        return name in dir(self)


Instantiating the class is fine, but calling dir() on it locks up:

>>> b = B()
>>> dir(b)

[1]+  Stopped                 python2.7 -E

(after typing Ctrl-Z in the xterm). Notice that B is an old-style class in this example. The same behaviour also occurs when inheriting from object.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34346>
_______________________________________

From report at bugs.python.org  Mon Aug  6 11:39:08 2018
From: report at bugs.python.org (Steap)
Date: Mon, 06 Aug 2018 15:39:08 +0000
Subject: [issue33802] Regression in logging configuration
In-Reply-To: <1528412435.4.0.592728768989.issue33802@psf.upfronthosting.co.za>
Message-ID: <1533569948.01.0.56676864532.issue33802@psf.upfronthosting.co.za>


Steap <tipecaml at gmail.com> added the comment:

It seems like this regression has not completely been fixed: there are still issues with "None":

$ python3.6 -c 'import configparser; configparser.ConfigParser(defaults={"a": None})'

$ python3.7 -c 'import configparser; configparser.ConfigParser(defaults={"a": 1})'

$ python3.7 -c 'import configparser; configparser.ConfigParser(defaults={"a": None})'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.7/configparser.py", line 638, in __init__
    self._read_defaults(defaults)
  File "/usr/lib/python3.7/configparser.py", line 1216, in _read_defaults
    self.read_dict({self.default_section: defaults})
  File "/usr/lib/python3.7/configparser.py", line 753, in read_dict
    self.set(section, key, value)
  File "/usr/lib/python3.7/configparser.py", line 1197, in set
    self._validate_value_types(option=option, value=value)
  File "/usr/lib/python3.7/configparser.py", line 1182, in _validate_value_types
    raise TypeError("option values must be strings")
TypeError: option values must be strings

Should "None" not be used, or should this bug be reopened?

----------
nosy: +Steap

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33802>
_______________________________________

From report at bugs.python.org  Mon Aug  6 12:06:50 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Aug 2018 16:06:50 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
Message-ID: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

The test fails because

byte_str.decode('ascii', 'surragateescape')

is not what ascii(byte_str) - returns when called from the commandline.

Assumption: since " check('utf8', [arg_utf8])" succeeds I assume the parsing of the command-line is correct.

DETAILS
>>> arg = 'h\xe9\u20ac'.encode('utf-8')
>>> arg
b'h\xc3\xa9\xe2\x82\xac'

>>> arg.decode('ascii', 'surrogateescape')
'h\udcc3\udca9\udce2\udc82\udcac'


I am having a difficult time getting the syntax correct for all the "escapes", so I added a print statement in the check routine:

test_cmd_line (test.test_utf8_mode.UTF8ModeTests) ...
code:import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:]))) arg:b'h\xc3\xa9\xe2\x82\xac'
out:UTF-8:['h\xe9\u20ac']

code:import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:]))) arg:b'h\xc3\xa9\xe2\x82\xac'
out:ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

test code with my debug statement (to generate above):

    def test_cmd_line(self):
        arg = 'h\xe9\u20ac'.encode('utf-8')
        arg_utf8 = arg.decode('utf-8')
        arg_ascii = arg.decode('ascii', 'surrogateescape')
        code = 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))'

        def check(utf8_opt, expected, **kw):
            out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
            print("\ncode:%s arg:%s\nout:%s" % (code, arg, out))
            args = out.partition(':')[2].rstrip()
            self.assertEqual(args, ascii(expected), out)

        check('utf8', [arg_utf8])
        if sys.platform == 'darwin' or support.is_android:
            c_arg = arg_utf8
        else:
            c_arg = arg_ascii
        check('utf8=0', [c_arg], LC_ALL='C')

So the first check succeeds:

        check('utf8', [arg_utf8])

But the second does not:

FAIL: test_cmd_line (test.test_utf8_mode.UTF8ModeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/src/python3-3.7.0/Lib/test/test_utf8_mode.py", line 225, in test_cmd_line
    check('utf8=0', [c_arg], LC_ALL='C')
  File "/data/prj/python/src/python3-3.7.0/Lib/test/test_utf8_mode.py", line 218, in check
    self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

I tried saying the "expected" is arg, but arg is still a byte object, the cmd_line result is not (printed as such).

AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "[b'h\\xc3\\xa9\\xe2\\x82\\xac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ [b'h\xc3\xa9\xe2\x82\xac']
?  +
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

----------
components: Interpreter Core, Tests
messages: 323214
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: test_utf8_mode.test_cmd_line fails
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Mon Aug  6 14:38:14 2018
From: report at bugs.python.org (Abhishek Reddy)
Date: Mon, 06 Aug 2018 18:38:14 +0000
Subject: [issue34348] Python 3.7 - Issues Installing Scikit Learn
Message-ID: <1533580694.5.0.56676864532.issue34348@psf.upfronthosting.co.za>


New submission from Abhishek Reddy <abhishek.chamakura at bluestembrands.com>:

Hi

I am currently encountering below issues when trying to install any version of Scikit Learn (0.19.0 or 0.19.1 or 0.19.2)

Python Version - 3.7

/usr/local/bsb-python37 - Custom Location in which I configured and installed Python 3.7

I have installed all the prerequisite - OS packages - bias-devel , lapack-devel , atlas-devel. 

Earlier when I installed Python 2.7 I didn't run into any issues. Now when I re-try to install the scikit learn under Python 2.7 I am running into the same issue and the earlier successful installed version of scikit learn is corrupted.

Error
# /usr/local/bsb-python37/bin/python3.7 setup.py install --prefix=/usr/local/bsb-python37
Partial import of sklearn during the build process.
blas_opt_info:
blas_mkl_info:
customize UnixCCompiler
  libraries mkl_rt not found in ['/usr/local/bsb-python37/lib', '/usr/local/lib64', '/usr/local/lib', '/usr/lib64', '/usr/lib', '/usr/lib/']
  NOT AVAILABLE

blis_info:
customize UnixCCompiler
  libraries blis not found in ['/usr/local/bsb-python37/lib', '/usr/local/lib64', '/usr/local/lib', '/usr/lib64', '/usr/lib', '/usr/lib/']
  NOT AVAILABLE

  error: Command "g++ -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/bsb-python37/lib/python3.7/site-packages/numpy-1.14.5-py3.7-linux-x86_64.egg/numpy/core/include -I/usr/local/bsb-python37/lib/python3.7/site-packages/numpy-1.14.5-py3.7-linux-x86_64.egg/numpy/core/include -I/usr/local/bsb-python37/include/python3.7m -c sklearn/cluster/_dbscan_inner.cpp -o build/temp.linux-x86_64-3.7/sklearn/cluster/_dbscan_inner.o -MMD -MF build/temp.linux-x86_64-3.7/sklearn/cluster/_dbscan_inner.o.d" failed with exit status 1

Any help is greatly appreciated. I tried to google around and did all that I could try. No luck.

Thanks,
Abhishek

----------
components: Installation
messages: 323215
nosy: abhishekreddyc
priority: normal
severity: normal
status: open
title: Python 3.7 - Issues Installing Scikit Learn
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34348>
_______________________________________

From report at bugs.python.org  Mon Aug  6 14:51:49 2018
From: report at bugs.python.org (Jens Troeger)
Date: Mon, 06 Aug 2018 18:51:49 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1533581509.38.0.56676864532.issue24218@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

David, I tried to find the mentioned '\r\r?\n' issue but I could not find it here. However, from an initial investigation into the BytesGenerator, here is what?s happening.

Flattening the body and attachments of the EmailMessage object works, and eventually _write_headers() is called to flatten the headers which happens entry by entry (https://github.com/python/cpython/blob/master/Lib/email/generator.py#L417-L418). Flattening a header entry is a recursive process over the parse tree of the entry, which builds the flattened and encoded final string by descending into the parse tree and encoding & concatenating the individual ?parts? (tokens of the header entry).

Given the parse tree for a header entry like "Mart?n C?rdoba <foo at bar.com>" eventually results in the correct flattened string:

    '=?utf-8?q?Mart=C3=ADn_C=C3=B3rdoba?= <foo at bar.com>\r\n'

at the bottom of the recursion for this ?Mailbox? part. The recursive callstack is then:

    _refold_parse_tree _header_value_parser.py:2687
    fold [Mailbox] _header_value_parser.py:144
    _refold_parse_tree _header_value_parser.py:2630
    fold [Address] _header_value_parser.py:144
    _refold_parse_tree _header_value_parser.py:2630
    fold [AddressList] _header_value_parser.py:144
    _refold_parse_tree _header_value_parser.py:2630
    fold [Header] _header_value_parser.py:144
    fold [_UniqueAddressHeader] headerregistry.py:258
    _fold [EmailPolicy] policy.py:205
    fold_binary [EmailPolicy] policy.py:199
    _write_headers [BytesGenerator] generator.py:418
    _write [BytesGenerator] generator.py:195

The problem now arises from the interplay of 

    # https://github.com/python/cpython/blob/master/Lib/email/_header_value_parser.py#L2629
    encoded_part = part.fold(policy=policy)[:-1] # strip nl

which strips the '\n' from the returned string, and

    # https://github.com/python/cpython/blob/master/Lib/email/_header_value_parser.py#L2686
    return policy.linesep.join(lines) + policy.linesep

which adds the policy?s line separation string linesep="\r\n" to the end of the flattened string upon unrolling the recursion.

I am not sure about a proper fix here, but considering that the linesep policy can be any string length (in this case len("\r\n") == 2) a fixed truncation of one character [:-1] seems wrong. Instead, using:

    encoded_part = part.fold(policy=policy)[:-len(policy.linesep)] # strip nl

seems to work for entries with and without Unicode characters in their display names.

David, please advise on how to proceed from here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Mon Aug  6 14:55:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 06 Aug 2018 18:55:51 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1533581751.47.0.56676864532.issue2122@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8187

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:41:06 2018
From: report at bugs.python.org (Nic Watson)
Date: Mon, 06 Aug 2018 19:41:06 +0000
Subject: [issue34349] asyncio.wait should accept generator of tasks as first
 argument
Message-ID: <1533584466.72.0.56676864532.issue34349@psf.upfronthosting.co.za>


New submission from Nic Watson <pythonbugs at nicwatson.org>:

Currently, passing a generator of coroutines or futures as the first parameter of asyncio.wait raises a TypeError.  This is in conflict with the documentation calling the first parameter a "sequence".

Line in question. https://github.com/python/cpython/blob/3.7/Lib/asyncio/tasks.py#L347

Generators are indeed coroutines, so the check to validate that the first parameter is not a coroutine or a future is too specific.

I'd suggest replacing that line with a check that the passed-in parameter is iterable, i.e. hasattr(futures, __iter__).

----------
components: asyncio
messages: 323217
nosy: asvetlov, jnwatson, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait should accept generator of tasks as first argument
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34349>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:52:45 2018
From: report at bugs.python.org (Chris Fuller)
Date: Mon, 06 Aug 2018 19:52:45 +0000
Subject: [issue34346] dir() hangs interpreter
In-Reply-To: <1533563869.83.0.56676864532.issue34346@psf.upfronthosting.co.za>
Message-ID: <1533585165.53.0.56676864532.issue34346@psf.upfronthosting.co.za>


Change by Chris Fuller <cfuller732 at thinkingplanet.net>:


Removed file: https://bugs.python.org/file47731/splat.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34346>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:53:10 2018
From: report at bugs.python.org (Chris Fuller)
Date: Mon, 06 Aug 2018 19:53:10 +0000
Subject: [issue34346] dir() hangs interpreter
In-Reply-To: <1533563869.83.0.56676864532.issue34346@psf.upfronthosting.co.za>
Message-ID: <1533585190.7.0.56676864532.issue34346@psf.upfronthosting.co.za>


Change by Chris Fuller <cfuller732 at thinkingplanet.net>:


Added file: https://bugs.python.org/file47732/splat.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34346>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:54:59 2018
From: report at bugs.python.org (Chris Fuller)
Date: Mon, 06 Aug 2018 19:54:59 +0000
Subject: [issue34346] dir() hangs interpreter
In-Reply-To: <1533563869.83.0.56676864532.issue34346@psf.upfronthosting.co.za>
Message-ID: <1533585299.05.0.56676864532.issue34346@psf.upfronthosting.co.za>


Chris Fuller <cfuller732 at thinkingplanet.net> added the comment:

It hangs, and on Cygwin it dumped core when I hit ctrl-break. I uploaded a revised script. It';s a heisenbug, all I did was removed the unused splat method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34346>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:55:06 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Aug 2018 19:55:06 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533585306.8.0.56676864532.issue34319@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 5b2657fb8c5aaa98e5748e1c325c74b97ea12fd1 by Terry Jan Reedy (Xtreak) in branch 'master':
bpo-34319: Clarify file handler closure in pathlib.read_text (GH-8645)
https://github.com/python/cpython/commit/5b2657fb8c5aaa98e5748e1c325c74b97ea12fd1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:55:45 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 19:55:45 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533585345.13.0.56676864532.issue34319@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8188

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:55:55 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 19:55:55 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533585355.79.0.56676864532.issue34319@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8189

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Mon Aug  6 15:59:45 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 19:59:45 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533585585.77.0.56676864532.issue34319@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1c6df83e9318ab4ef8e32b805b8226b1324e1ffd by Miss Islington (bot) in branch '3.7':
bpo-34319: Clarify file handler closure in pathlib.read_text (GH-8645)
https://github.com/python/cpython/commit/1c6df83e9318ab4ef8e32b805b8226b1324e1ffd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Mon Aug  6 16:04:33 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Aug 2018 20:04:33 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1533585873.76.0.56676864532.issue34319@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3da5c5c76d90ddfc4c188cc801d9387501b63b7f by Miss Islington (bot) in branch '3.6':
bpo-34319: Clarify file handler closure in pathlib.read_text (GH-8645)
https://github.com/python/cpython/commit/3da5c5c76d90ddfc4c188cc801d9387501b63b7f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Mon Aug  6 16:10:54 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Aug 2018 20:10:54 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1533586254.96.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Felt <michael at felt.demon.nl> added the comment:

In short, I do not understand how this passes on Linux.

This is python3-3.4.6 on sles12:

>>> 'h\xe9\u20ac'.encode('utf-8')
b'h\xc3\xa9\xe2\x82\xac'
>>> ascii('h\xe9\u20ac'.encode('utf-8'))
"b'h\\xc3\\xa9\\xe2\\x82\\xac'"
>>> 'h\xe9\u20ac'.encode('utf-8').decode('us-ascii', 'surrogateescape')
'h\udcc3\udca9\udce2\udc82\udcac'
>>>

This is python3-3.7.0 on AIX:
>>> 'h\xe9\u20ac'.encode('utf-8')
b'h\xc3\xa9\xe2\x82\xac'
>>> ascii('h\xe9\u20ac'.encode('utf-8'))
"b'h\\xc3\\xa9\\xe2\\x82\\xac'"
>>> 'h\xe9\u20ac'.encode('utf-8').decode('us-ascii', 'surrogateescape')
'h\udcc3\udca9\udce2\udc82\udcac'

If I am missing something essential here - please be blunt!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Mon Aug  6 16:26:57 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 06 Aug 2018 20:26:57 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533586254.96.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <385a7a2d-7147-8c9a-8543-b96d23a708ab@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 8/6/2018 10:10 PM, Michael Felt wrote:
> Michael Felt <michael at felt.demon.nl> added the comment:
>
> In short, I do not understand how this passes on Linux.
>
> This is python3-3.4.6 on sles12:
>
>>>> 'h\xe9\u20ac'.encode('utf-8')
> b'h\xc3\xa9\xe2\x82\xac'
>>>> ascii('h\xe9\u20ac'.encode('utf-8'))
> "b'h\\xc3\\xa9\\xe2\\x82\\xac'"
>>>> 'h\xe9\u20ac'.encode('utf-8').decode('us-ascii', 'surrogateescape')
> 'h\udcc3\udca9\udce2\udc82\udcac'
> This is python3-3.7.0 on AIX:
>>>> 'h\xe9\u20ac'.encode('utf-8')
> b'h\xc3\xa9\xe2\x82\xac'
>>>> ascii('h\xe9\u20ac'.encode('utf-8'))
> "b'h\\xc3\\xa9\\xe2\\x82\\xac'"
>>>> 'h\xe9\u20ac'.encode('utf-8').decode('us-ascii', 'surrogateescape')
> 'h\udcc3\udca9\udce2\udc82\udcac'
>
> If I am missing something essential here - please be blunt!
Also seeing the same with Windows.
C:\Users\MICHAELFelt>python
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:06:47) [MSC v.1914 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 'h\xe9\u20ac'.encode('utf-8')
b'h\xc3\xa9\xe2\x82\xac'
>>> ascii('h\xe9\u20ac'.encode('utf-8'))
"b'h\\xc3\\xa9\\xe2\\x82\\xac'"
>>> 'h\xe9\u20ac'.encode('utf-8').decode('ascii','surrogateescape')
'h\udcc3\udca9\udce2\udc82\udcac'
>>>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34347>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file47733/pEpkey.asc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1765 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20180806/f6827c07/attachment.key>

From report at bugs.python.org  Mon Aug  6 16:41:27 2018
From: report at bugs.python.org (Sebastian)
Date: Mon, 06 Aug 2018 20:41:27 +0000
Subject: [issue34350] Non obvious logging handler behaviour
Message-ID: <1533588087.55.0.56676864532.issue34350@psf.upfronthosting.co.za>


New submission from Sebastian <seb.schaetz at gmail.com>:

In Python 3.6.3 I can do:

import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
logger.info("this does not work")
logging.info("PARTY")
logger.info("this works")

And it outputs:

INFO:root:PARTY
INFO:root:this works


The line 
logging.info("PARTY") 
seems to add a handler which makes the last line work. This is very confusing behavior as it is not obvious that a call to "logging.info" mutates the state of the logging subsystem and affects subsequent logging calls.

----------
components: Library (Lib)
messages: 323224
nosy: oneofthose
priority: normal
severity: normal
status: open
title: Non obvious logging handler behaviour
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34350>
_______________________________________

From report at bugs.python.org  Mon Aug  6 16:56:24 2018
From: report at bugs.python.org (Erik Janssens)
Date: Mon, 06 Aug 2018 20:56:24 +0000
Subject: [issue27186] add os.fspath()
In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io>
Message-ID: <1533588984.36.0.56676864532.issue27186@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

is there a particular reason for PyOS_FSPath to live in posixmodule.c

since Objects/unicodeobject.c uses this function, this makes it not possible to compile Python without a posixmodule.

this makes it difficult to compile a 'core' python on a new platform, since implementing the posixmodule on a new platform is not trivial.

also the documentation on porting mentions that one should first port python without a posixmodule.

----------
nosy: +erikjanss

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27186>
_______________________________________

From report at bugs.python.org  Mon Aug  6 17:01:10 2018
From: report at bugs.python.org (Vadim Pushtaev)
Date: Mon, 06 Aug 2018 21:01:10 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1533589270.68.0.56676864532.issue34284@psf.upfronthosting.co.za>


Vadim Pushtaev <pushtaev.vm at gmail.com> added the comment:

Sorry for the delay, I'm still working on a new PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34284>
_______________________________________

From report at bugs.python.org  Mon Aug  6 17:03:42 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Aug 2018 21:03:42 +0000
Subject: [issue34350] Non obvious logging handler behaviour
In-Reply-To: <1533588087.55.0.56676864532.issue34350@psf.upfronthosting.co.za>
Message-ID: <1533589422.6.0.56676864532.issue34350@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The behaviour is long-standing and documented, in the note just under this entry: https://docs.python.org/3/library/logging.html?highlight=logging#logging.log

But I do agree that it's surprising and (at least for me) undesirable behaviour, in that it makes it way too easy to accidentally configure logging in library code, which is a no-no according to most logging "best practices" advice. (Applications do logging configuration; libraries should usually confine themselves to creating loggers and emitting log messages.)

But I suspect it would be rather hard to change now.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34350>
_______________________________________

From report at bugs.python.org  Mon Aug  6 17:05:29 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 06 Aug 2018 21:05:29 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1533589529.61.0.56676864532.issue2122@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Mon Aug  6 17:11:56 2018
From: report at bugs.python.org (epiphyte)
Date: Mon, 06 Aug 2018 21:11:56 +0000
Subject: [issue34349] asyncio.wait should accept generator of tasks as first
 argument
In-Reply-To: <1533584466.72.0.56676864532.issue34349@psf.upfronthosting.co.za>
Message-ID: <1533589916.47.0.56676864532.issue34349@psf.upfronthosting.co.za>


Change by epiphyte <epiphyte at vertex.link>:


----------
nosy: +epiphyte

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34349>
_______________________________________

From report at bugs.python.org  Mon Aug  6 18:20:02 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Aug 2018 22:20:02 +0000
Subject: [issue27186] add os.fspath()
In-Reply-To: <1533588984.36.0.56676864532.issue27186@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7Vx31hC=8bi+zH2esYKv532WU50VFGox9zNDerEML90w@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Mon, Aug 6, 2018, 13:56 Erik Janssens, <report at bugs.python.org> wrote:

>
> Erik Janssens <erik.janssens at conceptive.be> added the comment:
>
> is there a particular reason for PyOS_FSPath to live in posixmodule.c
>

It's there because the C API for the os module is kept in that module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27186>
_______________________________________

From report at bugs.python.org  Mon Aug  6 20:08:43 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Aug 2018 00:08:43 +0000
Subject: [issue31047] Windows: os.path.isabs(os.path.abspath(" ")) == False
In-Reply-To: <1501087649.97.0.982453892523.issue31047@psf.upfronthosting.co.za>
Message-ID: <1533600523.17.0.56676864532.issue31047@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset b0bf51b32240369ccb736dc32ff82bb96f375402 by Steve Dower in branch '3.6':
bpo-31047: Fix ntpath.abspath for invalid paths (GH-8544)
https://github.com/python/cpython/commit/b0bf51b32240369ccb736dc32ff82bb96f375402


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31047>
_______________________________________

From report at bugs.python.org  Mon Aug  6 20:40:02 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Aug 2018 00:40:02 +0000
Subject: [issue34343] Why is turtle still present in python embedded for
 Windows?
In-Reply-To: <1533547471.89.0.56676864532.issue34343@psf.upfronthosting.co.za>
Message-ID: <1533602402.36.0.56676864532.issue34343@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

No particular reason. Just needs to be added to EXCLUDE_FILE_FROM_LIBRARY in Tools/msi/make_zip.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34343>
_______________________________________

From report at bugs.python.org  Mon Aug  6 20:41:07 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Aug 2018 00:41:07 +0000
Subject: [issue31047] Windows: os.path.isabs(os.path.abspath(" ")) == False
In-Reply-To: <1501087649.97.0.982453892523.issue31047@psf.upfronthosting.co.za>
Message-ID: <1533602467.34.0.56676864532.issue31047@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31047>
_______________________________________

From report at bugs.python.org  Mon Aug  6 22:12:21 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 07 Aug 2018 02:12:21 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533607941.97.0.56676864532.issue18540@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e4dcbbd7f4ac18d01c0ec85f64ae98b8281ed403 by Berker Peksag in branch 'master':
bpo-18540: Fix EAI_NONAME in imaplib.IMAP4*() (GH-8634)
https://github.com/python/cpython/commit/e4dcbbd7f4ac18d01c0ec85f64ae98b8281ed403


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Mon Aug  6 22:12:36 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Aug 2018 02:12:36 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533607956.74.0.56676864532.issue18540@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8190

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Mon Aug  6 22:12:44 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Aug 2018 02:12:44 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533607964.21.0.56676864532.issue18540@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8191

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Mon Aug  6 22:37:41 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 07 Aug 2018 02:37:41 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533609461.56.0.56676864532.issue18540@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 5799e5a84c78eac672e5f5f4f3fd2d903ba51a9d by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-18540: Fix EAI_NONAME in imaplib.IMAP4*() (GH-8634)
https://github.com/python/cpython/commit/5799e5a84c78eac672e5f5f4f3fd2d903ba51a9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Mon Aug  6 22:38:08 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 07 Aug 2018 02:38:08 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533609488.16.0.56676864532.issue18540@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 671a13a7b6ff1022a6fd868e5842687123ab9fd1 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-18540: Fix EAI_NONAME in imaplib.IMAP4*() (GH-8634)
https://github.com/python/cpython/commit/671a13a7b6ff1022a6fd868e5842687123ab9fd1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Mon Aug  6 22:38:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 07 Aug 2018 02:38:52 +0000
Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on
 Fedora 18
In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za>
Message-ID: <1533609532.62.0.56676864532.issue18540@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18540>
_______________________________________

From report at bugs.python.org  Tue Aug  7 00:39:32 2018
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 07 Aug 2018 04:39:32 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533616772.87.0.56676864532.issue34296@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

* While this issue is "pre warming VM", VM startup is not significant part of your 500ms.
* You're talking about application specific strategy now.  It's different of this issue.

And many ideas like yours are already discussed on ML, again and again.  I feel nothing is new or concrete.  It's not productive at all.

I want to close this issue.  Please give us more concrete idea or patch with target sample application you want to optimize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Tue Aug  7 00:49:59 2018
From: report at bugs.python.org (David Kopec)
Date: Tue, 07 Aug 2018 04:49:59 +0000
Subject: [issue31689] random.choices does not work with negative weights
In-Reply-To: <1507121599.13.0.213398074469.issue31689@psf.upfronthosting.co.za>
Message-ID: <1533617399.6.0.56676864532.issue31689@psf.upfronthosting.co.za>


David Kopec <snpukwana at gmail.com> added the comment:

It's not a bug, but I agree with Allen that it could use a much more clear error message. I think his proposed ValueError makes a lot more sense than just raising an IndexError as currently occurs. This will help people debug their programs who don't even realize they're accidentally using negative weights to begin with.

----------
nosy: +davecom
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31689>
_______________________________________

From report at bugs.python.org  Tue Aug  7 01:33:25 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Tue, 07 Aug 2018 05:33:25 +0000
Subject: [issue34343] Why is turtle still present in python embedded for
 Windows?
In-Reply-To: <1533547471.89.0.56676864532.issue34343@psf.upfronthosting.co.za>
Message-ID: <1533620005.13.0.56676864532.issue34343@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

Thank you very much. Then I will simply remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34343>
_______________________________________

From report at bugs.python.org  Tue Aug  7 03:56:44 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Aug 2018 07:56:44 +0000
Subject: [issue34348] Python 3.7 - Issues Installing Scikit Learn
In-Reply-To: <1533580694.5.0.56676864532.issue34348@psf.upfronthosting.co.za>
Message-ID: <1533628604.08.0.56676864532.issue34348@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Have you reported this upstream to the scikit-learn folks? scikit-learn is not part of core Python, so there's probably not a lot we can do here.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34348>
_______________________________________

From report at bugs.python.org  Tue Aug  7 04:07:14 2018
From: report at bugs.python.org (TROUVERIE Joachim)
Date: Tue, 07 Aug 2018 08:07:14 +0000
Subject: [issue29612] TarFile.extract() suffers from hard links inside tarball
In-Reply-To: <1487671846.82.0.103027933595.issue29612@psf.upfronthosting.co.za>
Message-ID: <1533629234.42.0.56676864532.issue29612@psf.upfronthosting.co.za>


Change by TROUVERIE Joachim <joachim.trouverie at linoame.fr>:


----------
pull_requests: +8192

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29612>
_______________________________________

From report at bugs.python.org  Tue Aug  7 05:24:40 2018
From: report at bugs.python.org (Alisue Lambda)
Date: Tue, 07 Aug 2018 09:24:40 +0000
Subject: [issue33350] WinError 10038 is raised when loop.sock_connect is
 wrapped with asyncio.wait_for
In-Reply-To: <1524588676.0.0.682650639539.issue33350@psf.upfronthosting.co.za>
Message-ID: <1533633880.33.0.56676864532.issue33350@psf.upfronthosting.co.za>


Alisue Lambda <lambdalisue at hashnote.net> added the comment:

I use the following patch to fix the behavior in Windows.


```
import sys

if sys.platform != 'win32':
    def patch():
        pass
else:
    def patch():
        """Patch selectors.SelectSelector to fix WinError 10038 in Windows

        Ref: https://bugs.python.org/issue33350
        """

        import select
        from selectors import SelectSelector

        def _select(self, r, w, _, timeout=None):
            try:
                r, w, x = select.select(r, w, w, timeout)
            except OSError as e:
                if hasattr(e, 'winerror') and e.winerror == 10038:
                    # descriptors may already be closed
                    return [], [], []
                raise
            else:
                return r, w + x, []

        SelectSelector._select = _select
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33350>
_______________________________________

From report at bugs.python.org  Tue Aug  7 05:56:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 07 Aug 2018 09:56:50 +0000
Subject: [issue34349] asyncio.wait should accept generator of tasks as first
 argument
In-Reply-To: <1533584466.72.0.56676864532.issue34349@psf.upfronthosting.co.za>
Message-ID: <1533635810.17.0.56676864532.issue34349@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34349>
_______________________________________

From report at bugs.python.org  Tue Aug  7 06:50:15 2018
From: report at bugs.python.org (Conrad Ho)
Date: Tue, 07 Aug 2018 10:50:15 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533639015.94.0.56676864532.issue24255@psf.upfronthosting.co.za>


Conrad Ho <conrad.alwin.ho at gmail.com> added the comment:

Hi Sanyam, were you able to fix the CI errors?

The fixes for the infinite loop that you are seeing in your PR CI run and the changes to test correct logging (vs testing stdout) etc are in my original patch already. I've checked that the test suite passes with my patch.

Otherwise, should I try to submit a PR / what's the best way to move this forward? It's my first contribution to cpython!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Tue Aug  7 07:43:06 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 07 Aug 2018 11:43:06 +0000
Subject: [issue31940] copystat on symlinks fails for alpine -- faulty lchmod
 implementation?
In-Reply-To: <1509753073.77.0.213398074469.issue31940@psf.upfronthosting.co.za>
Message-ID: <1533642186.77.0.56676864532.issue31940@psf.upfronthosting.co.za>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31940>
_______________________________________

From report at bugs.python.org  Tue Aug  7 07:53:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 07 Aug 2018 11:53:25 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1533642805.74.0.56676864532.issue34284@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue5322 may has a relation to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34284>
_______________________________________

From report at bugs.python.org  Tue Aug  7 10:20:15 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 07 Aug 2018 14:20:15 +0000
Subject: [issue34349] asyncio.wait should accept generator of tasks as first
 argument
In-Reply-To: <1533584466.72.0.56676864532.issue34349@psf.upfronthosting.co.za>
Message-ID: <1533651615.32.0.56676864532.issue34349@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Since we're deprecating generator-based coroutines anyways, I too think that the check can be relaxed.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34349>
_______________________________________

From report at bugs.python.org  Tue Aug  7 10:46:04 2018
From: report at bugs.python.org (Abhishek Reddy)
Date: Tue, 07 Aug 2018 14:46:04 +0000
Subject: [issue34348] Python 3.7 - Issues Installing Scikit Learn
In-Reply-To: <1533628604.08.0.56676864532.issue34348@psf.upfronthosting.co.za>
Message-ID: <A2A3BBCE-37BD-41EF-A294-EDA59A2B7D04@bluestembrands.com>


Abhishek Reddy <abhishek.chamakura at bluestembrands.com> added the comment:

Hi Mark,

Thank you for your update. How do I reach to the upstream scikit-learn folks ?

Thanks,
Abhishek

?On 8/7/18, 2:56 AM, "Mark Dickinson" <report at bugs.python.org> wrote:

    Mark Dickinson <dickinsm at gmail.com> added the comment:

    Have you reported this upstream to the scikit-learn folks? scikit-learn is not part of core Python, so there's probably not a lot we can do here.

    ----------
    nosy: +mark.dickinson

    _______________________________________
    Python tracker <report at bugs.python.org>
    <https://bugs.python.org/issue34348>
    _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34348>
_______________________________________

From report at bugs.python.org  Tue Aug  7 10:55:20 2018
From: report at bugs.python.org (Abhishek Reddy)
Date: Tue, 07 Aug 2018 14:55:20 +0000
Subject: [issue34351] Python 3.7 - Issues Installing Scikit Learn
Message-ID: <1533653720.64.0.56676864532.issue34351@psf.upfronthosting.co.za>


New submission from Abhishek Reddy <abhishek.chamakura at bluestembrands.com>:

Hi

I am currently encountering below issues when trying to install any version of Scikit Learn (0.19.0 or 0.19.1 or 0.19.2) on Linux - RHEL / Centos 7 OS. 

Few months back I could successfully install scikit-learn under python 2.7 without issues. When I re-run the installation of scikit-learn package under python 2.7 its failing with the same below error.

I have installed all the required dependencies of OS and Python packages for scikit-learn

Python Version - 3.7

/usr/local/bsb-python37 - Custom Location in which I configured and installed Python 3.7

I have installed all the prerequisite - OS packages - bias-devel , lapack-devel , atlas-devel. 

Earlier when I installed Python 2.7 I didn't run into any issues. Now when I re-try to install the scikit learn under Python 2.7 I am running into the same issue and the earlier successful installed version of scikit learn is corrupted.

Error
# /usr/local/bsb-python37/bin/python3.7 setup.py install --prefix=/usr/local/bsb-python37
Partial import of sklearn during the build process.
blas_opt_info:
blas_mkl_info:
customize UnixCCompiler
  libraries mkl_rt not found in ['/usr/local/bsb-python37/lib', '/usr/local/lib64', '/usr/local/lib', '/usr/lib64', '/usr/lib', '/usr/lib/']
  NOT AVAILABLE

blis_info:
customize UnixCCompiler
  libraries blis not found in ['/usr/local/bsb-python37/lib', '/usr/local/lib64', '/usr/local/lib', '/usr/lib64', '/usr/lib', '/usr/lib/']
  NOT AVAILABLE

  error: Command "g++ -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/bsb-python37/lib/python3.7/site-packages/numpy-1.14.5-py3.7-linux-x86_64.egg/numpy/core/include -I/usr/local/bsb-python37/lib/python3.7/site-packages/numpy-1.14.5-py3.7-linux-x86_64.egg/numpy/core/include -I/usr/local/bsb-python37/include/python3.7m -c sklearn/cluster/_dbscan_inner.cpp -o build/temp.linux-x86_64-3.7/sklearn/cluster/_dbscan_inner.o -MMD -MF build/temp.linux-x86_64-3.7/sklearn/cluster/_dbscan_inner.o.d" failed with exit status 1

Any help is greatly appreciated. I tried to google around and did all that I could try. No luck.

Thanks,
Abhishek

----------
components: Library (Lib)
messages: 323243
nosy: abhishekreddyc
priority: normal
severity: normal
status: open
title: Python 3.7 - Issues Installing Scikit Learn
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34351>
_______________________________________

From report at bugs.python.org  Tue Aug  7 11:17:29 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Aug 2018 15:17:29 +0000
Subject: [issue34348] Python 3.7 - Issues Installing Scikit Learn
In-Reply-To: <1533580694.5.0.56676864532.issue34348@psf.upfronthosting.co.za>
Message-ID: <1533655049.57.0.56676864532.issue34348@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> How do I reach to the upstream scikit-learn folks ?

See http://scikit-learn.org/stable/support.html

Closing here.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34348>
_______________________________________

From report at bugs.python.org  Tue Aug  7 11:24:36 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 07 Aug 2018 15:24:36 +0000
Subject: [issue34351] Python 3.7 - Issues Installing Scikit Learn
In-Reply-To: <1533653720.64.0.56676864532.issue34351@psf.upfronthosting.co.za>
Message-ID: <1533655476.86.0.56676864532.issue34351@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as duplicate of #34348.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34351>
_______________________________________

From report at bugs.python.org  Tue Aug  7 12:52:40 2018
From: report at bugs.python.org (Anthony Guevara)
Date: Tue, 07 Aug 2018 16:52:40 +0000
Subject: [issue34352] Using tailf with python3.4
Message-ID: <1533660760.63.0.56676864532.issue34352@psf.upfronthosting.co.za>


New submission from Anthony Guevara <amboxer21 at gmail.com>:

When using tailf with Python2.7 there are no issues. When using tailf with Python3.4 some print statements use the old version 2 style. Python3 also complains about an implicit conversion. I have included a patch.

----------
components: Distutils
files: tailf.patch
keywords: patch
messages: 323246
nosy: amboxer21, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Using tailf with python3.4
type: crash
versions: Python 3.4
Added file: https://bugs.python.org/file47734/tailf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34352>
_______________________________________

From report at bugs.python.org  Tue Aug  7 12:57:04 2018
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Aug 2018 16:57:04 +0000
Subject: [issue34352] Using tailf with python3.4
In-Reply-To: <1533660760.63.0.56676864532.issue34352@psf.upfronthosting.co.za>
Message-ID: <1533661024.01.0.56676864532.issue34352@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

That appears to be a third-party project, though I can't find it via Google.  You'll need to submit your patch to that project; there's nothing we can do with it here.

----------
components:  -Distutils
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34352>
_______________________________________

From report at bugs.python.org  Tue Aug  7 13:23:14 2018
From: report at bugs.python.org (G)
Date: Tue, 07 Aug 2018 17:23:14 +0000
Subject: [issue34353] stat's python implementation of filemode (fallback)
 doesn't behave like the C implementation
Message-ID: <1533662594.31.0.56676864532.issue34353@psf.upfronthosting.co.za>


New submission from G <gpery at protonmail.com>:

stat.py (Lib/stat.py)'s implementation of filemode doesn't account for socket-type files, while _stat (Modules/_stat.c) does, using S_IFSOCK.

----------
components: Library (Lib)
messages: 323248
nosy: gpery
priority: normal
severity: normal
status: open
title: stat's python implementation of filemode (fallback) doesn't behave like the C implementation
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34353>
_______________________________________

From report at bugs.python.org  Tue Aug  7 13:28:48 2018
From: report at bugs.python.org (G)
Date: Tue, 07 Aug 2018 17:28:48 +0000
Subject: [issue34353] stat's python implementation of filemode (fallback)
 doesn't behave like the C implementation
In-Reply-To: <1533662594.31.0.56676864532.issue34353@psf.upfronthosting.co.za>
Message-ID: <1533662928.39.0.56676864532.issue34353@psf.upfronthosting.co.za>


Change by G <gpery at protonmail.com>:


----------
keywords: +patch
pull_requests: +8193
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34353>
_______________________________________

From report at bugs.python.org  Tue Aug  7 15:07:56 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Tue, 07 Aug 2018 19:07:56 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533668876.9.0.56676864532.issue24255@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hey Conrad,

I've merged your fixes as well. They are in the PR now. Also added your name in the NEWS entry :)

@Vinay, I noticed that there are linting errors in `test_logging.py`. Does it make sense to issue a separate Pull Request to fix those? Currently, I've fixed them in the current Pull Request. Please let me know :)

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Tue Aug  7 16:23:35 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 07 Aug 2018 20:23:35 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1533673415.26.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Common "experts" - feedback needed!

Original
test test_utf8_mode failed -- Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test_utf8_mode.py", line 225, in test_cmd_line
    check('utf8=0', [c_arg], LC_ALL='C')
  File "/data/prj/python/git/python3-3.8/Lib/test/test_utf8_mode.py", line 217, in check
    self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

Modification #1:
        if sys.platform == 'darwin' or support.is_android:
            c_arg = arg_utf8
        elif sys.platform.startswith("aix"):
            c_arg = arg_ascii.encode('utf-8', 'surrogateescape')
        else:
            c_arg = arg_ascii
        check('utf8=0', [c_arg], LC_ALL='C')

Result:
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "[b'h\\xc3\\xa9\\xe2\\x82\\xac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ [b'h\xc3\xa9\xe2\x82\xac']
?  +
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

Modifiction #2:
        if sys.platform == 'darwin' or support.is_android:
            c_arg = arg_utf8
        elif sys.platform.startswith("aix"):
            c_arg = arg
        else:
            c_arg = arg_ascii
        check('utf8=0', [c_arg], LC_ALL='C')

AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "[b'h\\xc3\\xa9\\xe2\\x82\\xac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ [b'h\xc3\xa9\xe2\x82\xac']
?  +
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

The "expected" continues to be a "bytes" object, while the CLI code returns a non-byte string.
Or - the original has an ascii string object but uses \udc rather than \x

\udc is common (i.e., I see it frequently in googled results on other things) - should something in ascii() be changed to output \udc rather than \x ?

Thx!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Tue Aug  7 16:29:10 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 07 Aug 2018 20:29:10 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
In-Reply-To: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>
Message-ID: <1533673750.19.0.56676864532.issue34335@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset d2ac400267940f35d731d66c2dafafe099d770d9 by Mariatta (Mikhail Terekhov) in branch 'master':
bpo-34335: Use async/await syntax in documentation examples (GH-8674)
https://github.com/python/cpython/commit/d2ac400267940f35d731d66c2dafafe099d770d9


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Tue Aug  7 16:29:30 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Aug 2018 20:29:30 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
In-Reply-To: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>
Message-ID: <1533673770.61.0.56676864532.issue34335@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8195

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Tue Aug  7 16:33:35 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Aug 2018 20:33:35 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
In-Reply-To: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>
Message-ID: <1533674015.31.0.56676864532.issue34335@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fac49762c53822c40f24dcb5ca4945cffdf40cd9 by Miss Islington (bot) in branch '3.7':
bpo-34335: Use async/await syntax in documentation examples (GH-8674)
https://github.com/python/cpython/commit/fac49762c53822c40f24dcb5ca4945cffdf40cd9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Tue Aug  7 17:03:52 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 07 Aug 2018 21:03:52 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
In-Reply-To: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>
Message-ID: <1533675832.42.0.56676864532.issue34335@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Tue Aug  7 17:06:20 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 07 Aug 2018 21:06:20 +0000
Subject: [issue34335] Fix examples in asyncio docs (suppliment to bpo-32258)
In-Reply-To: <1533423382.45.0.56676864532.issue34335@psf.upfronthosting.co.za>
Message-ID: <1533675980.37.0.56676864532.issue34335@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34335>
_______________________________________

From report at bugs.python.org  Tue Aug  7 17:40:43 2018
From: report at bugs.python.org (Cyker Way)
Date: Tue, 07 Aug 2018 21:40:43 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533678043.0.0.56676864532.issue34296@psf.upfronthosting.co.za>


Cyker Way <cykerway at gmail.com> added the comment:

>   While this issue is "pre warming VM", VM startup is not significant part of your 500ms.

10-20ms should be OK for shell scripts. But a fork is still faster.  

>   You're talking about application specific strategy now. It's different of this issue.

Actually, this issue is created to look for a generic approach that can optimize the running time for most, or even all, python scripts. Different scripts may import different modules, but this doesn't mean there isn't a method that works for all of them.

>   And many ideas like yours are already discussed on ML, again and again.

I browsed about 6-7 threads on python-dev. I think 2-3 of them provide great information. But I don't think any of them gives concrete solutions. So we are still facing this problem today.

>   I want to close this issue. Please give us more concrete idea or patch with target sample application you want to optimize.

As said I'm looking for a generic approach. So optimizing specific applications isn't really the goal of this issue (though work on specific modules still helps). I did implement a proof of concept (link: <https://github.com/cykerway/pyforkexec>) for the fork-exec startup approach. It's still very rough and elementary, but proves this approach has its value. As Nick said:

>   ...the CPython runtime is highly configurable, so it's far from clear what, if anything, could be shared from run to run...

What I hope is we can inspect these configurations and figure out the invariants. This would help us make a clean environment as the forking base. If this is impossible, I think we can still fork from a known interpreter state chosen by the user script author. You may close this issue if nobody has more to say, but I hope the fork-exec startup can be standardized one day as I believe, for quick scripts, however much you optimize the cold start it can't be faster than a fork.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Tue Aug  7 18:42:55 2018
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Aug 2018 22:42:55 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533681775.71.0.56676864532.issue24255@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We generally do not fix "linting errors" unless they reveal logic errors or we touch the lines of code for some other reason.  We also follow the existing style of a module rather than any particular style guide (the stdlib modules are often older than all of the style guides...even PEP8).  In short, omit those changes from your PR, and don't bother creating a separate one, it would just get rejected ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Tue Aug  7 20:29:59 2018
From: report at bugs.python.org (Nikolas Vanderhoof)
Date: Wed, 08 Aug 2018 00:29:59 +0000
Subject: [issue34338] abstractmethod can run on classes
In-Reply-To: <1533486586.96.0.56676864532.issue34338@psf.upfronthosting.co.za>
Message-ID: <1533688199.66.0.56676864532.issue34338@psf.upfronthosting.co.za>


Nikolas Vanderhoof <nikolasrvanderhoof at gmail.com> added the comment:

This behavior is consistent with the behavior described in the documentation for `@classmethod`.

https://docs.python.org/3.6/library/functions.html?highlight=classmethod#classmethod

"It can be called either on the class (such as C.f()) or on an instance (such as C().f())."

In this case, it can't be called on an instance because it is abstract, but since it's a classmethod, it is still okay to call it on the class directly.

----------
nosy: +nikvanderhoof

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34338>
_______________________________________

From report at bugs.python.org  Tue Aug  7 20:32:28 2018
From: report at bugs.python.org (Nikolas Vanderhoof)
Date: Wed, 08 Aug 2018 00:32:28 +0000
Subject: [issue34338] abstractmethod can run on classes
In-Reply-To: <1533486586.96.0.56676864532.issue34338@psf.upfronthosting.co.za>
Message-ID: <1533688348.97.0.56676864532.issue34338@psf.upfronthosting.co.za>


Nikolas Vanderhoof <nikolasrvanderhoof at gmail.com> added the comment:

I've also posted that response on stackoverflow to your question in case others have the same confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34338>
_______________________________________

From report at bugs.python.org  Tue Aug  7 22:35:47 2018
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 08 Aug 2018 02:35:47 +0000
Subject: [issue28044] Make the sidebar in the documentation follow the section
 automatically
In-Reply-To: <1473423727.81.0.401970346659.issue28044@psf.upfronthosting.co.za>
Message-ID: <1533695747.27.0.56676864532.issue28044@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Nice implementation of sticky sidebar.
https://css-tricks.com/sticky-smooth-active-nav/#more-273952

I haven't looked at the patch, and don't know what R. David Murray doesn't like about how it works, but I find the Python sidebar extremely annoying because it scrolls off the top, and would rather it stayed around visible.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28044>
_______________________________________

From report at bugs.python.org  Tue Aug  7 22:50:23 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 08 Aug 2018 02:50:23 +0000
Subject: [issue28044] Make the sidebar in the documentation follow the section
 automatically
In-Reply-To: <1473423727.81.0.401970346659.issue28044@psf.upfronthosting.co.za>
Message-ID: <1533696623.57.0.56676864532.issue28044@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Really sorry, but this issue is now out of date, and the patch no longer applies.

The Python documentation theme is now being tracked in https://github.com/python/python-docs-theme/

Perhaps bring up this issue there?

Thanks.

----------
nosy: +Mariatta
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28044>
_______________________________________

From report at bugs.python.org  Tue Aug  7 22:58:08 2018
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 08 Aug 2018 02:58:08 +0000
Subject: [issue28044] Make the sidebar in the documentation follow the section
 automatically
In-Reply-To: <1473423727.81.0.401970346659.issue28044@psf.upfronthosting.co.za>
Message-ID: <1533697088.6.0.56676864532.issue28044@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Uh, thanks, I guess, but it wasn't marked out of date or resolved or closed when I commented. I haven't used the GitHub issue tracker. Sigh. There should be a link here to the issue that was copied there, to make it easy and obvious?

----------
nosy:  -Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28044>
_______________________________________

From report at bugs.python.org  Tue Aug  7 23:08:32 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 08 Aug 2018 03:08:32 +0000
Subject: [issue28044] Make the sidebar in the documentation follow the section
 automatically
In-Reply-To: <1473423727.81.0.401970346659.issue28044@psf.upfronthosting.co.za>
Message-ID: <1533697712.21.0.56676864532.issue28044@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

You can file a new issue in https://github.com/python/python-docs-theme/ and just add a link to this issue from GitHub in the description.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28044>
_______________________________________

From report at bugs.python.org  Tue Aug  7 23:35:40 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 08 Aug 2018 03:35:40 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533678043.0.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <CAEfz+TwNxRkizA9ROLOMb6RjNyCZf9b093v3E6Ej4zeJBsyruQ@mail.gmail.com>


INADA Naoki <songofacandy at gmail.com> added the comment:

On Wed, Aug 8, 2018 at 6:40 AM Cyker Way <report at bugs.python.org> wrote:
>
> Cyker Way <cykerway at gmail.com> added the comment:
>
> >   While this issue is "pre warming VM", VM startup is not significant part of your 500ms.
>
> 10-20ms should be OK for shell scripts. But a fork is still faster.
>
> >   You're talking about application specific strategy now. It's different of this issue.
>
> Actually, this issue is created to look for a generic approach that can optimize the running time for most, or even all, python scripts. Different scripts may import different modules, but this doesn't mean there isn't a method that works for all of them.
>

"Fork before loading any modules" and "fork after loading application"
are totally different.
It's not generic.  Former can be done by Python core, but I'm not sure
it's really helpful.
Later can be done in some framework.  And it can be battle tested on
3rd party CLI framework
before adding it to Python stdlib.

> >   And many ideas like yours are already discussed on ML, again and again.
>
> I browsed about 6-7 threads on python-dev. I think 2-3 of them provide great information. But I don't think any of them gives concrete solutions. So we are still facing this problem today.
>

I didn't mean it's solved.  I meant many people said same idea again and again,
and I'm tired to read such random ideas.
Python provides os.fork already.  People can use it.  CLI frameworks can use it.
So what Python should be provide additionally?

> >   I want to close this issue. Please give us more concrete idea or patch with target sample application you want to optimize.
>
> As said I'm looking for a generic approach. So optimizing specific applications isn't really the goal of this issue (though work on specific modules still helps). I did implement a proof of concept (link: <https://github.com/cykerway/pyforkexec>) for the fork-exec startup approach. It's still very rough and elementary, but proves this approach has its value. As Nick said:
>

I doubt there is generic and safe approach which is fit in stdlib.
For example, your PoC includes several considerable points:

* Different Python, venv, or application version may listen the unix socket.
* Where should be the socket listen?  How about socket permission?
* Environment variable may be differ.
* When the server is not used for a long time, it should be exit automatically.
  Client start server if there are no server listening.

I prefer battle-testing idea as 3rd party tool first.  Then, we can
discuss about
we should add it on stdlib or not.

"Add it on PyPI first" approach has several benefits:

* It can be used with older Python.
* It can be evolve quickly than Python's 1.5year release cycle.

> >   ...the CPython runtime is highly configurable, so it's far from clear what, if anything, could be shared from run to run...
>
> What I hope is we can inspect these configurations and figure out the invariants. This would help us make a clean environment as the forking base. If this is impossible, I think we can still fork from a known interpreter state chosen by the user script author. You may close this issue if nobody has more to say, but I hope the fork-exec startup can be standardized one day as I believe, for quick scripts, however much you optimize the cold start it can't be faster than a fork.
>

It relating only with "former" (fork before loading application) approach.
I don't think it's really worth enough.  Benefits will be very small compared to
it's danger and complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Wed Aug  8 01:21:01 2018
From: report at bugs.python.org (Vinicius Pacheco)
Date: Wed, 08 Aug 2018 05:21:01 +0000
Subject: [issue34354] Memory leak on _testCongestion
Message-ID: <1533705661.31.0.56676864532.issue34354@psf.upfronthosting.co.za>


New submission from Vinicius Pacheco <vfpweb at gmail.com>:

Following this document https://devguide.python.org/ to compile the python I've got a memory leak on the test _testCongestion. This test is on the file Lib/test/test_socket.py.

The line that show me the issue is:

while True:
    self.cli.sendto(self.data, 0, (HOST, self.port))

The process enters on the "while" and never finish. I'm using a Fedora 28 on this test.

----------
components: Interpreter Core
messages: 323262
nosy: Vinicius Pacheco
priority: normal
severity: normal
status: open
title: Memory leak on _testCongestion
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34354>
_______________________________________

From report at bugs.python.org  Wed Aug  8 02:47:22 2018
From: report at bugs.python.org (Yohan Boniface)
Date: Wed, 08 Aug 2018 06:47:22 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
Message-ID: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>


New submission from Yohan Boniface <yohanboniface at free.fr>:

Hi!

Just installed 3.7 (ArchLinux) and I've a SIGSEGV on one of my projects.
I've a hard time reducing to a minimal testcase, because it seems whatever random piece of code I remove the crash disappears at some point.

Here is the repository:

https://framagit.org/ybon/trefle

To reproduce, install the project in a 3.7 venv with `python setup.py develop` then run `python trefle/bin.py` (or even `python -c 'from trefle import routine'`).

Here is the output I have:

```
Initializing config
Done initializing config
fish: ?python trefle/bin.py? terminated by signal SIGSEGV (Address boundary error)
```

Here are some elements:

- if I run the code with PYTHONMALLOC=debug, I have no crash
- the project is using quite a lot of unicode (French content written in config files), even in some file names
- the project is using asyncio (but it does not seem directly related at first look)
- it is running without issue as is on python 3.6

Here is a gdb backtrace:

```
$ gdb python                                                                                                                                GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...(no debugging symbols found)...done.
(gdb) run trefle/bin.py 
Starting program: /home/ybon/.virtualenvs/trefle/bin/python trefle/bin.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Initializing config
Done initializing config

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff791a9ce in PyObject_Malloc () from /usr/lib/libpython3.7m.so.1.0
(gdb) backtrace 
#0  0x00007ffff791a9ce in PyObject_Malloc () from /usr/lib/libpython3.7m.so.1.0
#1  0x00007ffff79fec6e in ?? () from /usr/lib/libpython3.7m.so.1.0
#2  0x00007ffff7a05874 in PyParser_ASTFromStringObject () from /usr/lib/libpython3.7m.so.1.0
#3  0x00007ffff7a693f2 in Py_CompileStringObject () from /usr/lib/libpython3.7m.so.1.0
#4  0x00007ffff7a695c3 in ?? () from /usr/lib/libpython3.7m.so.1.0
#5  0x00007ffff795963f in _PyMethodDef_RawFastCallDict () from /usr/lib/libpython3.7m.so.1.0
#6  0x00007ffff79597d1 in _PyCFunction_FastCallDict () from /usr/lib/libpython3.7m.so.1.0
#7  0x00007ffff79f7e16 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#8  0x00007ffff7939069 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#9  0x00007ffff7980982 in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#10 0x00007ffff79f3142 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#11 0x00007ffff7939069 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#12 0x00007ffff7980982 in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#13 0x00007ffff79f2225 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#14 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#15 0x00007ffff79f2225 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#16 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#17 0x00007ffff79f2225 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#18 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#19 0x00007ffff79f23cd in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#20 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#21 0x00007ffff79f23cd in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#22 0x00007ffff793a08b in _PyFunction_FastCallDict () from /usr/lib/libpython3.7m.so.1.0
#23 0x00007ffff7949888 in ?? () from /usr/lib/libpython3.7m.so.1.0
#24 0x00007ffff79b71b9 in _PyObject_CallMethodIdObjArgs () from /usr/lib/libpython3.7m.so.1.0
#25 0x00007ffff792e285 in PyImport_ImportModuleLevelObject () from /usr/lib/libpython3.7m.so.1.0
#26 0x00007ffff79f4434 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#27 0x00007ffff7939069 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#28 0x00007ffff7939f34 in PyEval_EvalCodeEx () from /usr/lib/libpython3.7m.so.1.0
#29 0x00007ffff7939f5c in PyEval_EvalCode () from /usr/lib/libpython3.7m.so.1.0
#30 0x00007ffff7a05a64 in ?? () from /usr/lib/libpython3.7m.so.1.0
#31 0x00007ffff7959709 in _PyMethodDef_RawFastCallDict () from /usr/lib/libpython3.7m.so.1.0
#32 0x00007ffff79597d1 in _PyCFunction_FastCallDict () from /usr/lib/libpython3.7m.so.1.0
#33 0x00007ffff79f7e16 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#34 0x00007ffff7939069 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#35 0x00007ffff7980982 in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#36 0x00007ffff79f6933 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#37 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#38 0x00007ffff79f2225 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#39 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#40 0x00007ffff79f23cd in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#41 0x00007ffff79807db in _PyFunction_FastCallKeywords () from /usr/lib/libpython3.7m.so.1.0
#42 0x00007ffff79f23cd in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#43 0x00007ffff793a08b in _PyFunction_FastCallDict () from /usr/lib/libpython3.7m.so.1.0
#44 0x00007ffff7949888 in ?? () from /usr/lib/libpython3.7m.so.1.0
#45 0x00007ffff79b71b9 in _PyObject_CallMethodIdObjArgs () from /usr/lib/libpython3.7m.so.1.0
#46 0x00007ffff792e285 in PyImport_ImportModuleLevelObject () from /usr/lib/libpython3.7m.so.1.0
#47 0x00007ffff79f4434 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.7m.so.1.0
#48 0x00007ffff7939069 in _PyEval_EvalCodeWithName () from /usr/lib/libpython3.7m.so.1.0
#49 0x00007ffff7939f34 in PyEval_EvalCodeEx () from /usr/lib/libpython3.7m.so.1.0
#50 0x00007ffff7939f5c in PyEval_EvalCode () from /usr/lib/libpython3.7m.so.1.0
#51 0x00007ffff7a68770 in ?? () from /usr/lib/libpython3.7m.so.1.0
#52 0x00007ffff7a6a54a in PyRun_FileExFlags () from /usr/lib/libpython3.7m.so.1.0
#53 0x00007ffff7a6bac5 in PyRun_SimpleFileExFlags () from /usr/lib/libpython3.7m.so.1.0
#54 0x00007ffff7a6da8f in ?? () from /usr/lib/libpython3.7m.so.1.0
#55 0x00007ffff7a6e420 in _Py_UnixMain () from /usr/lib/libpython3.7m.so.1.0
#56 0x00007ffff7dc9003 in __libc_start_main () from /usr/lib/libc.so.6
#57 0x000055555555477a in _start ()
```

Thanks for your help on tracking this! :)

Yohan

----------
components: asyncio
messages: 323263
nosy: asvetlov, ybon, yselivanov
priority: normal
severity: normal
status: open
title: SIGSEGV (Address boundary error)
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 03:02:16 2018
From: report at bugs.python.org (Neil Booth)
Date: Wed, 08 Aug 2018 07:02:16 +0000
Subject: [issue30105] Duplicated connection_made() call for some SSL
 connections
In-Reply-To: <1492641406.9.0.0965010091679.issue30105@psf.upfronthosting.co.za>
Message-ID: <1533711736.77.0.56676864532.issue30105@psf.upfronthosting.co.za>


Neil Booth <kyuupichan at gmail.com> added the comment:

Can someone close this please; I submitted this and no longer see it with recent Python versions; I suspect it has been fixed by one of the many SSL fixes in the last 12 months

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30105>
_______________________________________

From report at bugs.python.org  Wed Aug  8 03:24:40 2018
From: report at bugs.python.org (chris)
Date: Wed, 08 Aug 2018 07:24:40 +0000
Subject: [issue34309] Trouble when reloading extension modules.
In-Reply-To: <1533144973.44.0.56676864532.issue34309@psf.upfronthosting.co.za>
Message-ID: <1533713080.84.0.56676864532.issue34309@psf.upfronthosting.co.za>


chris <christoph.wiedemann at hs-weingarten.de> added the comment:

For short-term / mid-term we have now decided to start python as seperate process and interact with some kind of IPC. That leads to a limited interaction model between python and the embedded app but it has the advantage that unloading is possible (by simply restarting python).

Hopefully, at some day python will have better support for unloading / reloading extension modules, but as some pointed out this will take time also until extension modules adopt new API discussed in the PEPs.

Thanks for discussion and information!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34309>
_______________________________________

From report at bugs.python.org  Wed Aug  8 03:29:54 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Aug 2018 07:29:54 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533713394.84.0.56676864532.issue34296@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This might be a useful feature but I think it would be better to develop this outside the stdlib, especially when the mechanism needs application specific code (such as preloading modules used by a specific script).

If/when such a tool has enough traction on PyPI we can always reconsider including it in the stdlib.

BTW. Python runs on a number of platforms where a forking server (option 2 in msg322800) is less useful. In particular Windows which doesn't have "fork" behaviour.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Wed Aug  8 03:30:27 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 08 Aug 2018 07:30:27 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1533713427.64.0.56676864532.issue34355@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Can reproduce with python3.7 from Debian packages, but can't reproduce with a python3.7 built with --with-pydebug.

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 03:52:04 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Wed, 08 Aug 2018 07:52:04 +0000
Subject: [issue24255] Replace debuglevel-related logic with logging
In-Reply-To: <1432189554.94.0.727112934658.issue24255@psf.upfronthosting.co.za>
Message-ID: <1533714724.68.0.56676864532.issue24255@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Yeah, that is understandable. I've reverted major chunk of it. Just in the http client file, I've added blank lines where ever necessary (which I think won't change the blame information for any of the code :))

Would that be okay?

Also, I did a change in the test to redirect the `output` from `test.support` to `stdout` in order to test the changes, but seems like the CI failed because the environment of test was changed. Is there a better method to accomplish it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24255>
_______________________________________

From report at bugs.python.org  Wed Aug  8 04:02:58 2018
From: report at bugs.python.org (Xavier Hardy)
Date: Wed, 08 Aug 2018 08:02:58 +0000
Subject: [issue34356] Add support for args and kwargs in logging.conf
Message-ID: <1533715378.01.0.56676864532.issue34356@psf.upfronthosting.co.za>


New submission from Xavier Hardy <hardyxavier at gmail.com>:

The behavior of formatters and handlers in logging.conf files is inconsistent.

With handlers, it is possible to add custom (keyword and non-keyword) arguments, but it is not possible for formatters (only class, format, datefmt, style).

https://github.com/python/cpython/blob/master/Lib/logging/config.py#L112
https://github.com/python/cpython/blob/master/Lib/logging/config.py#L141

I'll try to submit a pull request as soon as possible.

----------
messages: 323269
nosy: xavier.hardy
priority: normal
severity: normal
status: open
title: Add support for args and kwargs in logging.conf
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34356>
_______________________________________

From report at bugs.python.org  Wed Aug  8 05:50:09 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 08 Aug 2018 09:50:09 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1533721809.16.0.56676864532.issue34355@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

With the last revision of 3.7 (w/o --with-debug), I don't get this issue on Fedora 28 :/

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 05:51:31 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 08 Aug 2018 09:51:31 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1533721891.95.0.56676864532.issue34355@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

and what's the issue with asyncio ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 05:52:58 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 08 Aug 2018 09:52:58 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1533721978.35.0.56676864532.issue34355@psf.upfronthosting.co.za>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
components:  -asyncio
nosy:  -asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 06:46:23 2018
From: report at bugs.python.org (Yohan Boniface)
Date: Wed, 08 Aug 2018 10:46:23 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1533725183.14.0.56676864532.issue34355@psf.upfronthosting.co.za>


Yohan Boniface <yohanboniface at free.fr> added the comment:

Thanks all :)

As noted by Julien, to reproduce the test cases, one also needs to install the dev requirements (or just `pip instal minicli hupper`):

pip install -r requirements-dev.txt

> and what's the issue with asyncio ?

Nothing specific as far as I can tell.
I mentioned it because not all projects use asyncio so I thought it was an significative point to have in mind, just in case.
Also I blindly checked "asyncio" in the "Components" because the project does use asyncio, without foreseeing that this would point asyncio as a guilty and that asyncio maintainers would have been specifically CCed.
Thanks for fixing this.

One other thing to notice just in case: the code base do have unicode chars (in comments, strings and raw strings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 07:04:45 2018
From: report at bugs.python.org (Farzeen)
Date: Wed, 08 Aug 2018 11:04:45 +0000
Subject: [issue34238] When BROWSER is set on Mac
 webbrowser.register_standard_browsers doesn't work
In-Reply-To: <1532623484.23.0.56676864532.issue34238@psf.upfronthosting.co.za>
Message-ID: <1533726285.23.0.56676864532.issue34238@psf.upfronthosting.co.za>


Farzeen <happycoder97 at protonmail.com> added the comment:

Arch Linux is also affected.
Steps to reproduce:
```
$ python
Python 3.7.0 (default, Jul 15 2018, 10:44:58) 
[GCC 8.1.1 20180531] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.get(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/webbrowser.py", line 42, in get
    register_standard_browsers()
  File "/usr/lib/python3.7/webbrowser.py", line 567, in register_standard_browsers
    cmd = _synthesize(cmdline, -1)
  File "/usr/lib/python3.7/webbrowser.py", line 116, in _synthesize
    register(browser, None, controller, update_tryorder)
TypeError: register() takes from 2 to 3 positional arguments but 4 were given
>>> 
```

Workaround:
```
$ env BROWSER='' python
Python 3.7.0 (default, Jul 15 2018, 10:44:58) 
[GCC 8.1.1 20180531] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import webbrowser
>>> webbrowser.get(None)
<webbrowser.Mozilla object at 0x7f6bf8c75400>
>>> 
```

----------
nosy: +happycoder97

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34238>
_______________________________________

From report at bugs.python.org  Wed Aug  8 07:15:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Aug 2018 11:15:24 +0000
Subject: [issue34177] test_site fails in macOS-PR VSTS builds for 3.7 branch
In-Reply-To: <1532158324.8.0.56676864532.issue34177@psf.upfronthosting.co.za>
Message-ID: <1533726924.79.0.56676864532.issue34177@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this can be closed with https://github.com/python/buildmaster-config/commit/9a456462fb891328b5b8a170522d5f56f480fdfb. The buildbots are also green now with the failure reported in https://buildbot.python.org/all/#/builders/147/builds/174 fixed with the commit.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34177>
_______________________________________

From report at bugs.python.org  Wed Aug  8 08:17:07 2018
From: report at bugs.python.org (David)
Date: Wed, 08 Aug 2018 12:17:07 +0000
Subject: [issue34357] situation where urllib3 works, but urllib does not work
Message-ID: <1533730627.83.0.56676864532.issue34357@psf.upfronthosting.co.za>


New submission from David <deivid.rodriguez at riseup.net>:

Hello!

Newbie to python here. I run into an issue with one desktop library, Cinnamon. Specifically this one: https://github.com/linuxmint/Cinnamon/issues/5926#issuecomment-411232144. This library uses the urllib in the standard library to download some json. But for some reason, it does not work for me. If however, I use [https://github.com/urllib3/urllib3](urllib3), it just works. It sounds like something the standard library could do better, so I'm reporting it here in case it's helpful.

A minimal example would be:


```python
from urllib.request import urlopen
 
data = urlopen("https://cinnamon-spices.linuxmint.com/json/applets.json").read()
 
print(data)
```

which just hangs for me. If I pass a specific number of bytes (less than ~65000), it works, but only downloads parts of the file.

Using the equivalent code in urllib3 works just fine:

```python
import urllib3

http = urllib3.PoolManager()
response = http.request('GET', 'https://cinnamon-spices.linuxmint.com/json/applets.json')
print(response.data)

```

This is on

```
Python 3.7.0 (default, Aug  7 2018, 23:24:26) 
[GCC 5.5.0 20171010] on linux
```

Any help troubleshooting this would be appreciated!

----------
messages: 323275
nosy: deivid
priority: normal
severity: normal
status: open
title: situation where urllib3 works, but urllib does not work

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34357>
_______________________________________

From report at bugs.python.org  Wed Aug  8 08:26:39 2018
From: report at bugs.python.org (Sandu)
Date: Wed, 08 Aug 2018 12:26:39 +0000
Subject: [issue34358] round() combined with product outputs ugly result
Message-ID: <1533731199.22.0.56676864532.issue34358@psf.upfronthosting.co.za>


New submission from Sandu <sandu.ursu at gmail.com>:

`from scipy import stats`

`a = stats.norm.cdf(2.1882658846227234)`

`round(a,4)` gives:
`0.9857`

`round(a,4)*100` one would expect to output 98.57.
It returns:
`98.57000000000001`

For comparison, if I multiply with 10 or 1000 the output is as expected.

----------
messages: 323276
nosy: ursus
priority: normal
severity: normal
status: open
title: round() combined with product outputs ugly result
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34358>
_______________________________________

From report at bugs.python.org  Wed Aug  8 08:42:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Aug 2018 12:42:27 +0000
Subject: [issue34358] round() combined with product outputs ugly result
In-Reply-To: <1533731199.22.0.56676864532.issue34358@psf.upfronthosting.co.za>
Message-ID: <1533732147.82.0.56676864532.issue34358@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34358>
_______________________________________

From report at bugs.python.org  Wed Aug  8 09:13:15 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 08 Aug 2018 13:13:15 +0000
Subject: [issue34358] round() combined with product outputs ugly result
In-Reply-To: <1533731199.22.0.56676864532.issue34358@psf.upfronthosting.co.za>
Message-ID: <1533733995.29.0.56676864532.issue34358@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is expected behaviour, the FAQ entry on floating point gives a good explanation about what's going on here: https://docs.python.org/3.7/tutorial/floatingpoint.html

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34358>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:16:10 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 08 Aug 2018 14:16:10 +0000
Subject: [issue34358] round() combined with product outputs ugly result
In-Reply-To: <1533731199.22.0.56676864532.issue34358@psf.upfronthosting.co.za>
Message-ID: <1533737770.17.0.56676864532.issue34358@psf.upfronthosting.co.za>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34358>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:30:16 2018
From: report at bugs.python.org (Sascha Fuhrmann)
Date: Wed, 08 Aug 2018 14:30:16 +0000
Subject: [issue34359] Wrong virtual environment found
Message-ID: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>


New submission from Sascha Fuhrmann <saschaf300578 at googlemail.com>:

For my python development I have several directories on my Windows system:

common:
F:\python\scripts -> one-file-scripts based on python 2
F:\python\scripts3 -> one-file-scripts base on python 3

projects:
F:\python\projects\timetracking
...

Each directory has its own virtual environment (managed with pipenv):
F:\python\scripts\.venv
F:\python\scripts3\.venv
F:\python\projects\timetracking\.venv

Because I want to be able to call the scripts from everywhere, I added the directories to the path-environment variable.

[...]F:\Python\scripts3;F:\Python\projects\timetracking[...]

Let's have a look at the timetracking project. The main script (timetracking.py) has the following shebang-line:
#! /usr/bin/env .venv/scripts/python.exe

My current directory is the root of C

When I call 'timetracking.py' I get an error that some modules have not been installed.

With activating the debug mode (set PYLAUNCH_DEBUG=1) I get some more information:

***
C:\>timetracking.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\itsme\AppData\Local\py.ini' non-existent
File 'C:\Windows\py.ini' non-existent
Called with command line: "F:\Python\projects\timetracking\timetracking.py"
maybe_handle_shebang: read 256 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: F:\Python\scripts3\.venv\scripts\python.exe
run_child: about to run 'F:\Python\scripts3\.venv\scripts\python.exe "F:\Python\projects\timetracking\timetracking.py" '
Traceback (most recent call last):
  File "F:\Python\projects\timetracking\timetracking.py", line 18, in <module>
    import menu_definitions
  File "F:\Python\projects\timetracking\menu_definitions.py", line 15, in <module>
    import menu_edit_item_functions
  File "F:\Python\projects\timetracking\menu_edit_item_functions.py", line 15, in <module>
    import tools
  File "F:\Python\projects\timetracking\tools.py", line 19, in <module>
    from texttable import Texttable
ModuleNotFoundError: No module named 'texttable'
child process exit code: 1
***

As you can see, the pylauncher found a shebang - but not that one I expected ('scripts3\.venv' instead of 'timetracking\.venv') *confused*
It seems that the pylauncher uses the first .venv it found within the path variable...

Any ideas?

----------
components: Windows
messages: 323278
nosy: Sascha Fuhrmann, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Wrong virtual environment found
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:40:36 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 08 Aug 2018 14:40:36 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533739236.82.0.56676864532.issue34359@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

>From https://docs.python.org/3.7/using/windows.html#shebang-lines the supported shebang lines are

* /usr/bin/env python
* /usr/bin/python
* /usr/local/bin/python
* python

There's a provision in there:

"""
The /usr/bin/env form of shebang line has one further special property. Before looking for installed Python interpreters, this form will search the executable PATH for a Python executable. This corresponds to the behaviour of the Unix env program, which performs a PATH search.
"""

The launcher does *not* implement the full functionality of the Unix "env" program, and in particular doesn't support (relative or absolute) paths in the Python interpreter part.

While "search PATH for the relative path given in the env shebang line" would be a potential feature request, it's not current behaviour, and in my view, it's too rare of a scenario to be worth the complexity it would add to the launcher.

As a workaround, you can use an absolute path in your shebang line:

#!F:\python\scripts3\.venv\Scripts\python.exe

(Obviously that requires a little more manual management of the shebang lines in your scripts).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:50:24 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 08 Aug 2018 14:50:24 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533739824.86.0.56676864532.issue34359@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

And the Shebang is specific to the Unix-like systems, the loader from the operating system, will read the first line and will try to execute the defined interpreter. 

https://en.wikipedia.org/wiki/Shebang_(Unix)

On Windows, I am not sure, but like Paul told you, PyLauncher does not implement the full functionality of the Unix "env" program.

Maybe we could close this issue.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:54:49 2018
From: report at bugs.python.org (sfx2k)
Date: Wed, 08 Aug 2018 14:54:49 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740089.08.0.56676864532.issue34359@psf.upfronthosting.co.za>


sfx2k <saschaf300578 at googlemail.com> added the comment:

Thanks for your feedback, Paul and Stephane.

The thing with the relative path works if I change the order in the path from [...]F:\Python\scripts3;F:\Python\projects\timetracking[...] to [...]F:\Python\projects\timetracking;F:\Python\scripts3[...] 

;)

An absolut path is not practicable because it can be different on other systems :)

How do others do it? I don't think that I am the only one that uses such a workflow, or am I wrong?

----------
nosy:  -matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:55:11 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 08 Aug 2018 14:55:11 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740111.79.0.56676864532.issue34359@psf.upfronthosting.co.za>


Change by Paul Moore <p.f.moore at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:55:48 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 08 Aug 2018 14:55:48 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740148.47.0.56676864532.issue34359@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Others use absolute paths, as I mentioned in my reply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:57:38 2018
From: report at bugs.python.org (Paul Moore)
Date: Wed, 08 Aug 2018 14:57:38 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740258.53.0.56676864532.issue34359@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Oh, and I suspect that the reason that "The thing with the relative path works if I change the order in the path" is simply because the bit of code that searches PATH just ignores what's after #!/usr/bin/env and looks for python.exe. (More or less - I haven't checked the code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 10:59:15 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 08 Aug 2018 14:59:15 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740355.35.0.56676864532.issue34359@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Now, you could use a Windows shortcut where you specify the version of Python when you execute your script.

F:\python\scripts3\.venv\bin\python myscript.py

For example.

----------
nosy: +matrixise
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:02:23 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 08 Aug 2018 15:02:23 +0000
Subject: [issue23835] configparser does not convert defaults to strings
In-Reply-To: <1427862188.44.0.00358189102447.issue23835@psf.upfronthosting.co.za>
Message-ID: <1533740543.15.0.56676864532.issue23835@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

That's intentional. In ConfigParser objects this exception would be raised for any other section's assignment already. You want RawConfigParser if you want to put (invalid) types as option values. See:

>>> cp = ConfigParser()
>>> cp['asd'] = {'a': None}
Traceback (most recent call last):
...
TypeError: option values must be strings
>>> rcp = RawConfigParser()
>>> rcp['asd'] = {'a': None}
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23835>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:06:06 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 08 Aug 2018 15:06:06 +0000
Subject: [issue34242] configparser: SectionProxy.get is silent on missing
 options
In-Reply-To: <1532636603.09.0.56676864532.issue34242@psf.upfronthosting.co.za>
Message-ID: <1533740766.08.0.56676864532.issue34242@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

> Maybe a ConfigParser object could have an option to raise errors, because they are useful for discovering errors in config files.

For this option, use mapping access instead of `.get()`:

>>> cp['section']['key']
Traceback (most recent call last):
...
KeyError: 'key'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34242>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:07:19 2018
From: report at bugs.python.org (sfx2k)
Date: Wed, 08 Aug 2018 15:07:19 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740839.35.0.56676864532.issue34359@psf.upfronthosting.co.za>


sfx2k <saschaf300578 at googlemail.com> added the comment:

Okay, thanks anyway :)

btw:

"Oh, and I suspect that the reason that "The thing with the relative path works if I change the order in the path" is simply because the bit of code that searches PATH just ignores what's after #!/usr/bin/env and looks for python.exe. (More or less - I haven't checked the code)."

Nope - then it would find the python executable in c:\python3 first ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:07:41 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 08 Aug 2018 15:07:41 +0000
Subject: [issue34242] configparser: SectionProxy.get is silent on missing
 options
In-Reply-To: <1532636603.09.0.56676864532.issue34242@psf.upfronthosting.co.za>
Message-ID: <1533740861.88.0.56676864532.issue34242@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

> I still find the remark about the parser-level `get` being maintained for backwards compatibility strange (and it is eight years old), could this be improved?

How? Parser-level `.get()` predates mapping protocol access and has an incompatible API. Thus, we need to leave it as is, otherwise we'd break existing code.

Use mapping protocol everywhere in new code and you won't see those issues anymore.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34242>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:09:27 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 08 Aug 2018 15:09:27 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533740967.47.0.56676864532.issue34359@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

it's normal because this path is in the PATH env variable.

so in this case, I think we can close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:10:39 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 08 Aug 2018 15:10:39 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1533741039.51.0.56676864532.issue2651@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I agree with Inadasan. I was eager to fix this until I actually got to it at the '16 core sprint. I think there's too little value in fixing this versus possible backwards compatibility breakage.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:11:13 2018
From: report at bugs.python.org (sfx2k)
Date: Wed, 08 Aug 2018 15:11:13 +0000
Subject: [issue34359] Wrong virtual environment found
In-Reply-To: <1533738616.85.0.56676864532.issue34359@psf.upfronthosting.co.za>
Message-ID: <1533741073.31.0.56676864532.issue34359@psf.upfronthosting.co.za>


Change by sfx2k <saschaf300578 at googlemail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34359>
_______________________________________

From report at bugs.python.org  Wed Aug  8 11:14:16 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 08 Aug 2018 15:14:16 +0000
Subject: [issue33802] Regression in logging configuration
In-Reply-To: <1528412435.4.0.592728768989.issue33802@psf.upfronthosting.co.za>
Message-ID: <1533741256.63.0.56676864532.issue33802@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

None is an invalid value in the configparser. It only accepts strings. See:

>>> cp = ConfigParser()
>>> cp['asd'] = {'a': None}
Traceback (most recent call last):
...
TypeError: option values must be strings



The DEFAULT section was an omission which is now fixed. You can use a RawConfigParser if you want to put invalid types as option values:

>>> rcp = RawConfigParser()
>>> rcp['asd'] = {'a': None}
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33802>
_______________________________________

From report at bugs.python.org  Wed Aug  8 12:02:35 2018
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 08 Aug 2018 16:02:35 +0000
Subject: [issue34360] urllib.parse doesn't fail with multiple unmatching
 square brackets
Message-ID: <1533744155.42.0.56676864532.issue34360@psf.upfronthosting.co.za>


New submission from Florian Bruhin <python.org at the-compiler.org>:

Since bpo-29651, the urllib.parse docs say:

> Unmatched square brackets in the netloc attribute will raise a ValueError.

However, when there are at least one [ and ], but they don't match, there's somewhat inconsistent behavior:

>>> urllib.parse.urlparse('http://[::1]]').hostname
'::1'
>>> urllib.parse.urlparse('http://[[::1]').hostname
'[::1'

----------
components: Library (Lib)
messages: 323292
nosy: Howie Benefiel, The Compiler, orsenthil
priority: normal
severity: normal
status: open
title: urllib.parse doesn't fail with multiple unmatching square brackets
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34360>
_______________________________________

From report at bugs.python.org  Wed Aug  8 13:01:47 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Aug 2018 17:01:47 +0000
Subject: [issue34350] Non obvious logging handler behaviour
In-Reply-To: <1533588087.55.0.56676864532.issue34350@psf.upfronthosting.co.za>
Message-ID: <1533747707.4.0.56676864532.issue34350@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34350>
_______________________________________

From report at bugs.python.org  Wed Aug  8 14:15:06 2018
From: report at bugs.python.org (Vadim Pushtaev)
Date: Wed, 08 Aug 2018 18:15:06 +0000
Subject: [issue34284] Nonsensical exception message when calling `__new__` on
 non-instaniable objects
In-Reply-To: <1532981101.24.0.56676864532.issue34284@psf.upfronthosting.co.za>
Message-ID: <1533752106.46.0.56676864532.issue34284@psf.upfronthosting.co.za>


Vadim Pushtaev <pushtaev.vm at gmail.com> added the comment:

Usually, tp_new==NULL means that __new__ is inherited, but not always. Here is the comment from typeobject.c:

/* The condition below could use some explanation.
   It appears that tp_new is not inherited for static types
   whose base class is 'object'; this seems to be a precaution
   so that old extension types don't suddenly become
   callable (object.__new__ wouldn't insure the invariants
   that the extension type's own factory function ensures).
   Heap types, of course, are under our control, so they do
   inherit tp_new; static extension types that specify some
   other built-in type as the default also
   inherit object.__new__. */


So my current solution is to explicitly set __new__ to the common helper function that raises TypeError in that case.

---

Thanks a lot for your comments and ideas. In truth, I feel a little overwhelmed and definitely need further guidance for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34284>
_______________________________________

From report at bugs.python.org  Wed Aug  8 14:16:09 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Wed, 08 Aug 2018 18:16:09 +0000
Subject: [issue34361] An error should be returned when there are spaces in
 between function name and parameters
Message-ID: <1533752169.63.0.56676864532.issue34361@psf.upfronthosting.co.za>


New submission from Sanyam Khurana <sanyam.khurana01 at gmail.com>:

I noticed this while reviewing the code.

The print function works like:

```
print       (5)
```

This works with user-defined function too.

Ideally, this is a function call and we should return an error stating that there shouldn't be any spaces between the function name and the parameters listed.

This essentially is not good for people who're new to programming and learning to code with Python as their first language.

----------
components: Library (Lib)
messages: 323294
nosy: CuriousLearner
priority: normal
severity: normal
stage: needs patch
status: open
title: An error should be returned when there are spaces in between function name and parameters
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34361>
_______________________________________

From report at bugs.python.org  Wed Aug  8 14:17:49 2018
From: report at bugs.python.org (Cyker Way)
Date: Wed, 08 Aug 2018 18:17:49 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1533752269.77.0.56676864532.issue34296@psf.upfronthosting.co.za>


Cyker Way <cykerway at gmail.com> added the comment:

I'm fine with stdlib, 3rd party tools, or whatever. My focus is to understand is whether this idea can be correctly implemented on the python VM or not. I've been searching for similar implementations on standard JVM, but the results mostly come from research projects rather than industrial solutions. That being said, Android does have preloading implemented in its Dalvik/ART VM (which is more or less a variant of JVM). Cited from <https://source.android.com/devices/tech/dalvik/configure>:

>   The preloaded classes list is a list of classes the zygote will initialize on startup. This saves each app from having to run these class initializers separately, allowing them to start up faster and share pages in memory.

I was wondering what makes it difficult for standard JVM (eg. HotSpot) to have such feature and why Dalvik/ART is able to do it, and what would be the case for the python VM?

----

A few more words about my original vision: I was hoping to speed up python script execution using template VMs in which a list of selected modules are preloaded. For example, if you have one script for regex matching, and another for dir listing, then you can create 2 template VMs with `re` and `os` modules preloaded, respectively. The template VMs run as system service so that you can always fork from them to create something like a runtime version of *virtualenv* where only relevant modules are loaded. The preloaded modules can be standard modules or user modules. I don't really see what makes a difference here if the module is standard or not.

----

>   In particular Windows which doesn't have "fork" behaviour.

Forking helps the parent process keep a clean state since it basically does nothing after the fork. If the system doesn't natively support fork then the parent process can do the job by itself instead of forking a child process to do so. But additional work might be needed to remove the artifacts resulting from the execution of user script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Wed Aug  8 14:22:17 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Aug 2018 18:22:17 +0000
Subject: [issue34361] An error should be returned when there are spaces in
 between function name and parameters
In-Reply-To: <1533752169.63.0.56676864532.issue34361@psf.upfronthosting.co.za>
Message-ID: <1533752537.88.0.56676864532.issue34361@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, but ignoring that whitespace is part of the python language definition.  At this point in time, whatever the merits of the "beginner" argument, it is not going to change, for backward compatibility reasons if nothing else.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34361>
_______________________________________

From report at bugs.python.org  Wed Aug  8 15:07:33 2018
From: report at bugs.python.org (ppperry)
Date: Wed, 08 Aug 2018 19:07:33 +0000
Subject: [issue34362] User-created types with wrong __new__ can be instantiated
Message-ID: <1533755253.45.0.56676864532.issue34362@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

If you have a class that defines __new__ to the __new__ of another builtin type that it isn't a subclass of:
>>> class X:
...    __new__ = tuple.__new__
Instantiating this class should produce an error because `tuple.__new__` can't handle non-tuples, but instead it succeeds:
>>> X()
<__main__.X object at 0x00000000032C3F98>

(related: issue34284)

----------
components: Interpreter Core
messages: 323297
nosy: Vadim Pushtaev, ncoghlan, ppperry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: User-created types with wrong __new__ can be instantiated
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34362>
_______________________________________

From report at bugs.python.org  Wed Aug  8 15:41:25 2018
From: report at bugs.python.org (Alex DeLorenzo)
Date: Wed, 08 Aug 2018 19:41:25 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
Message-ID: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>


New submission from Alex DeLorenzo <alex.delorenzo at gmail.com>:

Example:

from typing import NamedTuple
from dataclasses import dataclass, asdict

class NamedTupleAttribute(NamedTuple):
    example: bool = True

@dataclass
class Data:
    attr1: bool
    attr2: NamedTupleAttribute

data = Data(True, NamedTupleAttribute(example=True))
namedtuple_attr = asdict(data)['attr2']
print(type(namedtuple_attr.example))
>>> generator

One would expect that the printed type would be of type bool.

----------
components: Interpreter Core
messages: 323298
nosy: alexdelorenzo
priority: normal
severity: normal
status: open
title: dataclasses.asdict() mishandles dataclass instance attributes that are instances of subclassed typing.NamedTuple
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 15:43:07 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Aug 2018 19:43:07 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533757387.06.0.56676864532.issue34363@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 15:47:19 2018
From: report at bugs.python.org (ppperry)
Date: Wed, 08 Aug 2018 19:47:19 +0000
Subject: [issue34362] User-created types with wrong __new__ can be instantiated
In-Reply-To: <1533755253.45.0.56676864532.issue34362@psf.upfronthosting.co.za>
Message-ID: <1533757639.43.0.56676864532.issue34362@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

Whoops, realized this is a duplicate of issue5322.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34362>
_______________________________________

From report at bugs.python.org  Wed Aug  8 16:01:59 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 08 Aug 2018 20:01:59 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533758519.46.0.56676864532.issue34363@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 16:11:56 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 08 Aug 2018 20:11:56 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533759116.1.0.56676864532.issue34363@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

OK, so the crux of the bug is this difference:

>>> a = (1, 2)
>>> tuple(x for x in a)
(1, 2)
>>> NamedTupleAttribute(x for x in a)
NamedTupleAttribute(example=<generator object <genexpr> at 0x10e2e52a0>)

A potential solution would be to either use `type(obj) in (list, tuple)` instead of `isinstance(obj, (list, tuple))` (and thus cause using copy.deepcopy for everything else), but this might break some use cases (IMO quite unlikely).

Any other thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 16:42:15 2018
From: report at bugs.python.org (bob gailer)
Date: Wed, 08 Aug 2018 20:42:15 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
Message-ID: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>


New submission from bob gailer <bgailer at gmail.com>:

Inconsistent tracebacks. Note that the traceback for bug.py does not 
reference the
module file and line number.

# bug.py
def f():
 ? f'''
 ? {d e}'''
a=b

import bug

Traceback (most recent call last):
 ? File "<fstring>", line 1
 ??? (d e)
 ?????? ^
SyntaxError: invalid syntax

----------------------------------------

# bug2.py
def f():
 ? f'''
 ? {de}'''
a=b

import bug2
bug2.f()

Traceback (most recent call last):
 ? File "C:\python\bug2.py", line 5, in <module>
 ??? a=b
NameError: name 'b' is not defined

----------
messages: 323301
nosy: bgailer
priority: normal
severity: normal
status: open
title: problem with traceback for syntax error in f-string

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Wed Aug  8 17:06:54 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 08 Aug 2018 21:06:54 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533762414.89.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset cca4eec3c0a67cbfeaf09182ea6c097a94891ff6 by Yury Selivanov (Alex Gr?nholm) in branch 'master':
bpo-34270: Make it possible to name asyncio tasks (GH-8547)
https://github.com/python/cpython/commit/cca4eec3c0a67cbfeaf09182ea6c097a94891ff6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Wed Aug  8 17:08:30 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 08 Aug 2018 21:08:30 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533762510.24.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thank you for the contribution!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Wed Aug  8 17:13:24 2018
From: report at bugs.python.org (ppperry)
Date: Wed, 08 Aug 2018 21:13:24 +0000
Subject: [issue5322] object.__new__ argument calling autodetection faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1533762804.12.0.56676864532.issue5322@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: Python 2.6 object.__new__ argument calling autodetection faulty -> object.__new__ argument calling autodetection faulty

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Wed Aug  8 17:52:35 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 08 Aug 2018 21:52:35 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1533765155.58.0.56676864532.issue34355@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

After noticing that without pydebug I can reproduce in v3.7.0 but not in master I ran a git bisect, the following commit looks like it fixes the issue:

```
commit 16dfca4d829e45f36e71bf43f83226659ce49315
Author: INADA Naoki <methane at users.noreply.github.com>
Date:   Sat Jul 14 12:06:43 2018 +0900

    bpo-34087: Fix buffer overflow in int(s) and similar functions (GH-8274)
    
    `_PyUnicode_TransformDecimalAndSpaceToASCII()` missed trailing NUL char.
    It caused buffer overflow in `_Py_string_to_number_with_underscores()`.
    
    This bug is introduced in 9b6c60cb.
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Wed Aug  8 17:52:38 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Aug 2018 21:52:38 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533765158.74.0.56676864532.issue34363@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith
components: +Library (Lib) -Interpreter Core
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 17:53:06 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Aug 2018 21:53:06 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533765186.23.0.56676864532.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Oops, didn't see that you commented on this, Ivan.

I'll do some analysis tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 18:14:19 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 08 Aug 2018 22:14:19 +0000
Subject: [issue34350] Non obvious logging handler behaviour
In-Reply-To: <1533588087.55.0.56676864532.issue34350@psf.upfronthosting.co.za>
Message-ID: <1533766459.81.0.56676864532.issue34350@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The logging module-level convenience functions are specifically there for the use of casual, short scripts where users don't want to be concerned with the details of loggers and handlers.

Even if you accidentally configure logging in library code because you typed logging.XXX() instead of logger.XXX(), that's just like any other bug introduced because of a typo. It would presumably get caught in testing.

Obviously, this behaviour can't be changed because of the need to maintain backward compatibility (and IMO there is no reason to change this behaviour, as it is like this by design).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34350>
_______________________________________

From report at bugs.python.org  Wed Aug  8 18:16:03 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 08 Aug 2018 22:16:03 +0000
Subject: [issue29036] logging module: Add `full_module_name` to LogRecord
 details
In-Reply-To: <1482336912.68.0.293105867979.issue29036@psf.upfronthosting.co.za>
Message-ID: <1533766563.52.0.56676864532.issue29036@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Closing this as rejected, as when using the recommended approach for naming loggers, you get the full package name which can be output in logs.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29036>
_______________________________________

From report at bugs.python.org  Wed Aug  8 18:17:11 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 08 Aug 2018 22:17:11 +0000
Subject: [issue34244] Add support of check logger
In-Reply-To: <1532668540.12.0.56676864532.issue34244@psf.upfronthosting.co.za>
Message-ID: <1533766631.25.0.56676864532.issue34244@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Closing, as no response received.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34244>
_______________________________________

From report at bugs.python.org  Wed Aug  8 18:52:58 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 08 Aug 2018 22:52:58 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1533768778.8.0.56676864532.issue11191@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +8196

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Wed Aug  8 21:25:28 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 09 Aug 2018 01:25:28 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
In-Reply-To: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>
Message-ID: <1533777928.13.0.56676864532.issue34364@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

So the bug is that the line number and module are incorrect for the f-string, right? Nothing else?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Wed Aug  8 22:19:18 2018
From: report at bugs.python.org (Paul Monson)
Date: Thu, 09 Aug 2018 02:19:18 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1533781158.22.0.56676864532.issue33125@psf.upfronthosting.co.za>


Paul Monson <paulmons at gmail.com> added the comment:

I'm interested in getting python working on Windows running on Raspberry Pi (Thumb-2 instruction set).  I can also contribute to ARM64 Windows.  I've made some progress getting ARM32 working on a fork.  The next roadblock for my investigation is libffi support for ARM32 on Windows.  Can I help with that?

----------
nosy: +Paul Monson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Wed Aug  8 22:39:06 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Aug 2018 02:39:06 +0000
Subject: [issue34364] problem with traceback for syntax error in f-string
In-Reply-To: <31c748a7-5e57-009a-08e5-c18171489bc0@gmail.com>
Message-ID: <1533782346.49.0.56676864532.issue34364@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think this is a duplicate, but I can't find the exact issue. I don't think it's exactly the same as #29051.

----------
assignee:  -> eric.smith
components: +Interpreter Core
nosy: +eric.smith
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34364>
_______________________________________

From report at bugs.python.org  Wed Aug  8 22:54:31 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 09 Aug 2018 02:54:31 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533783271.31.0.56676864532.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks for the pointer, Ivan.

I haven't really thought it through yet, but this fixes the problem at hand:

diff --git a/dataclasses.py b/dataclasses.py
index ba34f6b..54916ee 100644
--- a/dataclasses.py
+++ b/dataclasses.py
@@ -1019,7 +1019,7 @@ def _asdict_inner(obj, dict_factory):
             result.append((f.name, value))
         return dict_factory(result)
     elif isinstance(obj, (list, tuple)):
-        return type(obj)(_asdict_inner(v, dict_factory) for v in obj)
+        return type(obj)(*[_asdict_inner(v, dict_factory) for v in obj])
     elif isinstance(obj, dict):
         return type(obj)((_asdict_inner(k, dict_factory), _asdict_inner(v, dict_factory))
                           for k, v in obj.items())

There are plenty more tests needed for this, plus I need to think it through some more. astuple() has the same issue. I'll also have to think about the dict subclass case, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Wed Aug  8 22:59:44 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 09 Aug 2018 02:59:44 +0000
Subject: [issue33989] ms.key_compare is not initialized in all paths of
 list_sort_impl()
In-Reply-To: <1530207786.09.0.56676864532.issue33989@psf.upfronthosting.co.za>
Message-ID: <1533783584.94.0.56676864532.issue33989@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
title: ms.key_compare is not initialized in all pathes of list_sort_impl -> ms.key_compare is not initialized in all paths of list_sort_impl()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33989>
_______________________________________

From report at bugs.python.org  Wed Aug  8 23:00:00 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 09 Aug 2018 03:00:00 +0000
Subject: [issue33989] ms.key_compare is not initialized in all paths of
 list_sort_impl()
In-Reply-To: <1530207786.09.0.56676864532.issue33989@psf.upfronthosting.co.za>
Message-ID: <1533783600.24.0.56676864532.issue33989@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8197
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33989>
_______________________________________

From report at bugs.python.org  Wed Aug  8 23:08:55 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 09 Aug 2018 03:08:55 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533752269.77.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <CAEfz+TwUJPipmUvRcQ46P_ZTGBJAehh0oZCUcp8Q+1uUmeW6cQ@mail.gmail.com>


INADA Naoki <songofacandy at gmail.com> added the comment:

On Thu, Aug 9, 2018 at 3:17 AM Cyker Way <report at bugs.python.org> wrote:
>
> Cyker Way <cykerway at gmail.com> added the comment:
>
> I'm fine with stdlib, 3rd party tools, or whatever. My focus is to understand is whether this idea can be correctly implemented on the python VM or not. I've been searching for similar implementations on standard JVM, but the results mostly come from research projects rather than industrial solutions. That being said, Android does have preloading implemented in its Dalvik/ART VM (which is more or less a variant of JVM). Cited from <https://source.android.com/devices/tech/dalvik/configure>:
>
> >   The preloaded classes list is a list of classes the zygote will initialize on startup. This saves each app from having to run these class initializers separately, allowing them to start up faster and share pages in memory.
>
> I was wondering what makes it difficult for standard JVM (eg. HotSpot) to have such feature and why Dalvik/ART is able to do it, and what would be the case for the python VM?
>

Many WSGI servers provides "pre-fork" for (1) faster worker process creation and
(2) sharing static memory.  So it's definitely possible.

When compared with JVM, Python is dynamic language.
for example,

if not os.environ.get('XXX_NO_SPEEDUP'):
    from xxx._speedup import somefunc  # Load somefunc from extension
else:
    from xxx._util import somefunc  # Load somefunc from pure Python

Environment variables, configuration files, or even input from keyboard or
some sensors may affects importing modules, unlike JVM.

So more strict restriction is required for application in Python's case.
It can't be used for general, blindly and automatically from VM-side.
It should be implemented explicitly from Application side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34296>
_______________________________________

From report at bugs.python.org  Thu Aug  9 01:03:49 2018
From: report at bugs.python.org (Kevin Norris)
Date: Thu, 09 Aug 2018 05:03:49 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
Message-ID: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>


New submission from Kevin Norris <nykevin.norris at gmail.com>:

The 3.x datetime documentation contains the following footnote:

> In other words, date1 < date2 if and only if date1.toordinal() < date2.toordinal(). In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn?t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively.

But in 3.x, comparison no longer falls back to comparing object addresses.  Also, some of the comments on issue 8005 seem to suggest that this footnote is not actually true in 3.x (aside from the first sentence, of course).  But regardless, the footnote should not refer to a long dead interpreter behavior as if it were still around.

----------
assignee: docs at python
components: Documentation
messages: 323314
nosy: Kevin.Norris, docs at python
priority: normal
severity: normal
status: open
title: datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Thu Aug  9 01:08:33 2018
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Aug 2018 05:08:33 +0000
Subject: [issue29036] logging module: Add `full_module_name` to LogRecord
 details
In-Reply-To: <1482336912.68.0.293105867979.issue29036@psf.upfronthosting.co.za>
Message-ID: <1533791313.21.0.56676864532.issue29036@psf.upfronthosting.co.za>


Ram Rachum <ram at rachum.com> added the comment:

Hi Vinay,

Since it's been a couple of years since I opened this ticket, I can't tell you the case in which I wanted to know the full module name of a logger. But it's probably been a logger from a third-party library. Since I can't force a third-party library that doesn't use the `__name__` convention to use it, having an attribute with the full module name would be my only solution to getting that information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29036>
_______________________________________

From report at bugs.python.org  Thu Aug  9 02:21:13 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 09 Aug 2018 06:21:13 +0000
Subject: [issue29036] logging module: Add `full_module_name` to LogRecord
 details
In-Reply-To: <1482336912.68.0.293105867979.issue29036@psf.upfronthosting.co.za>
Message-ID: <1533795673.29.0.56676864532.issue29036@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The full module name isn't readily available. The value that sets the LogRecord's pathname attribute [which is obtained from the Python code object for the caller] is used to derive the filename attribute (by taking the basename of the pathname) and the filename is used to determine the module attribute (by just dropping the extension from the filename). So if you really need the modulename, you would have to derive it from the pathname.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29036>
_______________________________________

From report at bugs.python.org  Thu Aug  9 02:48:30 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Thu, 09 Aug 2018 06:48:30 +0000
Subject: [issue34366] _uuid module fails to compile on FreeBSD when libuuid is
 installed
Message-ID: <1533797310.78.0.56676864532.issue34366@psf.upfronthosting.co.za>


New submission from Micha? G?rny <mgorny at gentoo.org>:

The _uuid extension fails to build on my Gentoo/FreeBSD system:

building '_uuid' extension
x86_64-gentoo-freebsd11.1-gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -pipe -march=native -fwrapv -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include -I. -I/var/tmp/portage/dev-lang/python-3.7.0/work/Python-3.7.0/Include -I/var/tmp/portage/dev-lang/python-3.7.0/work/Python-3.7.0 -c /var/tmp/portage/dev-lang/python-3.7.0/work/Python-3.7.0/Modules/_uuidmodule.c -o build/temp.freebsd-11.1-RELEASE-amd64-3.7/var/tmp/portage/dev-lang/python-3.7.0/work/Python-3.7.0/Modules/_uuidmodule.o
In file included from /usr/include/uuid.h:34:0,
                 from /var/tmp/portage/dev-lang/python-3.7.0/work/Python-3.7.0/Modules/_uuidmodule.c:8:
/usr/include/sys/uuid.h:77:21: error: conflicting types for 'uuid_t'
 typedef struct uuid uuid_t;
                     ^~~~~~
In file included from /var/tmp/portage/dev-lang/python-3.7.0/work/Python-3.7.0/Modules/_uuidmodule.c:5:0:
/usr/include/uuid/uuid.h:44:23: note: previous declaration of 'uuid_t' was here
 typedef unsigned char uuid_t[16];
                       ^~~~~~
[...]


Apparently the cause is that it includes headers belonging to the system uuid library and libuuid (from util-linux) simultaneously.  The whole module seems to be written with the assumption that the two different implementations will not be present simultaneously.  However, some software supports libuuid only, so we're forced to have both.

Attaching the complete build log.  I will submit a PR soonish.

----------
components: Extension Modules
files: dev-lang:python-3.7.0:20180809-062928.log
messages: 323317
nosy: mgorny
priority: normal
severity: normal
status: open
title: _uuid module fails to compile on FreeBSD when libuuid is installed
type: compile error
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47735/dev-lang:python-3.7.0:20180809-062928.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34366>
_______________________________________

From report at bugs.python.org  Thu Aug  9 03:26:17 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Thu, 09 Aug 2018 07:26:17 +0000
Subject: [issue34366] _uuid module fails to compile on FreeBSD when libuuid is
 installed
In-Reply-To: <1533797310.78.0.56676864532.issue34366@psf.upfronthosting.co.za>
Message-ID: <1533799577.53.0.56676864532.issue34366@psf.upfronthosting.co.za>


Change by Micha? G?rny <mgorny at gentoo.org>:


----------
keywords: +patch
pull_requests: +8198
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34366>
_______________________________________

From report at bugs.python.org  Thu Aug  9 03:45:55 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Aug 2018 07:45:55 +0000
Subject: [issue34360] urllib.parse doesn't fail with multiple unmatching
 square brackets
In-Reply-To: <1533744155.42.0.56676864532.issue34360@psf.upfronthosting.co.za>
Message-ID: <1533800755.44.0.56676864532.issue34360@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34360>
_______________________________________

From report at bugs.python.org  Thu Aug  9 05:46:10 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 09 Aug 2018 09:46:10 +0000
Subject: [issue32638] distutils test errors with AIX and xlc
In-Reply-To: <1516737985.98.0.467229070634.issue32638@psf.upfronthosting.co.za>
Message-ID: <1533807970.52.0.56676864532.issue32638@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

this can be closed. Discussion, if any, at https://github.com/python/cpython/pull/8709 or issue11191

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32638>
_______________________________________

From report at bugs.python.org  Thu Aug  9 07:55:07 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 09 Aug 2018 11:55:07 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1533815707.35.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Starting this discussion again. Please take time to read. I have spent hours trying to understand what is failing. Please spend a few minutes reading.

Sadly, there is a lot of text - but I do not know what I could leave out without damaging the process of discovery.

The failing result is:

    self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

The test code is:
  +207      @unittest.skipIf(MS_WINDOWS, 'test specific to Unix')
  +208      def test_cmd_line(self):
  +209          arg = 'h\xe9\u20ac'.encode('utf-8')
  +210          arg_utf8 = arg.decode('utf-8')
  +211          arg_ascii = arg.decode('ascii', 'surrogateescape')
  +212          code = 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))'
  +213
  +214          def check(utf8_opt, expected, **kw):
  +215              out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
  +216              args = out.partition(':')[2].rstrip()
  +217              self.assertEqual(args, ascii(expected), out)
  +218
  +219          check('utf8', [arg_utf8])
  +220          if sys.platform == 'darwin' or support.is_android:
  +221              c_arg = arg_utf8
  +222          else:
  +223              c_arg = arg_ascii
  +224          check('utf8=0', [c_arg], LC_ALL='C')

Question 1: why is windows excluded? Because it does not use UTF-8 as it's default (it's default is CP1252)

Question 2: It seems that what the test is 'checking' is that object.encode('utf-8') gets decoded by ascii() based on the utf8_mode set.

 +215              out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)

rewrites (less indent) as:
 +215  out = self.get_output('-X', utf8_opt, '-c', code, 'h\xe9\u20ac'.encode('utf-8'), **kw)

or
out = self.get_output('-X', utf8_opt, '-c', code, b'h\xc3\xa9\xe2\x82\xac', **kw)

Finally, in  Lib/test/support/script_helper.py we have
  +127      print("\n", cmd_line) # debug info, ignore
  +128      proc = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
  +129                           stdout=subprocess.PIPE, stderr=subprocess.PIPE,
  +130                           env=env, cwd=cwd)

Which gives:

 ['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8', '-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']

Above - utf8=1 - is successful

 ['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8=0', '-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']

Here: utf8=0 fails. The arg to the CLI is equal in both cases.
FAIL

## Goiing back to check() and what does it have:
## Add some debug. The first line is the 'raw' expected,
## the second line is ascii(decoded)
## the final is the value extracted from get_output

  +214          def check(utf8_opt, expected, **kw):
  +215              out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
  +216              args = out.partition(':')[2].rstrip()
  +217              print("")
  +218              print("%s: expected\n%s:ascii(expected)\n%s:out" % (expected, ascii(expected), out))
  +219              self.assertEqual(args, ascii(expected), out)

For: utf8 mode true, it works:
['h?\u20ac']: expected
['h\xe9\u20ac']:ascii(expected)
UTF-8:['h\xe9\u20ac']:out

  +221          check('utf8', [arg_utf8])

But not for utf8=0
  +226          check('utf8=0', [c_arg], LC_ALL='C')
 # note, different values for LC_ALL='C' have been tried
['h\udcc3\udca9\udce2\udc82\udcac']: expected
['h\udcc3\udca9\udce2\udc82\udcac']:ascii(expected)
ISO8859-1:['h\xc3\xa9\xe2\x82\xac']:out

## re: expected and ascii(expected)
When utf8=1 expected and ascii(expected) differ. "arg" looks different from both - but after processing by get_object() expected and out match.

When utf8=0 there is no difference is "arg1" passed to "code".
However, whith check - the values for both expected and ascii(expected) are identical. And, sadly, the value coming back via get_output looks nothing like 'expected'.

In short, when utf8=1 ascii(b'h\xc3\xa9\xe2\x82\xac') becomes ['h\xe9\u20ac' which is what is desired. But when utf8=0 ascii(b'h\xc3\xa9\xe2\x82\xac') is b'h\xc3\xa9\xe2\x82\xac' not 'h\udcc3\udca9\udce2\udc82\udcac'

Finally, when I run the command from the command line (after rewrites)

What passes:
./python '-X' 'faulthandler' '-X' 'utf8=1' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(
sys.argv[1:])))' b'h\xc3\xa9\xe2\x82\xac'
UTF-8:['bh\\xc3\\xa9\\xe2\\x82\\xac']

encoding is UTF-8, but the result of ascii(argv[1]) is the same as argv[1]

./python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(
sys.argv[1:])))' b'h\xc3\xa9\xe2\x82\xac'

ISO8859-1:['bh\\xc3\\xa9\\xe2\\x82\\xac']

Here, the only difference in the output is that the "UTF-8" has been changed to "ISO8859-1", i.e., I was expecting a difference is the result of ascii('bh\\xc3\\xa9\\xe2\\x82\\xac'). Instead, I see "bytes obj in", "bytes obj out" -- apparently unchanged. HOWEVER, the result returned by get_output is always different, even it is just limited to removing the 'b' quality.

Again: test result includes:
 ISO8859-1:['h\xc3\xa9\xe2\x82\xac'] - which is not equal to manual CLI with ISO8859-1:['bh\\xc3\\xa9\\xe2\\x82\\xac']

So, I feel the issue is not with test, but within what happens after:

  +127      proc = subprocess.Popen(cmd_line, stdin=subprocess.PIPE,
  +128                           stdout=subprocess.PIPE, stderr=subprocess.PIPE,
  +129                           env=env, cwd=cwd)

Specifically: here.

  +130      with proc:
  +131          try:
  +132              out, err = proc.communicate()
  +133          finally:
  +134              proc.kill()
  +135              subprocess._cleanup()
  +136      rc = proc.returncode
  +137      err = strip_python_stderr(err)
  +138      return _PythonRunResult(rc, out, err), cmd_line


PASS:
['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8', '-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']
 0 b"UTF-8:['h\\xe9\\u20ac']\n" b''

FAIL:
['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8=0', '-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']
 0 b"ISO8859-1:['h\\xc3\\xa9\\xe2\\x82\\xac']\n" b''

Seems the 'b' quality disappears somehow with:
  +216              args = out.partition(':')[2].rstrip()

So, maybe it is in test - in that line.

However, this goes well beyond my comprehension of python internal workings.

Hope this helps. Please comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Thu Aug  9 08:26:28 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 09 Aug 2018 12:26:28 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533817588.43.0.56676864532.issue34363@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

The problem with this solution is that it may brea (relatively common) use case of tuple valued fields, e.g.:

>>> tuple(*[x for x in a])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: tuple expected at most 1 arguments, got 2

Essentially, named tuples are all subclasses of `tuple` but they override __new__ in an incompatible way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Thu Aug  9 09:19:59 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 09 Aug 2018 13:19:59 +0000
Subject: [issue27494] 2to3 parser failure caused by a comma after a generator
 expression
In-Reply-To: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za>
Message-ID: <1533820799.93.0.56676864532.issue27494@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This is one of those issues where it's clear that the parser and 2to3 should be separate.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27494>
_______________________________________

From report at bugs.python.org  Thu Aug  9 09:39:38 2018
From: report at bugs.python.org (Erik Bray)
Date: Thu, 09 Aug 2018 13:39:38 +0000
Subject: [issue34212] Cygwin link failure with builtin modules since issue30860
In-Reply-To: <1532452252.87.0.56676864532.issue34212@psf.upfronthosting.co.za>
Message-ID: <1533821978.94.0.56676864532.issue34212@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
pull_requests: +8199

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34212>
_______________________________________

From report at bugs.python.org  Thu Aug  9 09:42:04 2018
From: report at bugs.python.org (Erik Bray)
Date: Thu, 09 Aug 2018 13:42:04 +0000
Subject: [issue34212] Cygwin link failure with builtin modules since issue30860
In-Reply-To: <1532452252.87.0.56676864532.issue34212@psf.upfronthosting.co.za>
Message-ID: <1533822124.01.0.56676864532.issue34212@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

I added a new PR modifying makesetup and adding a new variable to Makefile.pre.in, PY_BUILTIN_MODULE_CFLAGS, explicitly for building built-in modules.

I think this, or some version of it, is a cleaner solution than my previous brute-force approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34212>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:17:49 2018
From: report at bugs.python.org (Alexander Tsvetkov)
Date: Thu, 09 Aug 2018 14:17:49 +0000
Subject: [issue34367] AsyncResult.get() only notifies one thread
Message-ID: <1533824269.46.0.56676864532.issue34367@psf.upfronthosting.co.za>


New submission from Alexander Tsvetkov <xflower at gmail.com>:

If more than one thread is waiting for the multiprocessing.pool.AsyncResult (aka ApplyResult) returned from apply_async, only one thread will be notified once the result arrives.

It happens because AsyncResult._set calls notify upon the result arrival, not notify_all.

threading.Event used in Python 3 uses notify_all.

Reproduction script is attached.
Expected outcome:
1
1
is printed to STDOUT.

Observed outcome:
The script hangs.

----------
components: Library (Lib)
files: async_result_demo.py
messages: 323323
nosy: AlexWithBeard
priority: normal
severity: normal
status: open
title: AsyncResult.get() only notifies one thread
versions: Python 2.7
Added file: https://bugs.python.org/file47736/async_result_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34367>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:41:24 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 09 Aug 2018 14:41:24 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533825684.86.0.56676864532.issue34270@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, the C implementation of Task.__init__ is not exactly equivalent to the Python implementation (nor to both the C and Python implementation of Task.set_name).  In the C impl of Task.__init__ the provided name is used as-is if it's an instance of str:

   (_asyncio_Task___init___impl() in Modules/_asynciomodule.c)

   if (name == Py_None) {
       name = PyUnicode_FromFormat("Task-%" PRIu64, ++task_name_counter);
   } else if (!PyUnicode_Check(name)) {
       name = PyObject_Str(name);
   } else {
       Py_INCREF(name);
   }

One of the following should happen, right?

1. fix the Python implementation of Task.__init__() and both impl of Task.set_name()
2. change the check to PyUnicode_CheckExact()
3. remove the special-case (i.e. change the C impl to match the Python impl)

p.s. Sorry I did not notice this before it got committed. :/

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:46:46 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 14:46:46 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533826006.71.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> 2. change the check to PyUnicode_CheckExact()

I'd be OK with this, but why is this important?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:47:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 14:47:49 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533826069.65.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

As a side note, Alex, what do you think about appending coroutine's name to Task's name if the latter is autogenerated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:51:25 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 14:51:25 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533826285.77.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

I also couldn't figure out yet why PyUnicode_Check() was necessary in the first place. Doesn't PyObject_Str() just increment the refcount if the argument is already a string?

Eric, please explain why these changes should be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:52:23 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 14:52:23 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533826343.44.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Yury, I have no objections. Furthermore, it would be nice to expose the coroutine object publicly, like curio and trio do. It would make life simpler for me in some cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 10:55:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 14:55:28 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533826528.24.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I also couldn't figure out yet why PyUnicode_Check() was necessary in the first place. Doesn't PyObject_Str() just increment the refcount if the argument is already a string?

`str()` returns its argument if it's exactly a `builtins.str` instance.  If it's a subclass of str, it will construct a `builtins.str` out of it.

>>> class mystr(str):
...     pass
>>> a = mystr('aaa')
>>> str(a) is a
False

So Eric is right, there's a small discrepancy between Python and C version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:00:20 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 15:00:20 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533826820.16.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Ok, I understand. But is the conversion a bad thing then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:05:42 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 09 Aug 2018 15:05:42 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533827142.91.0.56676864532.issue34324@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 599bfa18f8ebcb23af300b6855934048c3c64e7d by Mariatta (St?phane Wirtel) in branch 'master':
bpo-34324: Doc README wrong directory name for venv (GH-8650)
https://github.com/python/cpython/commit/599bfa18f8ebcb23af300b6855934048c3c64e7d


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:06:12 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Aug 2018 15:06:12 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533827172.45.0.56676864532.issue34324@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8200

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:06:21 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Aug 2018 15:06:21 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533827181.28.0.56676864532.issue34324@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8201

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:06:49 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 09 Aug 2018 15:06:49 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533827209.41.0.56676864532.issue34324@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:10:31 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Aug 2018 15:10:31 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533827431.15.0.56676864532.issue34324@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fe8f90aa3ca3f277cac634cdb96b829039225c6b by Miss Islington (bot) in branch '3.7':
bpo-34324: Doc README wrong directory name for venv (GH-8650)
https://github.com/python/cpython/commit/fe8f90aa3ca3f277cac634cdb96b829039225c6b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:16:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 15:16:55 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533827815.86.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Ok, I understand. But is the conversion a bad thing then?

It's not a bad thing, it's just that we don't do it in C Task and we do it in pure Python Task.  Eric wants us to synchronize them so that in a very unlikely scenario where someone uses subclasses of str for names they will have exact same behaviour under both Tasks implementations.

I'd say let's just fix the C version to use PyUnicode_CheckExact.  Even though it's highly unlikely somebody ever hits this, there's no reason to keep Python and C implementations even slightly out of sync w.r.t. behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:17:14 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Aug 2018 15:17:14 +0000
Subject: [issue34324] Doc README wrong directory name for venv
In-Reply-To: <1533251941.31.0.56676864532.issue34324@psf.upfronthosting.co.za>
Message-ID: <1533827834.66.0.56676864532.issue34324@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0ee2a29585e3c17e38eb6e6a2515405e40be22b5 by Miss Islington (bot) in branch '3.6':
bpo-34324: Doc README wrong directory name for venv (GH-8650)
https://github.com/python/cpython/commit/0ee2a29585e3c17e38eb6e6a2515405e40be22b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34324>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:22:13 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 09 Aug 2018 15:22:13 +0000
Subject: [issue34362] User-created types with wrong __new__ can be instantiated
In-Reply-To: <1533755253.45.0.56676864532.issue34362@psf.upfronthosting.co.za>
Message-ID: <1533828133.42.0.56676864532.issue34362@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm not sure that this is a duplicate of #5322.  That one's about a warning when arguments are passed to object.__new__().  Yours is about using an incompatible __new__ when creating a new class in Python.  I agree that behavior you're seeing is unexpected and should probably be fixed.

Let's look at the situation a little more closely.  Here's what I understood you reported:

    >>> class X:
    ...   __new__ = tuple.__new__
    ...
    >>> x1 = X()  # This does not fail!

However, that is a little misleading because you might think it is calling tuple.__new__().  It isn't.  Apparently type.__call__() is invoking object.__new__() instead of X.__new__():

    >>> x2 = X([1, 2])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object() takes no parameters
    >>> object.__new__(X, [1, 2])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object() takes no parameters

If I had a little more time I'd look into the relevant code to see what's going on.  In the meantime, let's see if we can find the edges of this problem.

We can verify that X.__new__ is still set to tuple.__new__:

    >>> X.__new__ is object.__new__
    False
    >>> X.__new__ is tuple.__new__
    True
    >>> X.__new__(X)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: tuple.__new__(X): X is not a subtype of tuple
    >>> X.__new__(X, [1, 2])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: tuple.__new__(X): X is not a subtype of tuple
    >>> X.__new__(tuple)
    ()
    >>> X.__new__(tuple, [1, 2])
    (1, 2)

If we explicitly defer to tuple.__new__() then we get an error that matches our expectations better:

    >>> class Y:
    ...   def __new__(cls, *args, **kwargs):
    ...     return tuple.__new__(cls, *args, **kwargs)
    ...
    >>> y = Y()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 3, in __new__
    TypeError: tuple.__new__(Y): Y is not a subtype of tuple

This reinforces the conclusion that tuple.__call__() is doing something funny here.  We can take that conclusion further by seeing that the unexpected behavior is not specific to using tuple.__new__:

    >>> class Z:
    ...   __new__ = int.__new__
    ...
    >>> z1 = Z()
    >>> z2 = Z(42)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object() takes no parameters
    >>> Z.__new__(Z)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: int.__new__(Z): Z is not a subtype of int

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34362>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:26:42 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 15:26:42 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533828402.07.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> It's not a bad thing, it's just that we don't do it in C Task and we do it in pure Python Task.  Eric wants us to synchronize them so that in a very unlikely scenario where someone uses subclasses of str for names they will have exact same behaviour under both Tasks implementations.

Should a new issue be created for this so I can make a PR against it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:28:00 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Aug 2018 15:28:00 +0000
Subject: [issue34367] AsyncResult.get() only notifies one thread
In-Reply-To: <1533824269.46.0.56676864532.issue34367@psf.upfronthosting.co.za>
Message-ID: <1533828480.15.0.56676864532.issue34367@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34367>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:34:27 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 15:34:27 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533828867.75.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Let's just reuse this issue, it's just a small fix.

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:36:11 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 15:36:11 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533828971.21.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Which way do we want to change this? Do we want to convert to pure strings or retain the original object? In the latter case both the C and Python implementations (including set_name()) have to be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:39:36 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 09 Aug 2018 15:39:36 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533829176.37.0.56676864532.issue34270@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm not too invested in any changes happening at this point, actually. :)  Mostly I happened to be reading through the commit and noticed the inconsistency.  If I had reviewed the PR then I would have asked that it be fixed.  So I figured I'd mention it.

FWIW, I don't expect it would cause any problems.  It could result in a different (between the two implementations) Task repr if the name's type (a str subclass) implements __repr__.  There's also the possibility of side-effects (from the implementation of the name's type).  Neither is a big deal (especially the latter since it's *not* a common use case).  On the other had, the matter is made moot by using PyUnicode_CheckExact(). :)

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 11:44:29 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 15:44:29 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533829469.28.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> On the other had, the matter is made moot by using PyUnicode_CheckExact()

Then, in order to keep the pure Python implementation in sync, we'd have to change it to something like this:

if name is None:
   self._name = f'Task-{_task_name_counter()}'
elif isinstance(name, str):
   self._name = name
else:
   self._name = str(name)

I don't know about you, but it looks pretty awkward to me.

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 12:00:39 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 16:00:39 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533830439.35.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__ and use the same if check in C Task.set_name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 12:06:05 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 16:06:05 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533830765.07.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> Please just change PyUnicode_Check to PyUnicode_CheckExact in C Task.__init__ and use the same if check in C Task.set_name.

I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different in semantics then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 12:09:39 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 16:09:39 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533830979.28.0.56676864532.issue34270@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different in semantics then.

Probably I'm missing something here. How would they be different?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 12:10:11 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 16:10:11 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533831011.38.0.56676864532.issue34270@psf.upfronthosting.co.za>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

> 
I'll do that if you say so, but I'm just saying that the C and Python implementations will still remain different in semantics then.

Never mind, that was a brain fart. I keep ignoring the "!" in my mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 12:19:30 2018
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Thu, 09 Aug 2018 16:19:30 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533831570.28.0.56676864532.issue34270@psf.upfronthosting.co.za>


Change by Alex Gr?nholm <alex.gronholm at nextday.fi>:


----------
pull_requests: +8202

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 13:30:35 2018
From: report at bugs.python.org (Andriy Maletsky)
Date: Thu, 09 Aug 2018 17:30:35 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1533835835.77.0.56676864532.issue32102@psf.upfronthosting.co.za>


Change by Andriy Maletsky <andriy.maletsky at gmail.com>:


----------
pull_requests: +8204

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Thu Aug  9 13:52:28 2018
From: report at bugs.python.org (ppperry)
Date: Thu, 09 Aug 2018 17:52:28 +0000
Subject: [issue34362] User-created types with wrong __new__ can be instantiated
In-Reply-To: <1533755253.45.0.56676864532.issue34362@psf.upfronthosting.co.za>
Message-ID: <1533837148.77.0.56676864532.issue34362@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

issue5322, despite its confusing title, mentions this exact bug in one of the comments below. 

It looks like there is one bug in the logic for assigning `__new__`, which causes `__new__` and `tp_new` to point to different things, confusing the error-handling logic in `object.__new__` as well as causing creation of a type by calling it to work in cases where direct calls to __new__ fail.

There's no one bug report about that, however issue5322, issue25731 and some cases of issue34284 are all symptoms of the same root issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34362>
_______________________________________

From report at bugs.python.org  Thu Aug  9 16:12:59 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Thu, 09 Aug 2018 20:12:59 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533845579.66.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

I've tried to check the source code of IDLE in search of chained comparisons without parenthesis (like the example I showed and the bug with the mouse wheel). I couldn't find something important.

Then I wrote in a file the following code:

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(200)]
text.insert(tkinter.END, ''.join(lines))

In both Python 3.6 and 3.7 with Tk 8.6.8 on macOS 10.13, click-and-drag on the upper half of the scrollbar slider has no effect (the slider sticks at the top), like in the bugs #1 and #3. I strongly suspect a tkinter problem, as the equivalent Tcl/Tk code functions well. Click-and-drag in the lower half of the slider functions (in my code and IDLE) for me. Can someone reproduce this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Thu Aug  9 16:49:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 09 Aug 2018 20:49:59 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1533847799.84.0.56676864532.issue34270@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Thu Aug  9 16:56:29 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Thu, 09 Aug 2018 20:56:29 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533848189.53.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

Edit:

The code is:

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
 
def click_trace(event):
    text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x, event.y, vbar.identify(event.x, event.y)))

vbar.bind('<Button-1>', click_trace)

root.mainloop()

Clicking at the top on the slider shows that the Scrollbar considers it as being on "through1" (in Tk the zone between the upper arrow and the "slider") and NOT on the "slider". Please, play with the script (python3 tktest.py) and see the results for yourselves.

----------
Added file: https://bugs.python.org/file47737/tktest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Thu Aug  9 17:15:05 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Thu, 09 Aug 2018 21:15:05 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533849305.55.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

And the result (video) of my script is attached to this post.

----------
Added file: https://bugs.python.org/file47738/tkinter_scroll_issues.mov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Thu Aug  9 18:02:59 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Aug 2018 22:02:59 +0000
Subject: [issue32102] Add "capture_output=True" option to subprocess.run
In-Reply-To: <1511244827.04.0.213398074469.issue32102@psf.upfronthosting.co.za>
Message-ID: <1533852179.5.0.56676864532.issue32102@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8205

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32102>
_______________________________________

From report at bugs.python.org  Thu Aug  9 19:47:27 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Aug 2018 23:47:27 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533858447.53.0.56676864532.issue34047@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Vlad, can you test the current patch on PR 8678 on Mac?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Thu Aug  9 20:49:30 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Aug 2018 00:49:30 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533862170.03.0.56676864532.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Maybe do both, then. Also, it's probably better for performance reasons (I know: premature optimization and all that ...):

@@ -1018,8 +1018,10 @@ def _asdict_inner(obj, dict_factory):
             value = _asdict_inner(getattr(obj, f.name), dict_factory)
             result.append((f.name, value))
         return dict_factory(result)
-    elif isinstance(obj, (list, tuple)):
+    elif type(obj) in (list, tuple):
         return type(obj)(_asdict_inner(v, dict_factory) for v in obj)
+    elif isinstance(obj, (list, tuple)):
+        return type(obj)(*[_asdict_inner(v, dict_factory) for v in obj])
     elif isinstance(obj, dict):
         return type(obj)((_asdict_inner(k, dict_factory), _asdict_inner(v, dict_factory))
                           for k, v in obj.items())

I guess we could argue it's a bug in nametuples, but I don't see that getting us very far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Thu Aug  9 22:07:42 2018
From: report at bugs.python.org (ppperry)
Date: Fri, 10 Aug 2018 02:07:42 +0000
Subject: [issue5322] object.__new__ argument calling autodetection faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1533866862.92.0.56676864532.issue5322@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Fri Aug 10 00:27:00 2018
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 10 Aug 2018 04:27:00 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533875220.48.0.56676864532.issue34363@psf.upfronthosting.co.za>


Neil Girdhar <mistersheik at gmail.com> added the comment:

Sorry if I'm intruding here, but I really dislike that we are doing isinstance versus list, tuple, and dict.  And I dislike even more type(x) in (list, tuple).  I think the ideal thing to do would have been to check versus abstract base classes like isinstance(x, Sequence) and isinstance(x, Mapping).  The advantage to this is flexibility with user-defined types.

The problem seems to be that the abstract base classes don't promise anything about the constructor.  It seems like some Sequence types accept an Iterable (e.g. tuple), but others like NamedTuple want positional arguments.  I think this promise should be encoded in some way.

Maybe a third solution is to have NamedTuple special-cased out:

isinstance(x, Sequence) and not isinstance(x, NamedTuple)

If there are other Sequence types that do this (are there?) then an abstract base class could be created.

This solution has the benefit of playing the most nicely with user-defined classes.

----------
nosy: +NeilGirdhar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 00:57:34 2018
From: report at bugs.python.org (H-ZeX)
Date: Fri, 10 Aug 2018 04:57:34 +0000
Subject: [issue34368] ftplib __init__ function can't handle 120 or 4xy reply
 when connect to the server
Message-ID: <1533877054.01.0.56676864532.issue34368@psf.upfronthosting.co.za>


Change by H-ZeX <hzx20112012 at gmail.com>:


----------
components: XML
nosy: H-ZeX
priority: normal
severity: normal
status: open
title: ftplib __init__ function can't handle 120 or 4xy reply when connect to the server
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34368>
_______________________________________

From report at bugs.python.org  Fri Aug 10 00:57:59 2018
From: report at bugs.python.org (H-ZeX)
Date: Fri, 10 Aug 2018 04:57:59 +0000
Subject: [issue34368] ftplib __init__ function can't handle 120 or 4xy reply
 when connect to the server
Message-ID: <1533877079.57.0.56676864532.issue34368@psf.upfronthosting.co.za>


Change by H-ZeX <hzx20112012 at gmail.com>:


----------
components: +Library (Lib) -XML

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34368>
_______________________________________

From report at bugs.python.org  Fri Aug 10 01:01:02 2018
From: report at bugs.python.org (H-ZeX)
Date: Fri, 10 Aug 2018 05:01:02 +0000
Subject: [issue34368] ftplib __init__ function can't handle 120 or 4xy reply
 when connect to the server
Message-ID: <1533877262.72.0.56676864532.issue34368@psf.upfronthosting.co.za>


New submission from H-ZeX <hzx20112012 at gmail.com>:

in the __init__ function, call getresp,

however, the getresp don't handle the 120 reply which indicate the request should be delay or 421 reply

in the rfc 959 page 50, there are all reply that may return

Connection Establishment
120
220
220
421

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34368>
_______________________________________

From report at bugs.python.org  Fri Aug 10 01:12:12 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 10 Aug 2018 05:12:12 +0000
Subject: [issue34353] stat's python implementation of filemode (fallback)
 doesn't behave like the C implementation
In-Reply-To: <1533662594.31.0.56676864532.issue34353@psf.upfronthosting.co.za>
Message-ID: <1533877932.63.0.56676864532.issue34353@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b92c526ed5da474694f89e29d82565f2a654c29b by Benjamin Peterson (GPery) in branch 'master':
closes bpo-34353: Add sockets to stat.filemode fallback python implementation. (GH-8703)
https://github.com/python/cpython/commit/b92c526ed5da474694f89e29d82565f2a654c29b


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34353>
_______________________________________

From report at bugs.python.org  Fri Aug 10 01:50:55 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 10 Aug 2018 05:50:55 +0000
Subject: [issue32745] ctypes string pointer fields should accept embedded null
 characters
In-Reply-To: <1517514890.15.0.467229070634.issue32745@psf.upfronthosting.co.za>
Message-ID: <1533880255.0.0.56676864532.issue32745@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8206
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32745>
_______________________________________

From report at bugs.python.org  Fri Aug 10 01:52:17 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 10 Aug 2018 05:52:17 +0000
Subject: [issue32745] ctypes string pointer fields should accept embedded null
 characters
In-Reply-To: <1517514890.15.0.467229070634.issue32745@psf.upfronthosting.co.za>
Message-ID: <1533880337.47.0.56676864532.issue32745@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32745>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:02:11 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 10 Aug 2018 06:02:11 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533880931.79.0.56676864532.issue34047@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 077059e0f086cf8c8b7fb9d1f053e38ddc743f59 by Tal Einat in branch 'master':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/077059e0f086cf8c8b7fb9d1f053e38ddc743f59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:02:36 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Aug 2018 06:02:36 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533880956.03.0.56676864532.issue34047@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8207

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:02:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Aug 2018 06:02:44 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533880964.24.0.56676864532.issue34047@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8208

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:20:16 2018
From: report at bugs.python.org (Toshio Kuratomi)
Date: Fri, 10 Aug 2018 06:20:16 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
Message-ID: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

The current kqueue documentation specifies that timeout is a keyword argument but it can only be passed as a positional argument right now:

>>> import select
>>> ko = select.kqueue()
>>> ko.control([1], 0, timeout=10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: control() takes no keyword arguments
>>> help(ko.control)
Help on built-in function control:

control(...) method of select.kqueue instance
    control(changelist, max_events[, timeout=None]) -> eventlist
    
    Calls the kernel kevent function.
    - changelist must be an iterable of kevent objects describing the changes
      to be made to the kernel's watch list or None.
    - max_events lets you specify the maximum number of events that the
      kernel will return.
    - timeout is the maximum time to wait in seconds, or else None,
      to wait forever. timeout accepts floats for smaller timeouts, too.

This may be related to https://bugs.python.org/issue3852 in which the max_events argument used to be documented as optional but the code made it mandatory.

----------
components: Library (Lib)
messages: 323357
nosy: a.badger
priority: normal
severity: normal
status: open
title: kqueue.control() documentation and implementation mismatch
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:28:19 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 10 Aug 2018 06:28:19 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533882499.56.0.56676864532.issue34047@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

The scroll works. Many thanks, I thought the callback should have been rewritten, too. Should one open a different report for the clicks on the scrollbar ends, like in the script I put (independent of IDLE)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:43:10 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Aug 2018 06:43:10 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533883390.23.0.56676864532.issue34047@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ea8835fb302447da82f265a5bc0f785353100271 by Miss Islington (bot) in branch '3.7':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/ea8835fb302447da82f265a5bc0f785353100271


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 02:59:00 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Aug 2018 06:59:00 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533884340.83.0.56676864532.issue34047@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca4badb5c0bedaa4ebcb33b9cad5f64750876750 by Miss Islington (bot) in branch '3.6':
bpo-34047: IDLE: fix mousewheel scrolling direction on macOS (GH-8678)
https://github.com/python/cpython/commit/ca4badb5c0bedaa4ebcb33b9cad5f64750876750


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 03:17:02 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 10 Aug 2018 07:17:02 +0000
Subject: [issue34177] test_site fails in macOS-PR VSTS builds for 3.7 branch
In-Reply-To: <1532158324.8.0.56676864532.issue34177@psf.upfronthosting.co.za>
Message-ID: <1533885422.75.0.56676864532.issue34177@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34177>
_______________________________________

From report at bugs.python.org  Fri Aug 10 04:33:07 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 10 Aug 2018 08:33:07 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533889987.06.0.56676864532.issue34047@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

> Should one open a different report for the clicks on the scrollbar ends, like in the script I put (independent of IDLE)?

Indeed.  Please open a new issue with an appropriate title and attach your example script and video.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 04:33:22 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 10 Aug 2018 08:33:22 +0000
Subject: [issue34047] IDLE: on macOS, scroll slider 'sticks' at bottom of file
In-Reply-To: <1530724487.68.0.56676864532.issue34047@psf.upfronthosting.co.za>
Message-ID: <1533890002.59.0.56676864532.issue34047@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34047>
_______________________________________

From report at bugs.python.org  Fri Aug 10 05:28:00 2018
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 10 Aug 2018 09:28:00 +0000
Subject: [issue34360] urllib.parse doesn't fully comply to RFC 3986
In-Reply-To: <1533744155.42.0.56676864532.issue34360@psf.upfronthosting.co.za>
Message-ID: <1533893280.35.0.56676864532.issue34360@psf.upfronthosting.co.za>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

I confirm violation of https://tools.ietf.org/html/rfc3986#section-3.2.2 . 

URLs are now covered by RFC 3986 which obsoletes RFC 1808 that `urllib's documentation refers to.

This new URL RFC adds [] to 'reserved' characters, so them being present unquoted anywhere where reserved characters are not allowed shall be a parsing error.

----------
nosy: +Ivan.Pozdeev
title: urllib.parse doesn't fail with multiple unmatching square brackets -> urllib.parse doesn't fully comply to RFC 3986
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34360>
_______________________________________

From report at bugs.python.org  Fri Aug 10 06:07:16 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 10 Aug 2018 10:07:16 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
Message-ID: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>


New submission from Vlad Tudorache <tudorache.vlad at gmail.com>:

Run the python script below.

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
 
def click_trace(event):
    text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x, event.y, vbar.identify(event.x, event.y)))

vbar.bind('<Button-1>', click_trace)

root.mainloop()

When the slider is at the top of the scrollbar, clicking on its upper half doesn't allow dragging. The little script shows that the Scrollbar considers it as being on "through1" - in Tk the zone between the upper arrow and the "slider" - and not on "slider". Another consequence is that one can drag (up and down) the slider when clicking a little bit below the slider, on "through2" region. This issue doesn't manifest on Windows, where the scrollbar's arrows are shown.
I've seen this issue when trying to explore the reasons of another (34047, fixed) concerning the slider locked at the end of the scrollbar in IDLE.

----------
components: Tkinter
messages: 323363
nosy: vtudorache
priority: normal
severity: normal
status: open
title: Tkinter scroll issues on macOS
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Fri Aug 10 06:08:41 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 10 Aug 2018 10:08:41 +0000
Subject: [issue34343] Why is turtle still present in python embedded for
 Windows?
In-Reply-To: <1533547471.89.0.56676864532.issue34343@psf.upfronthosting.co.za>
Message-ID: <1533895721.14.0.56676864532.issue34343@psf.upfronthosting.co.za>


Change by Vlad Tudorache <tudorache.vlad at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34343>
_______________________________________

From report at bugs.python.org  Fri Aug 10 06:57:10 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 10 Aug 2018 10:57:10 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533898630.2.0.56676864532.issue34363@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Eric, I like your solution. It is probably not perfect, but at least it solves the existing problem without introducing obvious problems.

Neil, your way will not work since named tuples don't have NamedTuple in their MROs:

CustomNT.mro == (CustomNT, tuple, object)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 07:38:55 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Aug 2018 11:38:55 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1533901135.68.0.56676864532.issue34369@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Fri Aug 10 07:41:39 2018
From: report at bugs.python.org (Marcel Plch)
Date: Fri, 10 Aug 2018 11:41:39 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1533901299.17.0.56676864532.issue34097@psf.upfronthosting.co.za>


Change by Marcel Plch <gmarcel.plch at gmail.com>:


----------
pull_requests: +8209
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Fri Aug 10 07:43:14 2018
From: report at bugs.python.org (Sverrir Berg)
Date: Fri, 10 Aug 2018 11:43:14 +0000
Subject: [issue34371] File reading gets stuck if you read at eof on macos
Message-ID: <1533901394.11.0.56676864532.issue34371@psf.upfronthosting.co.za>


New submission from Sverrir Berg <sab at keilir.com>:

Reading a file that is at eof causes the file reading to halt indefinitely.
1) open() a file and read() everything from it.
2) call read() a second time - reading nothing (this causes the issue).
3) append to the file (using another file handle or manually).
4) try to read it again - read() always returns nothing.

Attached is a a test causing this - works correctly on Ubuntu 2.7.12/3.5.2, macos 3.7.0, macos PyPy 5.10.0 but fails on macos 2.7.10/2.7.15(brew)

I assume the expected behaviour is the same as on the other versions where you can continue to read from the file when it has been appended to?

----------
components: IO
files: readwrite.py
messages: 323365
nosy: sverrirab
priority: normal
severity: normal
status: open
title: File reading gets stuck if you read at eof on macos
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file47739/readwrite.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34371>
_______________________________________

From report at bugs.python.org  Fri Aug 10 08:00:01 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 10 Aug 2018 12:00:01 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1533902401.2.0.56676864532.issue34369@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

This is probably a regression from the Argument Clinic conversion.

Another docstring mismatches:

select(rlist, wlist, xlist, timeout=None, /)
    Wait until one or more file descriptors are ready for some kind of I/O.


>>> select.select(timeout=0.1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: select() takes no keyword arguments


poll(timeout=None, /) method of select.poll instance
    Polls the set of registered file descriptors.

>>> select.poll().poll(timeout=0.1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: poll() takes no keyword arguments

----------
nosy: +berker.peksag, taleinat
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Fri Aug 10 08:05:54 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 10 Aug 2018 12:05:54 +0000
Subject: [issue34371] File reading gets stuck if you read at eof on macos
In-Reply-To: <1533901394.11.0.56676864532.issue34371@psf.upfronthosting.co.za>
Message-ID: <1533902754.78.0.56676864532.issue34371@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is IMHO not a bug in CPython (or even macOS).  On Python 2.7 file I/O is implemented using C's stdio library and that prescribes this behaviour (the "at EOF" state of a file stream is sticky. 

fd.seek(0, 2) should unset the "at EOF" flag.

----------
nosy: +ronaldoussoren
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34371>
_______________________________________

From report at bugs.python.org  Fri Aug 10 09:03:58 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 10 Aug 2018 13:03:58 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1533906238.2.0.56676864532.issue33125@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

If libffi already has support and just needs to be updated in CPython, then sure. I thought we'd finished extracting it, but Zach posted aPR link above that apparently still needs finishing.

However, if libffi doesn't have the support yet then you'll have to approach them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Aug 10 09:12:14 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 10 Aug 2018 13:12:14 +0000
Subject: [issue34371] File reading gets stuck if you read at eof on macos
In-Reply-To: <1533901394.11.0.56676864532.issue34371@psf.upfronthosting.co.za>
Message-ID: <1533906734.02.0.56676864532.issue34371@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

For completeness sake I've attached a C program demonstrating the same problem.

----------
status: pending -> open
Added file: https://bugs.python.org/file47740/readwrite.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34371>
_______________________________________

From report at bugs.python.org  Fri Aug 10 09:12:19 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 10 Aug 2018 13:12:19 +0000
Subject: [issue34371] File reading gets stuck if you read at eof on macos
In-Reply-To: <1533901394.11.0.56676864532.issue34371@psf.upfronthosting.co.za>
Message-ID: <1533906739.93.0.56676864532.issue34371@psf.upfronthosting.co.za>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34371>
_______________________________________

From report at bugs.python.org  Fri Aug 10 09:50:21 2018
From: report at bugs.python.org (Toshio Kuratomi)
Date: Fri, 10 Aug 2018 13:50:21 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1533909021.36.0.56676864532.issue34369@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

I don't believe (kqueue.control at least) is a regression from Argument Clinic.  Both the documentation and the behaviour are the same in Python-2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Fri Aug 10 11:02:24 2018
From: report at bugs.python.org (Arusekk)
Date: Fri, 10 Aug 2018 15:02:24 +0000
Subject: [issue34372] Compiler could output more accurate line numbers
Message-ID: <1533913344.46.0.56676864532.issue34372@psf.upfronthosting.co.za>


New submission from Arusekk <arek_koz at o2.pl>:

If this is a duplicate, please excuse me.

In particular, the most noticeable inaccuracy happens when the postfix if-else expression is involved. Maybe there are more of them.
The problem is quite self-explaining. The module named 'dis' will be helpful to reproduce the issue.

>>> import dis
>>> code = """(
... [
...     call1(),
...     call2()
... ]
... + call3()
... * call4()
... )"""
>>> dis.dis(code)
  3           0 LOAD_NAME                0 (call1)
              3 CALL_FUNCTION            0 (0 positional, 0 keyword pair)

  4           6 LOAD_NAME                1 (call2)
              9 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             12 BUILD_LIST               2

  6          15 LOAD_NAME                2 (call3)
             18 CALL_FUNCTION            0 (0 positional, 0 keyword pair)

  7          21 LOAD_NAME                3 (call4)
             24 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             27 BINARY_MULTIPLY
             28 BINARY_ADD
             29 RETURN_VALUE
>>> dis.dis(code.replace("+", "if").replace("*", "else"))
  6           0 LOAD_NAME                0 (call3)
              3 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
              6 POP_JUMP_IF_FALSE       25
              9 LOAD_NAME                1 (call1)
             12 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             15 LOAD_NAME                2 (call2)
             18 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             21 BUILD_LIST               2
             24 RETURN_VALUE

  7     >>   25 LOAD_NAME                3 (call4)
             28 CALL_FUNCTION            0 (0 positional, 0 keyword pair)
             31 RETURN_VALUE

I used this code to show the difference between if-else and some arithmetics.

AFAICT the feature is possible to implement, as lnotab can contain negative line differences.

I don't know whether it is just a bug or a fully intended feature, but it would be quite an enhancement to have better line number tracking, useful for debugging.

If this is implemented, it may be worth further backporting.

Possible reasons in the upstream Python/compile.c (using < instead of !=):

https://github.com/python/cpython/blob/077059e0f086cf8c8b7fb9d1f053e38ddc743f59/Python/compile.c#L4092

https://github.com/python/cpython/blob/077059e0f086cf8c8b7fb9d1f053e38ddc743f59/Python/compile.c#L4438

----------
components: Interpreter Core
messages: 323371
nosy: Arusekk
priority: normal
severity: normal
status: open
title: Compiler could output more accurate line numbers
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________

From report at bugs.python.org  Fri Aug 10 12:15:51 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Aug 2018 16:15:51 +0000
Subject: [issue34373] test_time errors on AIX
Message-ID: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

32-bit:

======================================================================
ERROR: test_mktime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/src/python3-3.7.0/Lib/test/test_time.py", line 446, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
FAIL: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/src/python3-3.7.0/Lib/test/test_time.py", line 129, in test_pthread_getcpuclockid
    self.assertNotEqual(clk_id, time.CLOCK_THREAD_CPUTIME_ID)
AssertionError: 12 == 12

----------------------------------------------------------------------

64-bit:
======================================================================
ERROR: test_mktime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/lib/python3.7/test/test_time.py", line 446, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/lib/python3.7/test/test_time.py", line 130, in test_pthread_getcpuclockid
    t1 = time.clock_gettime(clk_id)
OverflowError: signed integer is greater than maximum

The test_mktime failed because
time.mktime(time.localtime(-2)) -- actually any negative value in localtime - fails

The patch in the file Modules/timemodule.c fixes this.

The test_pthread_getcpuclockid is a bit more complex as the result is different
depending on 32 or 64-bit mode.

In 32-bit mode AIX always responds with the constant CLOCK_THREAD_CPUTIME_ID.
The patch in Lib/test/test_time.py makes the test aware of this.

In AIX clockid_t is actually long long. However, changing the type to parse to "L"
broke many other things. It seems to work as a long ("l") when the ABI is 64-bit.

See additional change in Modules/timemodule.c 
static PyObject *
time_clock_gettime

Finally,
added some (additional) range checking for 
_PyTime_localtime for AIX. Not having this complicated testing for above.

----------
components: Interpreter Core, Tests
messages: 323372
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_time errors on AIX
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Fri Aug 10 12:23:57 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 10 Aug 2018 16:23:57 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>
Message-ID: <1533918237.61.0.56676864532.issue34373@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8210
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Fri Aug 10 13:36:47 2018
From: report at bugs.python.org (theger)
Date: Fri, 10 Aug 2018 17:36:47 +0000
Subject: [issue34374] Shouldn't shutil.copyfile replace link in dst with
 follow_symlinks set?
Message-ID: <1533922607.61.0.56676864532.issue34374@psf.upfronthosting.co.za>


New submission from theger <heger.tomas at gmail.com>:

This might not be an issue at all and maybe I'm just missing something but this confused me a bit and hence the question in title.

Python's shutil.copyfile() has a follow_symlinks argument but it only affects the source, not the destination - i.e. when src is a symlink, it makes a difference whether the flag is set (and then it will copy the destination of that src symlink) or not (and then it will just create a new symlink in dst pointing to the src symlink's destination). I hope it's clear so far.

When dst is a link though, the flag doesn't change anything and it will always copy that file to the dst symlink's destination.

My question is... If dst is a symlink and follow_symlinks flag is not set, wouldn't it be more logical if the dst symlink was just replaced by a copy of src instead of copying src to dst's destination?

Thanks and sorry if this is just noise.

----------
components: Library (Lib)
messages: 323373
nosy: theger
priority: normal
severity: normal
status: open
title: Shouldn't shutil.copyfile replace link in dst with follow_symlinks set?
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34374>
_______________________________________

From report at bugs.python.org  Fri Aug 10 13:56:20 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Aug 2018 17:56:20 +0000
Subject: [issue34374] Shouldn't shutil.copyfile replace link in dst with
 follow_symlinks set?
In-Reply-To: <1533922607.61.0.56676864532.issue34374@psf.upfronthosting.co.za>
Message-ID: <1533923780.08.0.56676864532.issue34374@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is following the model of the posix cp command, whose equivalent to 'follow_symlinks' only affects the source.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34374>
_______________________________________

From report at bugs.python.org  Fri Aug 10 13:56:26 2018
From: report at bugs.python.org (Victor Porton)
Date: Fri, 10 Aug 2018 17:56:26 +0000
Subject: [issue34375] Subtests (unittest)
Message-ID: <1533923786.85.0.56676864532.issue34375@psf.upfronthosting.co.za>


New submission from Victor Porton <porton at narod.ru>:

The following is a fragment of a real code:

~~~
    def test_run_xinlude(self):
        # stub_stdin(self, Global.get_resource_bytes("tests/core/data/xml/xinclude.xml"))
        for next_script_mode in ['doc1', 'doc2']:
            for order in ['breadth', 'depth']:
                with capture_stdin_and_stdout():
                    command_line.main(['-r',
                                       order,
                                       'chain',
                                       Global.get_filename("tests/core/data/xml/xinclude.xml"),
                                       '-u',
                                       'http://portonvictor.org/ns/trans/precedence-include',
                                       '-s',
                                       next_script_mode])
                    self.assertEqual(sys.stdout.buffer.getvalue(), TestUtility.XInclude_output,
                                     "for next_script=%s, order=%s" % (next_script_mode, order))
~~~

I wrote it in one test method instead of four similar methods.

It has the deficiency that if the first test fails, the three remaining tests are skipped.

I propose to add `subtest` context manager to use it like:

~~~
            with subtest():
                with capture_stdin_and_stdout():
                    command_line.main(['-r',
                                       order,
                                       'chain',
                                       Global.get_filename("tests/core/data/xml/xinclude.xml"),
                                       '-u',
                                       'http://portonvictor.org/ns/trans/precedence-include',
                                       '-s',
                                       next_script_mode])
                    self.assertEqual(sys.stdout.buffer.getvalue(), TestUtility.XInclude_output,
                                     "for next_script=%s, order=%s" % (next_script_mode, order))
~~~

which would split our test into four independent tests.

----------
components: Library (Lib)
messages: 323375
nosy: porton
priority: normal
severity: normal
status: open
title: Subtests (unittest)
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34375>
_______________________________________

From report at bugs.python.org  Fri Aug 10 13:59:14 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Aug 2018 17:59:14 +0000
Subject: [issue34375] Subtests (unittest)
In-Reply-To: <1533923786.85.0.56676864532.issue34375@psf.upfronthosting.co.za>
Message-ID: <1533923954.54.0.56676864532.issue34375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

https://docs.python.org/3/library/unittest.html#distinguishing-test-iterations-using-subtests

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34375>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:07:45 2018
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 10 Aug 2018 18:07:45 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533924465.6.0.56676864532.issue34363@psf.upfronthosting.co.za>


Neil Girdhar <mistersheik at gmail.com> added the comment:

Why can't we add an ABC into a NamedTuple instance's MRO?  Because while I like Eric's solution, it seems to be backwards:  tuple and list are not the special cases?NamedTuple is.

All sequences accept an iterable in their constructor, and NamedTuple doesn't.  So it should be NamedTuple that is marked as being "weird".  Right now, NamedTuple instances claim to be tuples, but don't accept iterables to initialize themselves.  That seems wrong.

This problem that we have with dataclass can easily pop up somewhere else, and it will require the same restriction to list and tuple types to fix it (breaking user-defined types).

Is it imposible to add to the MRO of NamedTuple instances?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:19:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Aug 2018 18:19:58 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
Message-ID: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Apply two accuracy improvements that work well together and that are both cheap (less than 5% difference in speed).  

1. Moving the max value to the end saves an iteration and can improve accuracy (especially in the case where len(args) <= 3 where the summation order is always optimal).

2. Use Kahan summation which works especially well because all the inputs are non-negative.

The patched version generally gets the error down to within 1 ULP (tested with 100,000 trials using 100 arguments to hypot() where the arguments are generated using random.expovariate(1.0) and arranged in the least favorable order, largest-to-smallest):

Patched:
 [(0.0, 67276),
  (1.0, 16700),
  (-0.5, 14702),
  (-1.0, 1322)]

Baseline:
[(1.0, 30364),
 (0.0, 25328),
 (-0.5, 17407),
 (-1.0, 10554),
 (2.0, 6274),
 (-1.5, 4890),
 (-2.0, 3027),
 (-2.5, 897),
 (3.0, 752),
 (-3.0, 380),
 (-3.5, 61),
 (4.0, 51),
 (-4.0, 13),
 (-4.5, 1),
 (5.0, 1)]

The impact on performance is minimal (well under 5%).

Patched:
$ py -c 'import sys; print(sys.version)'
3.8.0a0 (heads/hypot-kahan-late-swap-2:e1d89184f0, Aug 10 2018, 11:06:21)
[Clang 9.1.0 (clang-902.0.39.2)]
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(15.0, 14.0, 13.0, 12.0, 11.0, 10.0, 9.0, 8.0, 7.0, 6.0, 5.0, 4.0, 3.0, 2.0, 1.0)'
1000000 loops, best of 7: 230 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(10.0, 9.0, 8.0, 7.0, 6.0, 5.0, 4.0, 3.0, 2.0, 1.0)'
2000000 loops, best of 7: 170 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(5.0, 4.0, 3.0, 2.0, 1.0)'
2000000 loops, best of 7: 119 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(3.0, 2.0, 1.0)'
5000000 loops, best of 7: 95.7 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(2.0, 1.0)'
5000000 loops, best of 7: 81.5 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(1.0)'
5000000 loops, best of 7: 67.4 nsec per loop

Baseline:
$ py -c 'import sys; print(sys.version)'
3.8.0a0 (heads/master:077059e0f0, Aug 10 2018, 11:02:47)
[Clang 9.1.0 (clang-902.0.39.2)]
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(15.0, 14.0, 13.0, 12.0, 11.0, 10.0, 9.0, 8.0, 7.0, 6.0, 5.0, 4.0, 3.0, 2.0, 1.0)'
1000000 loops, best of 7: 237 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(10.0, 9.0, 8.0, 7.0, 6.0, 5.0, 4.0, 3.0, 2.0, 1.0)'
2000000 loops, best of 7: 173 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(5.0, 4.0, 3.0, 2.0, 1.0)'
2000000 loops, best of 7: 120 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(3.0, 2.0, 1.0)'
5000000 loops, best of 7: 94.8 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(2.0, 1.0)'
5000000 loops, best of 7: 80.3 nsec per loop
$ py -m timeit -r 7 -s 'from math import hypot' 'hypot(1.0)'
5000000 loops, best of 7: 67.1 nsec per loop

----------
assignee: rhettinger
components: Library (Lib)
files: measure_hypot_alternatives.py
messages: 323378
nosy: mark.dickinson, rhettinger, serhiy.storchaka, tim.peters
priority: low
severity: normal
status: open
title: Improve accuracy of math.hypot() and math.dist()
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file47741/measure_hypot_alternatives.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:22:40 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Aug 2018 18:22:40 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533925360.81.0.56676864532.issue34376@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +8211
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:22:49 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Aug 2018 18:22:49 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533925369.87.0.56676864532.issue34363@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +8212
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:28:28 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 10 Aug 2018 18:28:28 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1533925708.53.0.56676864532.issue34370@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

The bug needs forwarding to the Tcl/Tk community. This is the script written in Tcl (run with tclsh8.6 script.tcl for Tcl 8.6 and tclsh8.5 script.tcl for 8.5):

package require Tk

scrollbar .vbar -width 10
text .edit

pack .vbar -side right -fill y
pack .edit -side left -fill both -expand 1

.vbar configure -command {.edit yview}
.edit configure -yscrollcommand {.vbar set}

bind .vbar {<Button-1> } {
	set cx %x
	set cy %y
	set dz [.vbar identify $cx $cy]
	puts "You clicked at ($cx,$cy) on $dz.\n"
}

for {set i 1} {$i <= 256} {incr i} {
	.edit insert "$i.0" "This is the line number $i.\n"
}

I will post two videos made on my MacBook, showing an expected behavior with Tk 8.5 and the scroll problems with Tk 8.6 on macOS.

----------
Added file: https://bugs.python.org/file47742/Tk86MacIssue.mov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:30:29 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Aug 2018 18:30:29 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533925829.8.0.56676864532.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Hmm, for some reason I'm not getting mail from this issue, so I made my PR before I saw the comments since my last comment.

Raymond has resisted adding a base class to namedtuple. I believe the preferred way to identify a namedtuple is to look for a _fields member. We could do that instead of use the (*[]) trick for all classes derived from tuple or list.

Maybe it's worthwhile bringing up the differences in how tuple and namedtuple handle creation with iterables on python-dev.

I'm still not certain of the right approach, but PR 8728 adds some tests and fixes the problem identified in this issue. I probably won't commit it until I can discuss with some other people.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:34:08 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Fri, 10 Aug 2018 18:34:08 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1533926048.29.0.56676864532.issue34370@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

Now, the video for TK 8.5 showing expected behavior on macOS.

----------
Added file: https://bugs.python.org/file47743/Tk85Mac.mov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:37:04 2018
From: report at bugs.python.org (Paul Monson)
Date: Fri, 10 Aug 2018 18:37:04 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1533926224.98.0.56676864532.issue33125@psf.upfronthosting.co.za>


Paul Monson <paulmons at gmail.com> added the comment:

The PR hasn't changed since September.  Is it still active? 

Should I consider updating the libffi_msvc code to support ARM32 in Python?  Completing the switch to libffi makes more sense to me.

I fetched the PR code to my fork and rebased it on the current master branch.  When I run python -m test there are 2 tests that fail.  Is that what's holding the PR up? or is it something more?  I'm new to the Python codebase but I can try to help debugging if the failing tests are the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33125>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:40:52 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Aug 2018 18:40:52 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533926452.47.0.56676864532.issue34363@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Raymond has resisted adding a base class to namedtuple. I believe the
> preferred way to identify a namedtuple is to look for a _fields member.

FWIW, that was also Guido's opinion as well.  A named tuple is generic concept defined in the glossary as "Any tuple-like class whose indexable elements are also accessible using a named attribute".  This includes user-defined classes, classes created by collections.namedtuple, and instances of structseq.  The code generated by oollections.namedtuple was based on patterns already in widespread use at the time.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:52:51 2018
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 10 Aug 2018 18:52:51 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533927171.15.0.56676864532.issue34363@psf.upfronthosting.co.za>


Neil Girdhar <mistersheik at gmail.com> added the comment:

> The code generated by oollections.namedtuple was based on patterns already in widespread use at the time.

That's fair enough.  However, it seems like there is one important difference: unlike any other Sequence, namedtuples cannot be initialized with an iterable.

For that reason, I like Eric's option of checking for the _fields member rather than special-casing list and tuple since it seems like namedtuple is the special case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 14:54:25 2018
From: report at bugs.python.org (Paul Price)
Date: Fri, 10 Aug 2018 18:54:25 +0000
Subject: [issue34377] Update valgrind suppressions
Message-ID: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>


New submission from Paul Price <paul.antony.price at gmail.com>:

I've found that the valgrind suppressions don't work for me with cpython 3.6.2. Renaming PyObject_Free/PyObject_Realloc to _PyObject_Free/_PyObject_Realloc in the suppressions file works.

I've got a patch that I'll put in via a GitHub PR.

----------
components: Demos and Tools
messages: 323385
nosy: Paul Price
priority: normal
severity: normal
status: open
title: Update valgrind suppressions
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Fri Aug 10 15:03:08 2018
From: report at bugs.python.org (Paul Price)
Date: Fri, 10 Aug 2018 19:03:08 +0000
Subject: [issue34377] Update valgrind suppressions
In-Reply-To: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>
Message-ID: <1533927788.12.0.56676864532.issue34377@psf.upfronthosting.co.za>


Change by Paul Price <paul.antony.price at gmail.com>:


----------
keywords: +patch
pull_requests: +8213
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Fri Aug 10 15:14:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Aug 2018 19:14:13 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533928453.43.0.56676864532.issue34376@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What results for all components equal? hypot(1.0, 1.0, ..., 1.0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 15:28:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Aug 2018 19:28:31 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533929311.75.0.56676864532.issue34376@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Would it give a performance benefit if get rid of multiplication and division, and scale by the power of two approximation of the max using ldexp()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 16:02:05 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Aug 2018 20:02:05 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1533931325.66.0.56676864532.issue18307@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Fri Aug 10 16:05:41 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Aug 2018 20:05:41 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1533931541.97.0.56676864532.issue18307@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This will be a semantic change to the value of co_filename so I don't think this can safely be backported.

----------
versions:  -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Fri Aug 10 16:40:32 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Aug 2018 20:40:32 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533933632.32.0.56676864532.issue34376@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> What results for all components equal? hypot(1.0, 1.0, ..., 1.0)

The scaled summation will be exact (all elements scale to 1.0 and frac is always 0.0).

> Would it give a performance benefit if get rid of multiplication 
> and division, and scale by the power of two approximation of the 
> max using ldexp()?

You're right that the multiplication and division are the most expensive part (the adds and subtracts are cheaper and can be done in parallel with subsequent memory fetches).  See the attached Clang and GCC-8 disassemblies.

I've tried a number of variants and couldn't get any performance boost without breaking some of the test cases.  This patch is the best of a dozen attempts.

----------
Added file: https://bugs.python.org/file47744/math_hypot.s

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 16:53:14 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Aug 2018 20:53:14 +0000
Subject: [issue34363] dataclasses.asdict() mishandles dataclass instance
 attributes that are instances of subclassed typing.NamedTuple
In-Reply-To: <1533757285.89.0.56676864532.issue34363@psf.upfronthosting.co.za>
Message-ID: <1533934394.84.0.56676864532.issue34363@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

For the record, I don't disagree with namedtuples not having a base class.

Maybe it's best to let copy.deepcopy() deal with namedtuples, instead of trying to detect them here. So just special case exact tuples and lists, and pass everything else to copy.deepcopy().

>>> C = namedtuple('C', 'a b c')
>>> c = C(1, 2, 3)
>>> b=copy.deepcopy(c)
>>> b
C(a=1, b=2, c=3)
>>> hasattr(b, '_fields')
True
>>> hasattr(c, '_fields')
True
>>> b is c
False
>>>

Although by doing that, you lose dict_factory or tuple_factory on nested data structures, and namedtuples that contain dataclasses would be handled differently, I think. I'll do some investigating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34363>
_______________________________________

From report at bugs.python.org  Fri Aug 10 17:18:48 2018
From: report at bugs.python.org (Tim Peters)
Date: Fri, 10 Aug 2018 21:18:48 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533935928.49.0.56676864532.issue34376@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Not that it matters:  "ulp" is a measure of absolute error, but the script is computing some notion of relative error and _calling_ that "ulp".  It can understate the true ulp error by up to a factor of 2 (the "wobble" of base 2 fp).

Staying away from denorms, this is an easy way to get one ulp with respect to a specific 754 double:

    def ulp(x):
        import math
        mant, exp = math.frexp(x)
        return math.ldexp(0.5, exp - 52)

Then, e.g.,

>>> x
1.9999999999999991
>>> y
1.9999999999999996
>>> y - x
4.440892098500626e-16
>>> oneulp = ulp(x)
>>> oneulp # the same as sys.float_info.epsilon for this x
2.220446049250313e-16
>>> (y - x) / oneulp
2.0

which is the true absolute error of y wrt x.

>>> x + 2 * oneulp == y
True

But:

>>> (y - x) / x
2.220446049250314e-16
>>> _ / oneulp
1.0000000000000004

understates the true ulp error by nearly a factor of 2, while the mathematically (but not numerically) equivalent spelling used in the script:

>>> (y/x - 1.0) / oneulp
1.0

understates it by exactly a factor of 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 17:28:50 2018
From: report at bugs.python.org (Karan)
Date: Fri, 10 Aug 2018 21:28:50 +0000
Subject: [issue34378] Documentation 3.5+
Message-ID: <1533936530.23.0.56676864532.issue34378@psf.upfronthosting.co.za>


New submission from Karan <karan.svnit at gmail.com>:

The documentation link for 3.5+ is having an issue with the left sidebar where the index is present. In 2.7 if I scroll the main doc below to mid of the document the sidebar still shows me the index. The same is not present in the 3.5+. 

I know this is a very minor thing but for a new learner like me who is constantly reading these docs, this very small thing irritates a lot. 

Thanks

----------
assignee: docs at python
components: Documentation
files: imgonline-com-ua-twotoone-eLRSfZftmcsz.jpg
messages: 323393
nosy: Kapple, docs at python
priority: normal
severity: normal
status: open
title: Documentation 3.5+
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47745/imgonline-com-ua-twotoone-eLRSfZftmcsz.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34378>
_______________________________________

From report at bugs.python.org  Fri Aug 10 17:51:16 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Aug 2018 21:51:16 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533937876.22.0.56676864532.issue34376@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's a little more performance data that might suggest where possible speed optimizations may lay (I was mostly going for accuracy improvements in this patch).

On my 2.6GHz (3.6Ghz burst) Haswell, the hypot() function for n arguments takes about 11*n+60 ns per call.

The 60 ns fixed portion goes to function call overhead, manipulating native Python objects scattered all over memory, Inf/NaN handling, and in the external calls to __PyArg_ParseStack(), PyObject_Malloc(), PyFloat_AsDouble(), PyObject_Free(), and PyFloat_FromDouble().

The inlined summation routine accesses native C doubles in consecutive memory addresses.  Per Agner Fog's instruction timing tables, the DIVSD takes 10-13 cycles which is about 3 ns, the MULSD takes 5 cycles which is about 2ns, and ADDSD/SUBSD each have a 3 cycle latency for another 1 ns each.  That accounts for most of the 11 ns per argument variable portion of the running time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Fri Aug 10 17:56:18 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 10 Aug 2018 21:56:18 +0000
Subject: [issue34378] Documentation 3.5+
In-Reply-To: <1533936530.23.0.56676864532.issue34378@psf.upfronthosting.co.za>
Message-ID: <1533938178.19.0.56676864532.issue34378@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Sorry you're having trouble with this.
There is similar issue as https://bugs.python.org/issue28044.

The Python documentation Sphinx theme is now being maintained over at https://github.com/python/python-docs-theme/

Please file the issue there. Thanks.

----------
nosy: +Mariatta
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Make the sidebar in the documentation follow the section automatically

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34378>
_______________________________________

From report at bugs.python.org  Fri Aug 10 18:10:19 2018
From: report at bugs.python.org (Evan Allrich)
Date: Fri, 10 Aug 2018 22:10:19 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
Message-ID: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>


New submission from Evan Allrich <psf at allri.ch>:

At present the note [0] appears under the documentation for `json.dumps` (which does not use the `fp` argument). It seems the note would be better placed with the documentation for the affected function.

[0] 
> Note
> 
> Unlike pickle and marshal, JSON is not a framed protocol, so trying to > serialize multiple objects with repeated calls to dump() using the same > fp will result in an invalid JSON file.

----------
assignee: docs at python
components: Documentation
messages: 323396
nosy: docs at python, eallrich
priority: normal
severity: normal
status: open
title: Move note about repeated calls to json.dump using the same fp to the json.dump section
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Fri Aug 10 18:20:18 2018
From: report at bugs.python.org (Evan Allrich)
Date: Fri, 10 Aug 2018 22:20:18 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533939618.11.0.56676864532.issue34379@psf.upfronthosting.co.za>


Change by Evan Allrich <psf at allri.ch>:


----------
keywords: +patch
pull_requests: +8215
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Fri Aug 10 18:35:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 10 Aug 2018 22:35:27 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1533940527.42.0.56676864532.issue34376@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Retested using Tim's ulp(x) function (see attached script).  The accuracy results are for 1,000 trials using 10,000 arguments to hypot() where the arguments are generated using triangular(0.999, 1.001) and arranged in the least favorable order, largest-to-smallest:

Patched:  
[(-1.0, 129),
 (0.0, 723),
 (1.0, 148)]

Baseline:
[(-33.0, 2),
 (-32.0, 1),
 (-31.0, 1),
 (-28.0, 5),
 (-27.0, 2),
 (-26.0, 4),
 (-25.0, 3),
 (-24.0, 4),
 (-23.0, 1),
 (-21.0, 9),
 (-20.0, 7),
 (-19.0, 6),
 (-18.0, 15),
 (-17.0, 12),
 (-16.0, 6),
 (-15.0, 12),
 (-14.0, 14),
 (-13.0, 15),
 (-12.0, 15),
 (-11.0, 25),
 (-10.0, 21),
 (-9.0, 24),
 (-8.0, 26),
 (-7.0, 29),
 (-6.0, 36),
 (-5.0, 33),
 (-4.0, 37),
 (-3.0, 31),
 (-2.0, 39),
 (-1.0, 43),
 (0.0, 48),
 (1.0, 45),
 (2.0, 32),
 (3.0, 37),
 (4.0, 34),
 (5.0, 25),
 (6.0, 36),
 (7.0, 29),
 (8.0, 35),
 (9.0, 27),
 (10.0, 24),
 (11.0, 17),
 (12.0, 18),
 (13.0, 18),
 (14.0, 18),
 (15.0, 11),
 (16.0, 8),
 (17.0, 6),
 (18.0, 9),
 (19.0, 15),
 (20.0, 8),
 (21.0, 5),
 (22.0, 6),
 (23.0, 4),
 (24.0, 2),
 (25.0, 1),
 (28.0, 2),
 (30.0, 1),
 (33.0, 1)]

----------
Added file: https://bugs.python.org/file47746/hypot_accuracy.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Sat Aug 11 01:45:12 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 05:45:12 +0000
Subject: [issue34333] Path.with_suffix() raises TypeError when doing
 %-formatting
In-Reply-To: <1533330187.01.0.56676864532.issue34333@psf.upfronthosting.co.za>
Message-ID: <1533966312.41.0.56676864532.issue34333@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 423d05f6f59b24c91b9ef6b2e4ac130316764382 by Berker Peksag in branch 'master':
bpo-34333: Fix %-formatting in Path.with_suffix() (GH-8663)
https://github.com/python/cpython/commit/423d05f6f59b24c91b9ef6b2e4ac130316764382


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34333>
_______________________________________

From report at bugs.python.org  Sat Aug 11 01:45:34 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 05:45:34 +0000
Subject: [issue34333] Path.with_suffix() raises TypeError when doing
 %-formatting
In-Reply-To: <1533330187.01.0.56676864532.issue34333@psf.upfronthosting.co.za>
Message-ID: <1533966334.29.0.56676864532.issue34333@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8217

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34333>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:00:13 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:00:13 +0000
Subject: [issue34333] Path.with_suffix() raises TypeError when doing
 %-formatting
In-Reply-To: <1533330187.01.0.56676864532.issue34333@psf.upfronthosting.co.za>
Message-ID: <1533967213.63.0.56676864532.issue34333@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c614121224a5a81d958643471720645b1cb3166e by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-34333: Fix %-formatting in Path.with_suffix() (GH-8663)
https://github.com/python/cpython/commit/c614121224a5a81d958643471720645b1cb3166e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34333>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:00:36 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:00:36 +0000
Subject: [issue34333] Path.with_suffix() raises TypeError when doing
 %-formatting
In-Reply-To: <1533330187.01.0.56676864532.issue34333@psf.upfronthosting.co.za>
Message-ID: <1533967236.33.0.56676864532.issue34333@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34333>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:05:06 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:05:06 +0000
Subject: [issue9372] pulldom.DOMEventStream.__getitem__ is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1533967506.89.0.56676864532.issue9372@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 84a13fbda0d79789e3c9efcc9f64752261ce1e8d by Berker Peksag in branch 'master':
bpo-9372: Deprecate several __getitem__ methods (GH-8609)
https://github.com/python/cpython/commit/84a13fbda0d79789e3c9efcc9f64752261ce1e8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9372>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:05:27 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:05:27 +0000
Subject: [issue9372] pulldom.DOMEventStream.__getitem__ is broken
In-Reply-To: <1279976693.98.0.219854761696.issue9372@psf.upfronthosting.co.za>
Message-ID: <1533967527.28.0.56676864532.issue9372@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9372>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:15:46 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:15:46 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1533968146.1.0.56676864532.issue31908@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c8b0dbc4928a1fe4bd5abebd810b6849374c7af3 by Berker Peksag in branch 'master':
bpo-26818: Add a test to make sure the bug is fixed (GH-8664)
https://github.com/python/cpython/commit/c8b0dbc4928a1fe4bd5abebd810b6849374c7af3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:15:46 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:15:46 +0000
Subject: [issue26818] trace CLI doesn't respect -s option
In-Reply-To: <1461248919.65.0.631004346458.issue26818@psf.upfronthosting.co.za>
Message-ID: <1533968146.51.0.902498594338.issue26818@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c8b0dbc4928a1fe4bd5abebd810b6849374c7af3 by Berker Peksag in branch 'master':
bpo-26818: Add a test to make sure the bug is fixed (GH-8664)
https://github.com/python/cpython/commit/c8b0dbc4928a1fe4bd5abebd810b6849374c7af3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26818>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:16:03 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 06:16:03 +0000
Subject: [issue26818] trace CLI doesn't respect -s option
In-Reply-To: <1461248919.65.0.631004346458.issue26818@psf.upfronthosting.co.za>
Message-ID: <1533968163.24.0.56676864532.issue26818@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8218

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26818>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:16:03 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 06:16:03 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1533968163.34.0.665841612001.issue31908@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8219

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:28:37 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:28:37 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1533968917.71.0.56676864532.issue31908@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 8fc21c80af73226de875886132e0c32a4ffb32c5 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-26818: Add a test to make sure the bug is fixed (GH-8664)
https://github.com/python/cpython/commit/8fc21c80af73226de875886132e0c32a4ffb32c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:28:37 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:28:37 +0000
Subject: [issue26818] trace CLI doesn't respect -s option
In-Reply-To: <1461248919.65.0.631004346458.issue26818@psf.upfronthosting.co.za>
Message-ID: <1533968917.95.0.902498594338.issue26818@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 8fc21c80af73226de875886132e0c32a4ffb32c5 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-26818: Add a test to make sure the bug is fixed (GH-8664)
https://github.com/python/cpython/commit/8fc21c80af73226de875886132e0c32a4ffb32c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26818>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:29:00 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 11 Aug 2018 06:29:00 +0000
Subject: [issue26818] trace CLI doesn't respect -s option
In-Reply-To: <1461248919.65.0.631004346458.issue26818@psf.upfronthosting.co.za>
Message-ID: <1533968940.29.0.56676864532.issue26818@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26818>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:41:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Aug 2018 06:41:38 +0000
Subject: [issue34377] Update valgrind suppressions
In-Reply-To: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>
Message-ID: <1533969698.01.0.56676864532.issue34377@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset db6075ab3aa44f69c13c4a169806d08596d25003 by Benjamin Peterson (Paul Price) in branch 'master':
closes bpo-34377: Update Valgrind suppressions. (GH-8729)
https://github.com/python/cpython/commit/db6075ab3aa44f69c13c4a169806d08596d25003


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:41:56 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 06:41:56 +0000
Subject: [issue34377] Update valgrind suppressions
In-Reply-To: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>
Message-ID: <1533969716.02.0.56676864532.issue34377@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Sat Aug 11 02:42:04 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 06:42:04 +0000
Subject: [issue34377] Update valgrind suppressions
In-Reply-To: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>
Message-ID: <1533969724.03.0.56676864532.issue34377@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8221

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Sat Aug 11 03:29:35 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 07:29:35 +0000
Subject: [issue34377] Update valgrind suppressions
In-Reply-To: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>
Message-ID: <1533972575.4.0.56676864532.issue34377@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 39c1253bd12d253d8d6d009a1ee1c3729c5ebde4 by Miss Islington (bot) in branch '3.7':
closes bpo-34377: Update Valgrind suppressions. (GH-8729)
https://github.com/python/cpython/commit/39c1253bd12d253d8d6d009a1ee1c3729c5ebde4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Sat Aug 11 03:34:04 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 11 Aug 2018 07:34:04 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533972844.96.0.56676864532.issue34379@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 9e840848510d20e644a19c723b803877377d3765 by INADA Naoki (Evan Allrich) in branch 'master':
bpo-34379: Doc: Move note for json.dump (GH-8730)
https://github.com/python/cpython/commit/9e840848510d20e644a19c723b803877377d3765


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Sat Aug 11 03:34:20 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 07:34:20 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533972860.86.0.56676864532.issue34379@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Sat Aug 11 03:34:26 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 07:34:26 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533972866.71.0.56676864532.issue34379@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8223

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Sat Aug 11 04:02:11 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Aug 2018 08:02:11 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533974531.26.0.56676864532.issue34379@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6b145085225d4b114b4422f6d3c6e859e75b97d7 by Miss Islington (bot) in branch '3.7':
bpo-34379: Doc: Move note for json.dump (GH-8730)
https://github.com/python/cpython/commit/6b145085225d4b114b4422f6d3c6e859e75b97d7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Sat Aug 11 05:13:10 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 11 Aug 2018 09:13:10 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533978790.5.0.56676864532.issue34379@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset eb6ed12f486f184cb00fc35662d012dbb1f30d2e by INADA Naoki (Miss Islington (bot)) in branch '3.6':
bpo-34379: Doc: Move note for json.dump (GH-8730)
https://github.com/python/cpython/commit/eb6ed12f486f184cb00fc35662d012dbb1f30d2e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Sat Aug 11 05:13:33 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 11 Aug 2018 09:13:33 +0000
Subject: [issue34379] Move note about repeated calls to json.dump using the
 same fp to the json.dump section
In-Reply-To: <1533939019.03.0.56676864532.issue34379@psf.upfronthosting.co.za>
Message-ID: <1533978813.96.0.56676864532.issue34379@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34379>
_______________________________________

From report at bugs.python.org  Sat Aug 11 05:22:13 2018
From: report at bugs.python.org (Steven Silvester)
Date: Sat, 11 Aug 2018 09:22:13 +0000
Subject: [issue34380] Relax Restrictions on await?
Message-ID: <1533979333.92.0.56676864532.issue34380@psf.upfronthosting.co.za>


New submission from Steven Silvester <steven.silvester at gmail.com>:

When writing an `async` function, we often want to `await` a method call that may or may not be `async`.  For instance, it may be synchronous in the base class, but asynchronous in the subclass on the instance we have been given.  It would be nice for `await foo` to be a no-op if `foo` does not have an `__await__` method.  For instance, the following works in EMCAScript 2017:  `async function foo () { let bar = await 1; console.log(bar); }`.  As a workaround, we have been using `await force_async(foo.bar)`, where `force_async` is the following:

```python
async def force_async(obj):
    """Force an object to be asynchronous"""
    if hasattr(obj, '__await__'):
        return await obj
    async def inner():
        return obj
    return await inner()
```

This functionality is roughly equivalent to `gen.maybe_future` for coroutines, that is now deprecated in Tornado.  cf http://www.tornadoweb.org/en/stable/gen.html#tornado.gen.maybe_future

----------
components: asyncio
messages: 323410
nosy: Steven Silvester, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Relax Restrictions on await?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34380>
_______________________________________

From report at bugs.python.org  Sat Aug 11 05:25:15 2018
From: report at bugs.python.org (Markus Wegmann)
Date: Sat, 11 Aug 2018 09:25:15 +0000
Subject: [issue30545] Enum equality across modules: comparing objects instead
 of values
In-Reply-To: <1496379539.81.0.670964151039.issue30545@psf.upfronthosting.co.za>
Message-ID: <1533979515.26.0.56676864532.issue30545@psf.upfronthosting.co.za>


Markus Wegmann <atokulus at gmail.com> added the comment:

Hi there!

I came as well in contact with this kind of bug. Sadly, I could not replicate it with a simplified toy example.

You can experience the bug, if checkout

https://github.com/Atokulus/flora_tools/tree/56bb17ea33c910915875214e916ab73f567b3b0c

and run

`python3.7 main.py generate_code -d ..`

You find the crucial part where the identity check fails at 'radio_math.py:102' in function `get_message_toa`. The program then fails, due to the wrong program flow.

`
C:\Users\marku\AppData\Local\Programs\Python\Python37\python.exe C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py generate_code -d C:\Users\marku\Documents\flora
Traceback (most recent call last):
  File "C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py", line 110, in <module>
    main()
  File "C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py", line 104, in main
    generate_code(args.path)
  File "C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py", line 58, in generate_code
    code_gen = CodeGen(flora_path)
  File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 37, in __init__
    self.generate_all()
  File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 40, in generate_all
    self.generate_radio_constants()
  File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 72, in generate_radio_constants
    radio_toas.append([math.get_message_toa(payload) for payload in payloads])
  File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 72, in <listcomp>
    radio_toas.append([math.get_message_toa(payload) for payload in payloads])
  File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\radio_math.py", line 130, in get_message_toa
    ) / self.configuration.bitrate
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

Process finished with exit code 1
`

In the appendix, you find a toy project with similar structure, which in contrast to `flora_tools` works flawlessly.

I hope there is somebody out there with a little more experience in spotting the cause. If there is a bug in Python or CPython, it might have quite a security & safety impact.

Meanwhile I will hotfix my program by comparing the unerlying enum values.

Best regards
Atokulus

----------
nosy: +Markus Wegmann
Added file: https://bugs.python.org/file47747/enum_bug-flawless_example.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30545>
_______________________________________

From report at bugs.python.org  Sat Aug 11 05:42:16 2018
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 11 Aug 2018 09:42:16 +0000
Subject: [issue30271] Make sqlite3 statement cache optional
In-Reply-To: <1493924630.07.0.362744800273.issue30271@psf.upfronthosting.co.za>
Message-ID: <1533980536.49.0.56676864532.issue30271@psf.upfronthosting.co.za>


Aviv Palivoda <palaviv at gmail.com> added the comment:

I don't have any specific use case for making the statement cache optional. I expected that by changing the cache size to 0 there will be no statement cache. I think that this is a common assumption as can be seen in https://github.com/ghaering/pysqlite/issues/126#issue-346189937.

rogerbinns did give a use case where we would like to disable the statement cache in https://github.com/ghaering/pysqlite/issues/126#issuecomment-410030910. I think that statement cache should be disable implicitly in that case as you suggest. The code change will be very similar and I do believe we should allow the user to disable the cache. I will be happy to open a new PR once this is merged that will disable the statement cache implicitly when calling `set_authorizer()`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30271>
_______________________________________

From report at bugs.python.org  Sat Aug 11 05:43:13 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 11 Aug 2018 09:43:13 +0000
Subject: [issue34381] Make tests with outbound connection optional
Message-ID: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

I am currently trying investigate tests failures on HP-UX to port some engineering applications away from Fortran to Python, but a bunch of tests require outbound connection which I do not have. I do have an HTTP proxy only.

Please add something to TESTOPTS, e.g., '-o' (offline) to skip test. I'd like to focus on the real test failures.

----------
components: Tests
messages: 323413
nosy: michael-o
priority: normal
severity: normal
status: open
title: Make tests with outbound connection optional
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Sat Aug 11 08:31:06 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 11 Aug 2018 12:31:06 +0000
Subject: [issue34382] test_os.test_mode fails when directory base directory
 has g+s set
Message-ID: <1533990666.21.0.56676864532.issue34382@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

test_mode assumes that the SGID bit is not set in the parent directory. If it is set the assertEqual() tests fail.

This PR checks the mode of 'base' to see if the SGID bit is set, or not, and compares results accordingly.

Back-porting requested.

----------
components: Tests
messages: 323414
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_os.test_mode fails when directory base directory has g+s set
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34382>
_______________________________________

From report at bugs.python.org  Sat Aug 11 08:37:19 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 11 Aug 2018 12:37:19 +0000
Subject: [issue34382] test_os.test_mode fails when directory base directory
 has g+s set
In-Reply-To: <1533990666.21.0.56676864532.issue34382@psf.upfronthosting.co.za>
Message-ID: <1533991039.4.0.56676864532.issue34382@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8224
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34382>
_______________________________________

From report at bugs.python.org  Sat Aug 11 09:12:11 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 11 Aug 2018 13:12:11 +0000
Subject: [issue34151] use malloc() for better performance of some list
 operations
In-Reply-To: <1531935109.04.0.56676864532.issue34151@psf.upfronthosting.co.za>
Message-ID: <1533993131.23.0.56676864532.issue34151@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 2fc46979b8c802675ca7fd51c6f2108a305001c8 by Xiang Zhang (Sergey Fedoseev) in branch 'master':
bpo-34151: Improve performance of some list operations (GH-8332)
https://github.com/python/cpython/commit/2fc46979b8c802675ca7fd51c6f2108a305001c8


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34151>
_______________________________________

From report at bugs.python.org  Sat Aug 11 09:14:26 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 11 Aug 2018 13:14:26 +0000
Subject: [issue34151] use malloc() for better performance of some list
 operations
In-Reply-To: <1531935109.04.0.56676864532.issue34151@psf.upfronthosting.co.za>
Message-ID: <1533993266.2.0.56676864532.issue34151@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34151>
_______________________________________

From report at bugs.python.org  Sat Aug 11 10:58:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 11 Aug 2018 14:58:55 +0000
Subject: [issue34380] Relax Restrictions on await?
In-Reply-To: <1533979333.92.0.56676864532.issue34380@psf.upfronthosting.co.za>
Message-ID: <1533999535.88.0.56676864532.issue34380@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This isn't something we want to do in Python.  We have a dynamic but strict type system. 1 + '1' is an error in Python, but works just fine in JavaScript.  Likewise, in 'await foo' foo is expected to be an awaitable in Python and not anything else.  This has been discussed multiple times during PEP 492 approval process.

I've been beaten myself by lose semantics of await in JS by awaiting a function that returned null?a simple bug that turned out to be a nightmare to identify in a complex system.

So unfortunately I have to close this one as "won't fix", sorry. Thank you for suggesting the idea though.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34380>
_______________________________________

From report at bugs.python.org  Sat Aug 11 12:27:05 2018
From: report at bugs.python.org (Steven Silvester)
Date: Sat, 11 Aug 2018 16:27:05 +0000
Subject: [issue34380] Relax Restrictions on await?
In-Reply-To: <1533979333.92.0.56676864532.issue34380@psf.upfronthosting.co.za>
Message-ID: <1534004825.61.0.56676864532.issue34380@psf.upfronthosting.co.za>


Steven Silvester <steven.silvester at gmail.com> added the comment:

Thanks for your consideration and for implementing the original feature!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34380>
_______________________________________

From report at bugs.python.org  Sat Aug 11 13:31:39 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 11 Aug 2018 17:31:39 +0000
Subject: [issue30545] Enum equality across modules: comparing objects instead
 of values
In-Reply-To: <1496379539.81.0.670964151039.issue30545@psf.upfronthosting.co.za>
Message-ID: <1534008699.72.0.56676864532.issue30545@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Markus Wegmann said:
--------------------
> In the appendix, you find a toy project with similar structure, which > in contrast to `flora_tools` works flawlessly.

I appreciate your attempt to reproduce the problem, but since you weren't able to, the issue is probably somewhere else and not in Enum.

> TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

Your Enum example in flawless is not an IntEnum, so the error (unable to add an integer to None) seems entirely unrelated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30545>
_______________________________________

From report at bugs.python.org  Sat Aug 11 13:39:18 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 11 Aug 2018 17:39:18 +0000
Subject: [issue31874] [feature] runpy.run_module should mimic script launch
 behavior for sys.path
In-Reply-To: <1509026474.72.0.213398074469.issue31874@psf.upfronthosting.co.za>
Message-ID: <1534009158.41.0.56676864532.issue31874@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In [setuptools 1453](https://github.com/pypa/setuptools/issues/1453), this issue hit the project hard. Tox 3.2 changed the default invocation of pip from the script-based invocation to the runpy based implementation (python -m pip), which causes pip to be unable to uninstall the setuptools in the environment.

This use case also reveals that the heuristic of "retain '' in sys.path if the module being executed is in a subdirectory of a current directory" wouldn't address the issue, as `.tox/python/lib/python3.7/site-packages/pip/__main__.py` is in a subdirectory of the current directory, but one would still expect '' not to be in sys.path in this case.

But basing on __main__.__spec__, that would probably do what is expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31874>
_______________________________________

From report at bugs.python.org  Sat Aug 11 14:32:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 11 Aug 2018 18:32:59 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1534012379.51.0.56676864532.issue34376@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Applied in: https://mail.python.org/pipermail/python-checkins/2018-August/156572.html   Note, the BPO number was left off the checkin message.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Sat Aug 11 15:28:45 2018
From: report at bugs.python.org (Andrei)
Date: Sat, 11 Aug 2018 19:28:45 +0000
Subject: [issue34383] asyncio passes SSL certificate error to
 loop.call_exception_handler()
Message-ID: <1534015725.83.0.56676864532.issue34383@psf.upfronthosting.co.za>


New submission from Andrei <danandrei at gmail.com>:

I'm using 3.7, but it's an issue that I've found in the old github repo for 3.6.

When using asyncio, SSL certificate errors don't get suppressed.

I've tried:
- with contextlib.suppress(Exception)
- except & pass

Original ticket:
https://github.com/python/asyncio/issues/404

----------
components: asyncio
messages: 323421
nosy: DanAndrei, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio passes SSL certificate error to loop.call_exception_handler()
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34383>
_______________________________________

From report at bugs.python.org  Sat Aug 11 17:07:54 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Aug 2018 21:07:54 +0000
Subject: [issue34377] Update valgrind suppressions
In-Reply-To: <1533927265.92.0.56676864532.issue34377@psf.upfronthosting.co.za>
Message-ID: <1534021674.88.0.56676864532.issue34377@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset fe62d3664431dcd01a4421256ff700f0daab4e3c by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
closes bpo-34377: Update Valgrind suppressions. (GH-8734)
https://github.com/python/cpython/commit/fe62d3664431dcd01a4421256ff700f0daab4e3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34377>
_______________________________________

From report at bugs.python.org  Sat Aug 11 17:56:50 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 11 Aug 2018 21:56:50 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1534024610.7.0.56676864532.issue34376@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Thanks for doing the "real ulp" calc, Raymond!  It was intended to make the Kahan gimmick look better, and it succeeded ;-)  I don't personally care whether adding 10K things ends up with 50 ulp error, but to each their own.

Division can be mostly removed from scaling, but it's a bit delicate.  The obvious stab would be to multiply by 1/max instead of dividing by max.  That introduces another rounding error, but as you've already discovered this computation as a whole is relatively insensitive to rounding errors in scaling.  The real problem is that 1/max can overflow (when max is subnormal - the IEEE range isn't symmetric).

Instead a power of 2 could be used, chosen so that it and its reciprocal are both representable.  There's no particular virtue in scaling the largest value to 1.0 - the real point is to avoid spurious overflow/underflow when squaring the scaled x.  Code like the following could work.  Scaling would introduce essentially no rounding errors then.

But I bet a call to `ldexp()` is even more expensive than division on most platforms.  So it may well be slower when there are few points.

def hyp_ps(xs):
    b = max(map(abs, xs))
    _, exp = frexp(b)
    exp = -3 * exp // 4
    # scale and invscale are exact.
    # Multiplying by scale is exact, except when
    # the result becomes subnormal (in which case
    # |x| is insignifcant compared to |b|).
    # invscale isn't needed until the loop ends,
    # so the division time should overlap with the
    # loop body.
    scale = ldexp(1.0, exp) # exact
    invscale = 1.0 / scale  # exact
    # and `x * scale` is exact except for underflow
    s = fsum((x * scale)**2 for x in xs)
    return invscale * sqrt(s)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Sat Aug 11 18:11:03 2018
From: report at bugs.python.org (Martin Panter)
Date: Sat, 11 Aug 2018 22:11:03 +0000
Subject: [issue33300] Bad usage example in id() DocString
In-Reply-To: <1523995335.26.0.682650639539.issue33300@psf.upfronthosting.co.za>
Message-ID: <1534025463.8.0.56676864532.issue33300@psf.upfronthosting.co.za>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> duplicate
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33300>
_______________________________________

From report at bugs.python.org  Sat Aug 11 19:04:16 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 11 Aug 2018 23:04:16 +0000
Subject: [issue24111] Valgrind suppression file should be updated
In-Reply-To: <1430549990.4.0.860597056405.issue24111@psf.upfronthosting.co.za>
Message-ID: <1534028656.19.0.56676864532.issue24111@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

This was fixed in #34377.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24111>
_______________________________________

From report at bugs.python.org  Sat Aug 11 19:10:28 2018
From: report at bugs.python.org (Matt Pruitt)
Date: Sat, 11 Aug 2018 23:10:28 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1534029028.82.0.56676864532.issue31710@psf.upfronthosting.co.za>


Matt Pruitt <mhpruitt at outlook.com> added the comment:

Also ran into this issue while building Python in an isolated environment.  Realized that libffi is installing into the $EPREFIX/lib64 directory of our build environment.

Despite pkg-config returning the correct directory for linking libffi, it took explicitly setting LDFLAGS to the correct lib64 directory in my build process for the Python build to succeed.

I noticed from your build.log that you don't explicitly add your lib64 to your LDFLAGS.  Perhaps give that a shot?

----------
nosy: +mhpruitt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Sat Aug 11 20:21:27 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 12 Aug 2018 00:21:27 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1534033287.92.0.56676864532.issue34369@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I think this was an attempt to specify a positional-only parameter (by using square brackets), and include a default value in the signature. The usual approach in this situation is to use square brackets, but only mention the default value in the text:

control(changelist, max_events[, timeout])
. . .
The default for "timeout" is None, to wait forever.

In Issue 13386 Ezio suggested against showing both square brackets and a default value, and I agree.

Berker: your "select" and "poll" cases all include the PEP 457 slash "/" notation, which was supposed to indicate positional-only parameters. See Issue 21314 about explaining this notation in the documentation somewhere.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, martin.panter
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Sat Aug 11 23:41:11 2018
From: report at bugs.python.org (Girts Folkmanis)
Date: Sun, 12 Aug 2018 03:41:11 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
Message-ID: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>


New submission from Girts Folkmanis <girts.folkmanis at gmail.com>:

Documentation for os.readlink says "Changed in version 3.6: Accepts a path-like object.". This works fine on macOS, but blows up on Windows:

Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:06:47) [MSC v.1914 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import pathlib
>>> os.readlink(pathlib.Path('foo'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: readlink() argument 1 must be str, not WindowsPath

----------
components: Library (Lib)
messages: 323427
nosy: girtsf
priority: normal
severity: normal
status: open
title: os.readlink does not accept pathlib.Path on Windows
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Sun Aug 12 00:56:09 2018
From: report at bugs.python.org (John Nelson)
Date: Sun, 12 Aug 2018 04:56:09 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1534049769.87.0.56676864532.issue34323@psf.upfronthosting.co.za>


John Nelson <john at moriancumer.net> added the comment:

Python 3.5.4 (v3.5.4:3f56838, Aug  8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform, sys
>>> platform.win32_ver()
('2012ServerR2', '6.3.9600', 'SP0', 'Multiprocessor Free')
>>> sys.version_info
sys.version_info(major=3, minor=5, micro=4, releaselevel='final', serial=0)

----------
nosy: +John Nelson2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Sun Aug 12 01:10:35 2018
From: report at bugs.python.org (LarBob Doomer)
Date: Sun, 12 Aug 2018 05:10:35 +0000
Subject: [issue34385] Failed to build these modules: _ctypes on Solaris 10
Message-ID: <1534050635.26.0.56676864532.issue34385@psf.upfronthosting.co.za>


New submission from LarBob Doomer <larbobdoomer at gmail.com>:

I am compiling with GNU binutils 2.24, GCC 5.5.0, GNU make 4.2.1. 

When attempting to build 3.6.x, the build is successful except for the fact that the _ctypes module fails to build. This of course causes the install to fail.

Failed to build these modules:
_ctypes

I do have libffi-dev installed through OpenCSW.

----------
components: ctypes
messages: 323429
nosy: LarBob Doomer
priority: normal
severity: normal
status: open
title: Failed to build these modules: _ctypes on Solaris 10
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34385>
_______________________________________

From report at bugs.python.org  Sun Aug 12 01:36:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 12 Aug 2018 05:36:51 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534052211.88.0.56676864532.issue34384@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
pull_requests: +8225
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Sun Aug 12 01:39:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Aug 2018 05:39:39 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1534052379.75.0.56676864532.issue34376@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think that in most real cases (unless max is too large or too small) we can get rid of scaling at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Sun Aug 12 01:54:20 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 12 Aug 2018 05:54:20 +0000
Subject: [issue22602] UTF-7 codec decodes ill-formed sequences starting with
 "+"
In-Reply-To: <1412945083.94.0.341902119278.issue22602@psf.upfronthosting.co.za>
Message-ID: <1534053260.34.0.56676864532.issue22602@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8226
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22602>
_______________________________________

From report at bugs.python.org  Sun Aug 12 01:57:56 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 12 Aug 2018 05:57:56 +0000
Subject: [issue22602] UTF-7 codec decodes ill-formed sequences starting with
 "+"
In-Reply-To: <1412945083.94.0.341902119278.issue22602@psf.upfronthosting.co.za>
Message-ID: <1534053476.71.0.56676864532.issue22602@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

This was also mentioned in #24848.

----------
nosy: +ZackerySpytz
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22602>
_______________________________________

From report at bugs.python.org  Sun Aug 12 02:33:10 2018
From: report at bugs.python.org (Markus Wegmann)
Date: Sun, 12 Aug 2018 06:33:10 +0000
Subject: [issue30545] Enum equality across modules: comparing objects instead
 of values
In-Reply-To: <1496379539.81.0.670964151039.issue30545@psf.upfronthosting.co.za>
Message-ID: <1534055590.55.0.56676864532.issue30545@psf.upfronthosting.co.za>


Markus Wegmann <atokulus at gmail.com> added the comment:

Hi Ethan

> Your Enum example in flawless is not an IntEnum, so the error (unable to add an integer to None) seems entirely unrelated.

The TypeError is just a consequence of the faulty Enum identity comparison some lines before. I mentioned the TypeError so you can verify whether your Python version takes the same program flow.


I also did further research. The Enum's are definitely different regarding the module path -- the instance comparison will therefore return False. I checked __module__ + __qualname__:

`flora_tools.radio_configuration.RadioModem.LORA`

vs.

`radio_configuration.RadioModem.LORA`


The cause is the wrong import statement in `flora_tools/codegen/codegen.py`:

`from radio_configuration import RadioConfiguration,\ 
                                RADIO_CONFIGURATIONS`

It should have been

`from flora_tools.radio_configuration import RadioConfiguration\
                                            RADIO_CONFIGURATIONS`

The real deal here is why I was allowed to directly import from `radio_configuration` in the first place. I'm not allowed to directly import a submodule in the toy project without the proper root module name appended. Maybe I don't see the big picture, or have some crude options/monkey_patching enabled.

Nevertheless, the behaviour regarding Enum comparisons and different import paths seems to me quite misleading.

Best regards
Atokulus

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30545>
_______________________________________

From report at bugs.python.org  Sun Aug 12 02:36:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Aug 2018 06:36:18 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534055778.43.0.56676864532.issue34384@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Sun Aug 12 02:52:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Aug 2018 06:52:05 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534056725.17.0.56676864532.issue34384@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Windows
nosy: +berker.peksag, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Sun Aug 12 03:10:06 2018
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 12 Aug 2018 07:10:06 +0000
Subject: [issue30545] Enum equality across modules: comparing objects instead
 of values
In-Reply-To: <1496379539.81.0.670964151039.issue30545@psf.upfronthosting.co.za>
Message-ID: <1534057806.88.0.56676864532.issue30545@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

What you have discovered is not Enum specific, but in fact can happen with any module (as stated in my first comment in this bug report).

Maybe these SO question will help:

https://stackoverflow.com/q/2489601/208880

https://stackoverflow.com/a/4798648/208880

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30545>
_______________________________________

From report at bugs.python.org  Sun Aug 12 03:43:30 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Aug 2018 07:43:30 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1534059810.59.0.56676864532.issue34376@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Could we maybe make an educated guess based on absmin and absmax whether scaling is needed or not?

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Sun Aug 12 03:50:05 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 12 Aug 2018 07:50:05 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1534060205.77.0.56676864532.issue34369@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

In Python 3.8 this will have already been fixed (thanks to the recent conversion of the select module to use Argument Clinic); see below output from a recent build from the master branch.

Given that, is this worth fixing on 2.7 and <3.8?


Help on built-in function control:

control(changelist, maxevents, timeout=None, /) method of select.kqueue instance
    Calls the kernel kevent function.

    changelist
      Must be an iterable of kevent objects describing the changes to be made
      to the kernel's watch list or None.
    maxevents
      The maximum number of events that the kernel will return.
    timeout
      The maximum time to wait in seconds, or else None to wait forever.
      This accepts floats for smaller timeouts, too.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Sun Aug 12 05:00:30 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 12 Aug 2018 09:00:30 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1534064430.6.0.56676864532.issue21314@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I'd suggest adding a FAQ entry to the "Core Language" section at https://docs.python.org/3/faq/programming.html#core-language then we can link to it from the places (except pydoc docs) Zachary listed in msg223893.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Sun Aug 12 05:20:19 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 12 Aug 2018 09:20:19 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534065619.12.0.56676864532.issue30411@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +patch
pull_requests: +8227
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Sun Aug 12 05:36:13 2018
From: report at bugs.python.org (Artem Golubin)
Date: Sun, 12 Aug 2018 09:36:13 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
Message-ID: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>


New submission from Artem Golubin <me at rushter.com>:

Python provides an ability to intern strings (sys.intern). It would be useful to expose a read-only dictionary of interned strings to the Python users so we can see what kind of strings are interned. 

It takes minimal changes since internally it's just a dictionary. Is this worth adding to the sys module?

----------
components: Interpreter Core
messages: 323437
nosy: rushter
priority: normal
severity: normal
status: open
title: Expose a dictionary of interned strings in sys module
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Sun Aug 12 05:56:15 2018
From: report at bugs.python.org (Martin Panter)
Date: Sun, 12 Aug 2018 09:56:15 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1534067775.72.0.56676864532.issue34369@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Even in 3.8, the main documentation is not fixed: https://docs.python.org/dev/library/select.html#kqueue-objects

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Sun Aug 12 06:21:54 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 12 Aug 2018 10:21:54 +0000
Subject: [issue34369] kqueue.control() documentation and implementation
 mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1534069314.36.0.56676864532.issue34369@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

We can just remove the "=None" in the docs for select.kqueue.control() to conform with the rest of that doc.

We don't use the PEP 457 slash notation in the docs for select (or perhaps at all?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34369>
_______________________________________

From report at bugs.python.org  Sun Aug 12 06:44:04 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 12 Aug 2018 10:44:04 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
In-Reply-To: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>
Message-ID: <1534070644.41.0.56676864532.issue34386@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Could you explain why this would be useful?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Sun Aug 12 07:46:09 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 12 Aug 2018 11:46:09 +0000
Subject: [issue34213] Frozen dataclass __init__ fails for "object" property"
In-Reply-To: <1532457260.21.0.56676864532.issue34213@psf.upfronthosting.co.za>
Message-ID: <1534074369.64.0.56676864532.issue34213@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 4d12e4dc28b7c782c368bae2e8fd3815167ed37d by Eric V. Smith (Vadim Pushtaev) in branch 'master':
bpo-34213: Allow dataclasses to work with a field named 'object'. (GH-8452)
https://github.com/python/cpython/commit/4d12e4dc28b7c782c368bae2e8fd3815167ed37d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34213>
_______________________________________

From report at bugs.python.org  Sun Aug 12 07:46:29 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Aug 2018 11:46:29 +0000
Subject: [issue34213] Frozen dataclass __init__ fails for "object" property"
In-Reply-To: <1532457260.21.0.56676864532.issue34213@psf.upfronthosting.co.za>
Message-ID: <1534074389.56.0.56676864532.issue34213@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8228

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34213>
_______________________________________

From report at bugs.python.org  Sun Aug 12 07:55:20 2018
From: report at bugs.python.org (Kamyar Inanloo)
Date: Sun, 12 Aug 2018 11:55:20 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy!
Message-ID: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>


New submission from Kamyar Inanloo <kamyar1979 at gmail.com>:

When using del or delattr on an instance of dataclass, attribute does not get deleted truly! using vars or getattr still returns the deleted attribute just using delattr again raises error!

----------
components: Argument Clinic
messages: 323442
nosy: Kamyar Inanloo, larry
priority: normal
severity: normal
status: open
title: Deletion of attributes in dataclass is buggy!
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Sun Aug 12 08:36:17 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 12 Aug 2018 12:36:17 +0000
Subject: [issue24076] sum() several times slower on Python 3 64-bit
In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za>
Message-ID: <1534077377.67.0.56676864532.issue24076@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

FWIW, a PGO build of Py3.7 is now about 20% *faster* here than my Ubuntu 16/04 system Python 2.7, and for some (probably unrelated) reason, the system Python 3.5 is another 2% faster on my side.

IMHO, the only other thing that seems obvious to try would be to inline the unpacking of single digit PyLongs into sum(). I attached a simple patch that does that, in case someone wants to test it out. For non-PGO builds, it's about 17% faster for me. Didn't take the time to benchmark PGO builds with it.

----------
versions:  -Python 3.5
Added file: https://bugs.python.org/file47748/unpack_single_digits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24076>
_______________________________________

From report at bugs.python.org  Sun Aug 12 08:44:11 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Aug 2018 12:44:11 +0000
Subject: [issue24076] sum() several times slower on Python 3 64-bit
In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za>
Message-ID: <1534077851.38.0.56676864532.issue24076@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24076>
_______________________________________

From report at bugs.python.org  Sun Aug 12 10:15:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Aug 2018 14:15:40 +0000
Subject: [issue34213] Frozen dataclass __init__ fails for "object" property"
In-Reply-To: <1532457260.21.0.56676864532.issue34213@psf.upfronthosting.co.za>
Message-ID: <1534083340.02.0.56676864532.issue34213@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8229

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34213>
_______________________________________

From report at bugs.python.org  Sun Aug 12 10:25:07 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 12 Aug 2018 14:25:07 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy!
In-Reply-To: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>
Message-ID: <1534083907.65.0.56676864532.issue34387@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib) -Argument Clinic
nosy: +eric.smith -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Sun Aug 12 11:04:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 12 Aug 2018 15:04:29 +0000
Subject: [issue22602] UTF-7 codec decodes ill-formed sequences starting with
 "+"
In-Reply-To: <1412945083.94.0.341902119278.issue22602@psf.upfronthosting.co.za>
Message-ID: <1534086269.99.0.56676864532.issue22602@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about a "+" character followed immediately by the end of the bytestring?

>>> b'+'.decode('utf-7')
''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22602>
_______________________________________

From report at bugs.python.org  Sun Aug 12 11:54:57 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 15:54:57 +0000
Subject: [issue30871] Add test.pythoninfo
In-Reply-To: <1499438915.55.0.904149842261.issue30871@psf.upfronthosting.co.za>
Message-ID: <1534089297.17.0.56676864532.issue30871@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

pythoninfo is failing on several buildbots:


https://buildbot.python.org/all/#/builders/102/builds/55
https://buildbot.python.org/all/#/builders/79/builds/237
https://buildbot.python.org/all/#/builders/112/builds/161
https://buildbot.python.org/all/#/builders/118/builds/164
https://buildbot.python.org/all/#/builders/56/builds/105
https://buildbot.python.org/all/#/builders/18/builds/109

Example error:

./python -m test.pythoninfo
ERROR: collect_gdb() failed
Traceback (most recent call last):
  File "/usr/home/buildbot/python/2.7.koobs-freebsd-current.nondebug/build/Lib/test/pythoninfo.py", line 561, in collect_info
    collect_func(info_add)
  File "/usr/home/buildbot/python/2.7.koobs-freebsd-current.nondebug/build/Lib/test/pythoninfo.py", line 300, in collect_gdb
    version = version.splitlines()[0]
IndexError: list index out of range

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30871>
_______________________________________

From report at bugs.python.org  Sun Aug 12 11:55:01 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 15:55:01 +0000
Subject: [issue30871] Add test.pythoninfo
In-Reply-To: <1499438915.55.0.904149842261.issue30871@psf.upfronthosting.co.za>
Message-ID: <1534089301.27.0.56676864532.issue30871@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30871>
_______________________________________

From report at bugs.python.org  Sun Aug 12 11:58:55 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 15:58:55 +0000
Subject: [issue34388] collect_gdb fails for test.pythoninfo in several
 buildbots
Message-ID: <1534089535.5.0.56676864532.issue34388@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

collect_gdb fails for the test.pythoninfo step in several buildbots:

https://buildbot.python.org/all/#/builders/102/builds/55
https://buildbot.python.org/all/#/builders/79/builds/237
https://buildbot.python.org/all/#/builders/112/builds/161
https://buildbot.python.org/all/#/builders/118/builds/164
https://buildbot.python.org/all/#/builders/56/builds/105
https://buildbot.python.org/all/#/builders/18/builds/109

Example error:

./python -m test.pythoninfo
ERROR: collect_gdb() failed
Traceback (most recent call last):
  File "/usr/home/buildbot/python/2.7.koobs-freebsd-current.nondebug/build/Lib/test/pythoninfo.py", line 561, in collect_info
    collect_func(info_add)
  File "/usr/home/buildbot/python/2.7.koobs-freebsd-current.nondebug/build/Lib/test/pythoninfo.py", line 300, in collect_gdb
    version = version.splitlines()[0]
IndexError: list index out of range

----------
components: Build, Tests
messages: 323446
nosy: pablogsal
priority: normal
severity: normal
status: open
title: collect_gdb fails for test.pythoninfo in several buildbots
type: crash
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34388>
_______________________________________

From report at bugs.python.org  Sun Aug 12 11:59:59 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 15:59:59 +0000
Subject: [issue30871] Add test.pythoninfo
In-Reply-To: <1499438915.55.0.904149842261.issue30871@psf.upfronthosting.co.za>
Message-ID: <1534089599.07.0.56676864532.issue30871@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

All of these failures seems related to `collect_gdb`  I am going to open a new issue:

https://bugs.python.org/issue34388

Please, re-open this one if you think is better to have both open.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30871>
_______________________________________

From report at bugs.python.org  Sun Aug 12 12:00:26 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 16:00:26 +0000
Subject: [issue34388] collect_gdb fails for test.pythoninfo in several
 buildbots
In-Reply-To: <1534089535.5.0.56676864532.issue34388@psf.upfronthosting.co.za>
Message-ID: <1534089626.17.0.56676864532.issue34388@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The origin of this can be related to https://bugs.python.org/issue30871

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34388>
_______________________________________

From report at bugs.python.org  Sun Aug 12 12:00:36 2018
From: report at bugs.python.org (Tim Peters)
Date: Sun, 12 Aug 2018 16:00:36 +0000
Subject: [issue34376] Improve accuracy of math.hypot() and math.dist()
In-Reply-To: <1533925198.56.0.56676864532.issue34376@psf.upfronthosting.co.za>
Message-ID: <1534089636.37.0.56676864532.issue34376@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Sure, if we make more assumptions.  For 754 doubles, e.g., scaling isn't needed if `1e-100 < absmax < 1e100` unless there are a truly ludicrous number of points.  Because, if that holds, the true sum is between 1e-200 and number_of_points*1e200, both far from being near trouble.

Then the summation loop gets mostly duplicated (with and without scaling), a platform-dependent assumption is introduced, and we need two test-and-branches to determine which to run.  In the common two-argument cases, it saves one division in return.

Note that without the current form of scaling, we lose the guarantee that the sum is exact when all the arguments are the same (because they're all scaled to exactly 1.0 then, but in general each x*x loses half the product bits without scaling).  I don't care about that myself, but Serhiy seems to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34376>
_______________________________________

From report at bugs.python.org  Sun Aug 12 12:10:45 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 16:10:45 +0000
Subject: [issue34388] collect_gdb fails for test.pythoninfo in several AMD64
 FreeBSD buildbots
In-Reply-To: <1534089535.5.0.56676864532.issue34388@psf.upfronthosting.co.za>
Message-ID: <1534090245.74.0.56676864532.issue34388@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
title: collect_gdb fails for test.pythoninfo in several buildbots -> collect_gdb fails for test.pythoninfo in several AMD64 FreeBSD buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34388>
_______________________________________

From report at bugs.python.org  Sun Aug 12 12:32:43 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Aug 2018 16:32:43 +0000
Subject: [issue34388] collect_gdb fails for test.pythoninfo in several AMD64
 FreeBSD buildbots
In-Reply-To: <1534089535.5.0.56676864532.issue34388@psf.upfronthosting.co.za>
Message-ID: <1534091563.6.0.56676864532.issue34388@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34388>
_______________________________________

From report at bugs.python.org  Sun Aug 12 13:01:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Aug 2018 17:01:08 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
In-Reply-To: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>
Message-ID: <1534093268.09.0.56676864532.issue34386@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I wouldn't want a user to be able to mutate the dictionary directly (otherwise, non-strings could be added).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Sun Aug 12 14:41:41 2018
From: report at bugs.python.org (LarBob Doomer)
Date: Sun, 12 Aug 2018 18:41:41 +0000
Subject: [issue34385] Failed to build these modules: _ctypes on Solaris 10
In-Reply-To: <1534050635.26.0.56676864532.issue34385@psf.upfronthosting.co.za>
Message-ID: <1534099301.26.0.56676864532.issue34385@psf.upfronthosting.co.za>


LarBob Doomer <larbobdoomer at gmail.com> added the comment:

This is due to it not finding the external libffi I have.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34385>
_______________________________________

From report at bugs.python.org  Sun Aug 12 15:32:17 2018
From: report at bugs.python.org (Antony Lee)
Date: Sun, 12 Aug 2018 19:32:17 +0000
Subject: [issue34389] CPython may fail to build in the presence of a
 ~/.pydistutils.cfg
Message-ID: <1534102337.9.0.56676864532.issue34389@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

I have a ~/.pydistutils.cfg with the following contents:

    [build_ext]
    force = true
    inplace = true

(--force is useful because sometimes just comparing timestamps is insufficient to know whether a package needs to be rebuilt, e.g. in the presence of external dependencies -- and I use ccache anyways to avoid paying for excessive rebuilds; --inplace is useful as I have quite a few packages with extension modules that are editably-installed).

With this ~/.pydistutils.cfg, cpython fails to build.  For example, having checked out v3.7.0 from a git clone (otherwise clean git repo, per `git clean -xfd`),

    mkdir build && cd build && ../configure && make

ultimately results in

    <elided>

    gcc -pthread -shared build/temp.linux-x86_64-3.7/home/antony/src/extern/cpython/Modules/_ctypes/_ctypes.o build/temp.linux-x86_64-3.7/home/antony/src/extern/cpython/Modules/_ctypes/callbacks.o build/temp.linux-x86_64-3.7/home/antony/src/extern/cpython/Modules/_ctypes/callproc.o build/temp.linux-x86_64-3.7/home/antony/src/extern/cpython/Modules/_ctypes/stgdict.o build/temp.linux-x86_64-3.7/home/antony/src/extern/cpython/Modules/_ctypes/cfield.o -L/usr/local/lib -lffi -ldl -o /home/antony/src/extern/cpython/build/_ctypes.cpython-37m-x86_64-linux-gnu.so
    *** WARNING: renaming "_struct" since importing it failed: build/lib.linux-x86_64-3.7/_struct.cpython-37m-x86_64-linux-gnu.so: cannot open shared object file: No such file or directory
    Traceback (most recent call last):
    File "../setup.py", line 442, in check_extension_import
        importlib._bootstrap._load(spec)
    File "<frozen importlib._bootstrap>", line 696, in _load
    File "<frozen importlib._bootstrap>", line 670, in _load_unlocked
    File "<frozen importlib._bootstrap>", line 583, in module_from_spec
    File "<frozen importlib._bootstrap_external>", line 1043, in create_module
    File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
    ImportError: build/lib.linux-x86_64-3.7/_struct.cpython-37m-x86_64-linux-gnu.so: cannot open shared object file: No such file or directory

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
    File "../setup.py", line 2363, in <module>
        main()
    File "../setup.py", line 2358, in main
        "Tools/scripts/2to3", "Tools/scripts/pyvenv"]
    File "/home/antony/src/extern/cpython/Lib/distutils/core.py", line 148, in setup
        dist.run_commands()
    File "/home/antony/src/extern/cpython/Lib/distutils/dist.py", line 966, in run_commands
        self.run_command(cmd)
    File "/home/antony/src/extern/cpython/Lib/distutils/dist.py", line 985, in run_command
        cmd_obj.run()
    File "/home/antony/src/extern/cpython/Lib/distutils/command/build.py", line 135, in run
        self.run_command(cmd_name)
    File "/home/antony/src/extern/cpython/Lib/distutils/cmd.py", line 313, in run_command
        self.distribution.run_command(command)
    File "/home/antony/src/extern/cpython/Lib/distutils/dist.py", line 985, in run_command
        cmd_obj.run()
    File "/home/antony/src/extern/cpython/Lib/distutils/command/build_ext.py", line 339, in run
        self.build_extensions()
    File "../setup.py", line 308, in build_extensions
        self.check_extension_import(ext)
    File "../setup.py", line 447, in check_extension_import
        assert not self.inplace
    AssertionError
    make: *** [Makefile:618: sharedmods] Error 1

Removing the ~/.pydistutils.cfg fixes the issue and leads to a successful build.

I think(?) CPython's build system should essentially make sure that distutils behaves as if `--no-user-cfg` was in effect.  Or at least the limitation should be documented, but it's not very practical to have to temporarily rename an existing ~/.pydistutils.cfg whenever building CPython.  See also https://bugs.python.org/issue9309, perhaps.

----------
components: Build
messages: 323452
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: CPython may fail to build in the presence of a ~/.pydistutils.cfg
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34389>
_______________________________________

From report at bugs.python.org  Sun Aug 12 15:41:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Aug 2018 19:41:27 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy!
In-Reply-To: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>
Message-ID: <1534102887.72.0.56676864532.issue34387@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Sun Aug 12 16:09:33 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 12 Aug 2018 20:09:33 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
In-Reply-To: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>
Message-ID: <1534104573.03.0.56676864532.issue34386@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Another reason for not wanting write access to the sys.intern dictionary is that this dictionary does not own references to its keys and values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Sun Aug 12 16:14:01 2018
From: report at bugs.python.org (Kamyar Inanloo)
Date: Sun, 12 Aug 2018 20:14:01 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy!
In-Reply-To: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>
Message-ID: <1534104841.09.0.56676864532.issue34387@psf.upfronthosting.co.za>


Kamyar Inanloo <kamyar1979 at gmail.com> added the comment:

Actually it just sets the attribute to its default value, instead of removing it from the instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Sun Aug 12 16:33:06 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 12 Aug 2018 20:33:06 +0000
Subject: [issue24111] Valgrind suppression file should be updated
In-Reply-To: <1430549990.4.0.860597056405.issue24111@psf.upfronthosting.co.za>
Message-ID: <1534105986.51.0.56676864532.issue24111@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Update valgrind suppressions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24111>
_______________________________________

From report at bugs.python.org  Sun Aug 12 16:57:51 2018
From: report at bugs.python.org (Artem Golubin)
Date: Sun, 12 Aug 2018 20:57:51 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
In-Reply-To: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>
Message-ID: <1534107471.92.0.56676864532.issue34386@psf.upfronthosting.co.za>


Artem Golubin <me at rushter.com> added the comment:

Thank you, I agree. I can't come up with practical use cases other than my curiosity. 

Is it possible to somehow expose the dictionary in the debug build of Python? Currently, there is no way to access it from the interpreter even with ctypes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Sun Aug 12 19:10:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 12 Aug 2018 23:10:00 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1534115400.01.0.56676864532.issue34370@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka, wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Sun Aug 12 19:37:06 2018
From: report at bugs.python.org (Lisa Roach)
Date: Sun, 12 Aug 2018 23:37:06 +0000
Subject: [issue33073] Add as_integer_ratio() to int() objects
In-Reply-To: <1520976305.18.0.467229070634.issue33073@psf.upfronthosting.co.za>
Message-ID: <1534117026.88.0.56676864532.issue33073@psf.upfronthosting.co.za>


Change by Lisa Roach <lisaroach14 at gmail.com>:


----------
keywords: +patch
pull_requests: +8230
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33073>
_______________________________________

From report at bugs.python.org  Sun Aug 12 22:28:40 2018
From: report at bugs.python.org (Greg Toombs)
Date: Mon, 13 Aug 2018 02:28:40 +0000
Subject: [issue4508] distutils compiler not handling spaces in path to
 output/src files
In-Reply-To: <1228341537.43.0.522254260997.issue4508@psf.upfronthosting.co.za>
Message-ID: <1534127320.2.0.56676864532.issue4508@psf.upfronthosting.co.za>


Greg Toombs <gtoombs at lakeheadu.ca> added the comment:

Confirmed still broken in 3.6.3.

I ran into this when running CFFI. It does very wrong things with the path to cl.exe and include files with path spaces.

My workaround is to monkeypatch distutils.ccompiler.gen_preprocess_options such that include paths are formed as -I"path" and not -Ipath; and to monkeypatch distutils.spawn._nt_quote_args so that it leaves all of the arguments unquoted except the first arg (path to cl.exe), which I only got working by using tilde-mangled short names.

----------
nosy: +Greg Toombs
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4508>
_______________________________________

From report at bugs.python.org  Sun Aug 12 23:24:43 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 13 Aug 2018 03:24:43 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy!
In-Reply-To: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>
Message-ID: <1534130683.82.0.56676864532.issue34387@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I think this is just normal behavior with classes. But since you haven't shown any code, I can't tell exactly what you're doing and what you're expecting.

When providing bug reports, you need to provide:
- Exactly what code you're executing.
- Exactly what output you're seeing.
- What you expect if it's different from what you're seeing.

Please provide this in the body of a message as text, not (for example) as an attached image file.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Sun Aug 12 23:25:05 2018
From: report at bugs.python.org (Matthias Fripp)
Date: Mon, 13 Aug 2018 03:25:05 +0000
Subject: [issue34390] arparse.ArgumentParser misparses list arguments followed
 by undefined arguments
Message-ID: <1534130705.52.0.56676864532.issue34390@psf.upfronthosting.co.za>


New submission from Matthias Fripp <mfripp at gmail.com>:

The code below demonstrates this bug.

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--list-arg', nargs='+', default=[])
parser.parse_known_args(['--list-arg', 'a', '--text-arg=hello world'])

The result should be (Namespace(list_arg=['a']), ['--text-arg=hello world']), but is actually (Namespace(list_arg=['a', '--text-arg=hello world']), []). i.e., --list-arg consumes the next argument if that argument hasn't been defined and uses an equal sign and has a space in the assigned value.

Note that both of the following work correctly:

parser.parse_known_args(['--list-arg', 'a', '--text-arg', 'hello world'])
parser.parse_known_args(['--list-arg', 'a', '--text-arg=hello'])

Further, the next line should cause an error, but doesn't, due to the behavior noted above:

parser.parse_args(['--list-arg', 'a', '--text-arg=hello world'])

----------
components: Library (Lib)
messages: 323458
nosy: Matthias Fripp
priority: normal
severity: normal
status: open
title: arparse.ArgumentParser misparses list arguments followed by undefined arguments
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34390>
_______________________________________

From report at bugs.python.org  Sun Aug 12 23:32:51 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Aug 2018 03:32:51 +0000
Subject: [issue34213] Frozen dataclass __init__ fails for "object" property"
In-Reply-To: <1532457260.21.0.56676864532.issue34213@psf.upfronthosting.co.za>
Message-ID: <1534131171.11.0.56676864532.issue34213@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 32e58fc32188753d2a3604feacdf9540fe9515fb by Miss Islington (bot) in branch '3.7':
bpo-34213: Allow dataclasses to work with a field named 'object'. (GH-8452)
https://github.com/python/cpython/commit/32e58fc32188753d2a3604feacdf9540fe9515fb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34213>
_______________________________________

From report at bugs.python.org  Mon Aug 13 01:10:20 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 13 Aug 2018 05:10:20 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534137020.96.0.56676864532.issue34384@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Steve and/or Eryk, I was adding some tests for os.readlink() in PR 8740 and I noticed that os.readlink() always returns str on Windows. However, the documentation for os.readlink() says:

    If the path is a bytes object (direct or indirectly), the result will
    be a bytes object.

The question is, should I add support for bytes as part of PR 8740? And what is the best way to implement it? (e.g. use CreateFileA() if PyUnicode_Check(path.object) returns false?)

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Mon Aug 13 01:26:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 13 Aug 2018 05:26:52 +0000
Subject: [issue13837] test_shutil fails with symlinks enabled under Windows
In-Reply-To: <1327255807.39.0.63998442373.issue13837@psf.upfronthosting.co.za>
Message-ID: <1534138012.91.0.56676864532.issue13837@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Issue 20055 was a duplicate of this one. Both tests have been adjusted in https://github.com/python/cpython/commit/3f48ac98c04fc17f12c63dcf593dd0c19379c7df.

----------
dependencies:  -os.chmod() does not follow symlinks on Windows, os.path.realpath on Windows does not follow symbolic links
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> On Windows NT 6 with administrator account, there are two failing tests on test_shutil.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13837>
_______________________________________

From report at bugs.python.org  Mon Aug 13 01:38:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 13 Aug 2018 05:38:52 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534138732.39.0.56676864532.issue34384@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

In msg235615 (Issue 9949), Zachary said using bytes paths on Windows is deprecated, but I can't see the actual conversation because Rietveld seems to be down: https://bugs.python.org/review/9949/#ps5077 I think the os.readlink() documentation needs to be updated if we decide to keep the status quo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Mon Aug 13 02:21:18 2018
From: report at bugs.python.org (Joshua Kinard)
Date: Mon, 13 Aug 2018 06:21:18 +0000
Subject: [issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C
 properly
In-Reply-To: <1375175592.24.0.539816782076.issue18597@psf.upfronthosting.co.za>
Message-ID: <1534141278.09.0.56676864532.issue18597@psf.upfronthosting.co.za>


Joshua Kinard <kumba at gentoo.org> added the comment:

I was able to modify eryksun's patch for Python-2.7.15, at least the bulk of it.  It looks like the '_PyOS_SigintEvent' function is new to the 3.x branch, and despite it being a fairly simple function, it's used in a few core Python modules.  So I'm not sure the difficulty of adding it for Python-2.7.  Is there an alternative function available in the 2.7 code that I can replace it with?

I also don't have a clue how anyone even builds Python-2.7 on Windows, because getting the required tools properly installed borders on the arcane (esp VS2008 tools).  So testing it might be a bit difficult.  Is there a cheat sheet somewhere?

----------
nosy: +kumba

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18597>
_______________________________________

From report at bugs.python.org  Mon Aug 13 03:14:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Aug 2018 07:14:03 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534144443.49.0.56676864532.issue34384@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Currently the behavior doesn't match the documentation. Initially I thought that this can be solved by adding the support of path-like objects and backporting this up to 3.6. But os.readlink() on Windows doesn't not support also bytes paths, and never supported. This looks to me now more like a new feature. In 3.6 and 3.7 we can resolve this issue by just updating the documentation.

Bytes paths on Windows were deprecated before 3.6. Since implementing PEP 529, their should be supported on Windows if they are supported on other platforms. We shouldn't use an 8-bit API like CreateFileA, but instead decode bytes paths with UTF-8 and use a Unicode API (this should be implemented in path_converter()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Mon Aug 13 03:21:48 2018
From: report at bugs.python.org (Niels Kristian Jensen)
Date: Mon, 13 Aug 2018 07:21:48 +0000
Subject: [issue30563] [Cygwin] multiprocessing module with pool object issue
In-Reply-To: <1496559266.31.0.239393976491.issue30563@psf.upfronthosting.co.za>
Message-ID: <1534144908.73.0.56676864532.issue30563@psf.upfronthosting.co.za>


Niels Kristian Jensen <nkj at internetgruppen.dk> added the comment:

I ran the same test on Windows 10, works fine, but Windows Server 2012 bails out with no message, no abnormal exit code.

@Antoine Pitrou - if Cygwin and Python3 are non-compatible, I suggest that someone in the Python3 community writes a note about this, for reference.

In fact, the Python package should probably be removed from Cygwin?

----------
nosy: +nkjensen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30563>
_______________________________________

From report at bugs.python.org  Mon Aug 13 04:10:58 2018
From: report at bugs.python.org (Martin Panter)
Date: Mon, 13 Aug 2018 08:10:58 +0000
Subject: [issue34357] situation where urllib3 works, but urllib does not work
In-Reply-To: <1533730627.83.0.56676864532.issue34357@psf.upfronthosting.co.za>
Message-ID: <1534147858.24.0.56676864532.issue34357@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I can?t get it to hang. Does your computer or Internet provider have a proxy or firewall that may be interfering?

Perhaps it is worth comparing the HTTP header fields being sent and received. You can enable debug messages to see the request sent, and print the response fields directly. Most important things to look for are the Content-Length and Transfer-Encoding (if any) fields in the response.

>>> import urllib.request
>>> url = "https://cinnamon-spices.linuxmint.com/json/applets.json"
>>> handler = urllib.request.HTTPSHandler(debuglevel=1)
>>> opener = urllib.request.build_opener(handler)
>>> resp = opener.open(url)
send: b'GET /json/applets.json HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: cinnamon-spices.linuxmint.com\r\nUser-Agent: Python-urllib/3.6\r\nConnection: close\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: Server header: Date header: Content-Type header: Content-Length header: Connection header: Last-Modified header: ETag header: X-Sucuri-Cache header: X-XSS-Protection header: X-Frame-Options header: X-Content-Type-Options header: X-Sucuri-ID header: Accept-Ranges $
>>> print(response.info())
Server: Sucuri/Cloudproxy
Date: Mon, 13 Aug 2018 07:18:11 GMT
Content-Type: application/json
Content-Length: 70576
Connection: close
Last-Modified: Mon, 13 Aug 2018 07:25:14 GMT
ETag: "113b0-5734bfe97145e"
X-Sucuri-Cache: HIT
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Sucuri-ID: 11014
Accept-Ranges: bytes


>>> data = resp.read()
>>> len(data)
70576

Another experiment would be to try ?http.client? directly, which I understand is used by both the built-in ?urllib.request? module, and ?urllib3?:

from http.client import HTTPSConnection
conn = HTTPSConnection("cinnamon-spices.linuxmint.com")
headers = {  # Same header fields sent by ?urllib.request?
    "Accept-Encoding": "identity",
    "Host": "cinnamon-spices.linuxmint.com",
    "User-Agent": "Python-urllib/3.6",
    "Connection": "close",
}
conn.request("GET", "/json/applets.json", headers=headers)
resp = conn.getresponse()
print(resp.msg)
data = resp.read()

Try removing the ?Connection: close? field from the request. Occasionally this triggers bad server behaviour (see Issue 12849); maybe your server or proxy is affected.

----------
nosy: +martin.panter
stage:  -> test needed
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34357>
_______________________________________

From report at bugs.python.org  Mon Aug 13 04:23:44 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 13 Aug 2018 08:23:44 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
In-Reply-To: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>
Message-ID: <1534148624.65.0.56676864532.issue34386@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

IMHO we shouldn't expose the intern dictionary without there being a clear, and good enough, use case for doing so.  

Exposing the dictionary decreases implementation flexibility, and increases requirements on other implementations.  One example of the former: at least in theory the interning dictionary could be a set, but we couldn't make that change if the dictionary were exposed in the API.

With current information I'm -1 on exposing the dictionary, and -0 on doing that for debug builds only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Mon Aug 13 05:25:55 2018
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 Aug 2018 09:25:55 +0000
Subject: [issue30563] [Cygwin] multiprocessing module with pool object issue
In-Reply-To: <1496559266.31.0.239393976491.issue30563@psf.upfronthosting.co.za>
Message-ID: <1534152355.1.0.56676864532.issue30563@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In fact, the Python package should probably be removed from Cygwin?

We don't maintain Cygwin nor Python on Cygwin here.  You should contact those people.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30563>
_______________________________________

From report at bugs.python.org  Mon Aug 13 05:38:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Aug 2018 09:38:52 +0000
Subject: [issue34386] Expose a dictionary of interned strings in sys module
In-Reply-To: <1534066573.72.0.56676864532.issue34386@psf.upfronthosting.co.za>
Message-ID: <1534153132.11.0.56676864532.issue34386@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Ronald. Using a dict instance is an implementation detail. CPython could use a dict, a set, a hashtable implementation from Modules/hashtable.c, or the HAMT implementation from Python/hamt.c. Other Python implementations can have other options.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34386>
_______________________________________

From report at bugs.python.org  Mon Aug 13 05:47:28 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 13 Aug 2018 09:47:28 +0000
Subject: [issue1529353] Squeezer - squeeze large output in the interpreter
Message-ID: <1534153648.78.0.56676864532.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I'm back to working on this.  I've made good progress: I'm nearly done with all of the changes suggested here and ready for another PR review.

I'd like some opinions on a few things:

1. Should the tooltip-related configuration options be removed?  There is one for whether to show tooltips for squeezed outputs and another to set the hover delay.  I feel that they add unnecessary complexity.

2. Should there be an option to entirely disable auto-squeezing?  Currently there is only a setting for the minimum number of lines, which can just be set very high.

3. Should we keep the events for squeezing the last output block and expanding the last squeezed output block?  ISTM the keyboard shortcuts would only be used by "power users", which aren't our main target.  Further, without keyboard shortcuts, I see no point for having these events at all, given that it is easy to achieve this otherwise.

4. Is it worth the effort to update the number of lines displayed for squeezed outputs when a shell window's width is changed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Mon Aug 13 05:50:35 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 13 Aug 2018 09:50:35 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
Message-ID: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Related to #32947

Four ftplib tests are failing with OpenSSL 1.1.1-pre8 and TLS 1.3 enabled. All failing tests use a separate data connection and transfer data on the server. For store operations, the client never calls recv(). This breaks bidirectional shutdown. I assume there are session tickets stuck on the wire.

======================================================================
ERROR: test_storbinary (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ftplib.py", line 591, in test_storbinary
    self.client.storbinary('stor', f)
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 514, in storbinary
    conn.unwrap()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1091, in unwrap
    s = self._sslobj.shutdown()
OSError: [Errno 0] Error

======================================================================
ERROR: test_storbinary_rest (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ftplib.py", line 603, in test_storbinary_rest
    self.client.storbinary('stor', f, rest=r)
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 514, in storbinary
    conn.unwrap()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1091, in unwrap
    s = self._sslobj.shutdown()
OSError: [Errno 0] Error

======================================================================
ERROR: test_storlines (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ftplib.py", line 608, in test_storlines
    self.client.storlines('stor', f)
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 545, in storlines
    conn.unwrap()
  File "/home/heimes/dev/python/cpython/Lib/ssl.py", line 1091, in unwrap
    s = self._sslobj.shutdown()
OSError: [Errno 0] Error

======================================================================
ERROR: test_data_connection (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/heimes/dev/python/cpython/Lib/test/test_ftplib.py", line 889, in test_data_connection
    self.assertEqual(self.client.voidresp(), "226 transfer complete")
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 251, in voidresp
    resp = self.getresp()
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 236, in getresp
    resp = self.getmultiline()
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 222, in getmultiline
    line = self.getline()
  File "/home/heimes/dev/python/cpython/Lib/ftplib.py", line 204, in getline
    line = self.file.readline(self.maxline + 1)
  File "/home/heimes/dev/python/cpython/Lib/socket.py", line 589, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

----------------------------------------------------------------------
Ran 88 tests in 9.402s

FAILED (errors=4, skipped=1)

----------
messages: 323472
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: test_ftplib is failing with TLS 1.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Mon Aug 13 06:24:33 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Aug 2018 10:24:33 +0000
Subject: [issue34392] Add sys.isinterned()
Message-ID: <1534155873.32.0.56676864532.issue34392@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

I need to test whether the string is interned for Python implementations of marshal.dumps(). It is easy to do in C, and I suggest to expose this functionality to Python.

Currently you can test if the string is interned using the following function:

    def isinterned(s):
        return sys.intern(s) is s

But it has a side effect -- it interns a string if it is not equal to an already interned string.

----------
components: Interpreter Core
messages: 323473
nosy: rhettinger, ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add sys.isinterned()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34392>
_______________________________________

From report at bugs.python.org  Mon Aug 13 06:29:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Aug 2018 10:29:27 +0000
Subject: [issue34392] Add sys.isinterned()
In-Reply-To: <1534155873.32.0.56676864532.issue34392@psf.upfronthosting.co.za>
Message-ID: <1534156167.02.0.56676864532.issue34392@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8231
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34392>
_______________________________________

From report at bugs.python.org  Mon Aug 13 07:07:02 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 13 Aug 2018 11:07:02 +0000
Subject: [issue34392] Add sys.isinterned()
In-Reply-To: <1534155873.32.0.56676864532.issue34392@psf.upfronthosting.co.za>
Message-ID: <1534158422.8.0.56676864532.issue34392@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'd prefer to have this as an internal API, either sys._isinterned() or as a helper method in testcapi.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34392>
_______________________________________

From report at bugs.python.org  Mon Aug 13 07:34:23 2018
From: report at bugs.python.org (liad)
Date: Mon, 13 Aug 2018 11:34:23 +0000
Subject: [issue34393] json.dumps - allow compression
Message-ID: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>


New submission from liad <liad at mailinator.com>:

The list of arguments of json.dump() can be seen here: https://docs.python.org/2/library/json.html

Notice that there is no way to make compression.

For example pandas allows you to do:
        df.to_csv(path_or_buf=file_name, index=False, encoding='utf-8',
                  compression='gzip',
                  quoting=QUOTE_NONNUMERIC)

I want to be able to compress when I do:
    with open('products.json', 'w') as outfile:
        json.dump(data, outfile, sort_keys=True)


Please add the ability to compress using json.dump()

----------
messages: 323475
nosy: liad100
priority: normal
severity: normal
status: open
title: json.dumps - allow compression
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Mon Aug 13 07:49:24 2018
From: report at bugs.python.org (rushter)
Date: Mon, 13 Aug 2018 11:49:24 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534160964.71.0.56676864532.issue34393@psf.upfronthosting.co.za>


rushter <me at rushter.com> added the comment:

You can use the gzip module.

with gzip.GzipFile('products.json', 'w') as outfile:
        outfile.write(json.dumps(data, outfile, sort_keys=True))

----------
nosy: +rushter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Mon Aug 13 08:24:08 2018
From: report at bugs.python.org (liad)
Date: Mon, 13 Aug 2018 12:24:08 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534163048.03.0.56676864532.issue34393@psf.upfronthosting.co.za>


liad <liad at mailinator.com> added the comment:

The gzip module may work for saving file localy but for example:

This upload json to Google Storage:

import datalab.storage as storage
storage.Bucket('mybucket').item(path).write_to(json.dumps(response), 'application/json')

Your won't work here unless I save the file locally and only then upload it... It's a bit of a problem when your files are  100 GBs+

I still think the json.dump() should support compression

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Mon Aug 13 08:26:39 2018
From: report at bugs.python.org (David)
Date: Mon, 13 Aug 2018 12:26:39 +0000
Subject: [issue34357] situation where urllib3 works, but urllib does not work
In-Reply-To: <1533730627.83.0.56676864532.issue34357@psf.upfronthosting.co.za>
Message-ID: <1534163199.66.0.56676864532.issue34357@psf.upfronthosting.co.za>


David <deivid.rodriguez at riseup.net> added the comment:

Hi Martin.

It's definitely something with my internet connection. Yesterday I temporarily changed the way I connect to the internet to use the mobile connection from my cell phone instead of my WiFi connection, and things started working.

I also debugged the headers being received and I did notice the "Connection: Close" header was the only relevant difference in the request when comparing it to the request sent by my browser when accessing that page directly. My next task was to investigate how to do what you just suggested... With my currently knowledge of python it would've taken me ages to figure out, so thanks so much!

Let me try your suggestions and report back! Thanks so much for your help! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34357>
_______________________________________

From report at bugs.python.org  Mon Aug 13 08:36:26 2018
From: report at bugs.python.org (Semyon)
Date: Mon, 13 Aug 2018 12:36:26 +0000
Subject: [issue34394] Descriptors HowTo doesn't mention __set_name__
Message-ID: <1534163786.32.0.56676864532.issue34394@psf.upfronthosting.co.za>


New submission from Semyon <simeon+bpo at maryasin.name>:

There is a great HowTo document for descriptors https://github.com/python/cpython/blob/master/Doc/howto/descriptor.rst
But it doesn't even mention the __set_name__ method which was added in py3. And it lists the descriptor protocol without that method as if it is the full protocol. The only way to know about that method is to go to the link for any other method and then you'll see that there is a __set_name__.
I think the guide sholud be updated to include at least information about existence of __set_name__.

----------
assignee: docs at python
components: Documentation
messages: 323479
nosy: MarSoft, docs at python
priority: normal
severity: normal
status: open
title: Descriptors HowTo doesn't mention __set_name__
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34394>
_______________________________________

From report at bugs.python.org  Mon Aug 13 08:39:51 2018
From: report at bugs.python.org (David)
Date: Mon, 13 Aug 2018 12:39:51 +0000
Subject: [issue34357] situation where urllib3 works, but urllib does not work
In-Reply-To: <1533730627.83.0.56676864532.issue34357@psf.upfronthosting.co.za>
Message-ID: <1534163991.15.0.56676864532.issue34357@psf.upfronthosting.co.za>


David <deivid.rodriguez at riseup.net> added the comment:

martin.parter, it worked! Thanks so much, I was going nuts!!!! I also read the issue you pointed to, very interesting. Even if all servers should just work here, it does not seem to be the case in real life (I guess it's something easy to misconfigure) so I agree not setting "Connection: false" by default would make the standard lib more user friendly.

I guess I'll now talk to the maintainers of the upstream library and suggest the following:

* Reading this issue and the one you pointed to.
* Reviewing their server configuration.
* Migrating to http.client, specially if they don't make to fix the server configuration.

This can now be closed, thanks so much again <3

----------
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34357>
_______________________________________

From report at bugs.python.org  Mon Aug 13 08:48:25 2018
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 13 Aug 2018 12:48:25 +0000
Subject: [issue15100] Race conditions in shutil.copy,
 shutil.copy2 and shutil.copyfile
In-Reply-To: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za>
Message-ID: <1534164505.89.0.56676864532.issue15100@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

(Note:  I am talking only about the disclosure issue; file corruption would ideally be fixed as far back as possible, though I would be somewhat sympathetic to a "nah, that ain't security, too late" argument.)

My current UI shows this as relevant to every release *except* 3.4 and 3.8.  If it is really 3.4 only, I think it should be closed -- anyone still using 3.4 *and* able to install from source is likely to be more upset by unexpected (and possibly silent) breakage of an existing process than new exploits of a 6 year old bug.  

If it really does apply to 3.5-3.7, then it would be good to do the same fix in all (and to match 3.8, which presumably is also affected, and simply wasn't available to check when the Versions were last set).

If, for some reason, the *right* fix on 3.8 (or at least 3.7 or 3.6) doesn't apply to earlier 3.x versions, I suggest closing it as won't-fix on those older versions.

That said, I'm probably the wrong person to verify which versions are affected, so consider this as only soft support for Release Manager to do so if this continues to languish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15100>
_______________________________________

From report at bugs.python.org  Mon Aug 13 08:53:46 2018
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 13 Aug 2018 12:53:46 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
 setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1534164826.3.0.56676864532.issue17180@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

My current UI shows this as relevant *only* to 3.4 and 3.5.  If it really has been fixed in 3.6, and the fix can't be backported, I think the risk of breaking backup programs is enough to argue for doing nothing more than a doc change.  Anyone still using 3.4 (or even 3.5) *and* able to install from source is likely to be more upset by unexpected (and possibly silent) breakage of an existing process than new exploits of a 6 year old bug.  

That said, I'm probably the wrong person to verify which versions are affected, so consider this as only soft support for Release Manager to do so if this continues to languish.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Mon Aug 13 09:14:33 2018
From: report at bugs.python.org (Jeff Dafoe)
Date: Mon, 13 Aug 2018 13:14:33 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1534166073.78.0.56676864532.issue16038@psf.upfronthosting.co.za>


Jeff Dafoe <jeffdafoe at gmail.com> added the comment:

I have a question about this old patch, as it just came down in a CentOS 6 update. I think the patch is applied to the data channel in ASCII mode and not just the control channel. On the data channel in ASCII mode, there should be no assumption of maximum line length before EOL. I saw that your current value came from vsftpd's header file. I'm guessing if you look at the implementation, it's either only applied to the control channel or it's just used to set a single read size inside of a loop.  Examples of ASCII mode files that can exceed nearly any MAXLINE value without EOL are XML files or EDI files.

----------
nosy: +Jeff Dafoe

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Aug 13 11:13:28 2018
From: report at bugs.python.org (Shiva Saxena)
Date: Mon, 13 Aug 2018 15:13:28 +0000
Subject: [issue34117] Rename "generator expressions" to "generator
 comprehensions"
In-Reply-To: <1531614433.94.0.56676864532.issue34117@psf.upfronthosting.co.za>
Message-ID: <1534173208.11.0.56676864532.issue34117@psf.upfronthosting.co.za>


Shiva Saxena <shivasaxena911 at gmail.com> added the comment:

I am interested to work on this issue. It would be my first contribution in cpython. Should I go ahead?

----------
nosy: +GeekyShacklebolt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34117>
_______________________________________

From report at bugs.python.org  Mon Aug 13 12:26:18 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Aug 2018 16:26:18 +0000
Subject: [issue19050] [Python 2,
 Windows] fflush called on pointer to potentially closed file
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1534177578.94.0.56676864532.issue19050@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

As this is a fail-fast and not an uncontrolled crash, I vote to close as wontfix.

This only applies to security-fix versions, and it is not exploitable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Mon Aug 13 12:28:15 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 13 Aug 2018 16:28:15 +0000
Subject: [issue19050] [Python 2,
 Windows] fflush called on pointer to potentially closed file
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1534177695.85.0.56676864532.issue19050@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Mon Aug 13 12:32:30 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Aug 2018 16:32:30 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534177950.22.0.56676864532.issue34384@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Serhiy is exactly right, but to emphasise, the best way to do paths now is to use argument clinic with its path_t type. On Windows, .narrow is a flag that indicates whether you should PyUnicode_FSEncode() any results before returning them, and .wide is always initialized correctly.

Do not use any *A APIs - only *W from now on :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Mon Aug 13 12:53:22 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Mon, 13 Aug 2018 16:53:22 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
Message-ID: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

There are memory leaks in csv and pickle modules caused by incautious usage of PyMem_Resize().

See GitHub PR.

----------
components: Extension Modules
messages: 323487
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: memory leaks in error handling in csv and pickle modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Mon Aug 13 12:54:20 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Mon, 13 Aug 2018 16:54:20 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534179260.26.0.56676864532.issue34395@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +8232
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Mon Aug 13 14:08:17 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 13 Aug 2018 18:08:17 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534183697.74.0.56676864532.issue34384@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the suggestions! I've updated PR 8740. I will submit separate PRs to fix os.readlink() documentation in 3.6 and 3.7 branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Mon Aug 13 15:23:19 2018
From: report at bugs.python.org (Niklas Rosenstein)
Date: Mon, 13 Aug 2018 19:23:19 +0000
Subject: [issue33262] Deprecate shlex.split(None) to read from stdin.
In-Reply-To: <1523442529.49.0.682650639539.issue33262@psf.upfronthosting.co.za>
Message-ID: <1534188199.02.0.56676864532.issue33262@psf.upfronthosting.co.za>


Niklas Rosenstein <rosensteinniklas at gmail.com> added the comment:

I've just run into this as well -- I thought it was a bug until I found this issue. I also think that this is anything from sane.

----------
nosy: +n_rosenstein

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33262>
_______________________________________

From report at bugs.python.org  Mon Aug 13 15:36:41 2018
From: report at bugs.python.org (Dan Snider)
Date: Mon, 13 Aug 2018 19:36:41 +0000
Subject: [issue34396] Certain methods that heap allocated subtypes inherit
 suffer a 50-80% performance penalty
Message-ID: <1534189001.92.0.56676864532.issue34396@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

The ones I know of are list.__getitem__, dict __contains__ & __getitem__, and (frozen)set.__contains__ but from what I can tell so far it seems like dict.__getitem__ takes the worst hit. For dicts, I've spent a few hours trying to figure out what's getting put into the heap type's mp_subscript slot to slow it down so drastically but I just can't figure it out. 

So I just forced `dict_subscript` into the heap type's mp_subscript slot to confirm the rather obvious impossibility of it breaking anything. Here's a "little" timeit script to demonstrate how horribly inefficient `dict.__getitem__` is when called on anything other than an extension type:

if __name__ == '__main__':

    import timeit
    from collections import OrderedDict as FastDictSub
    from ctypes import *
    
    class mappingmethods(Structure):
        _fields_ = [
            ('mp_length', c_void_p),
            ('mp_subscript', PYFUNCTYPE(py_object,py_object,py_object)),
            ('mp_ass_subscript', c_void_p)]
        
    class _type_object(Structure):
        _fields_ = [('junk', (c_uint8*56)), # <- brevity
                    ('tp_as_mapping', POINTER(mappingmethods))]
    py_type = POINTER(_type_object)
    
    class SlowDictSub(dict):
        pass

    assert SlowDictSub.__base__ is dict and FastDictSub.__base__ is dict
    assert SlowDictSub.__getitem__ is dict.__getitem__
    assert FastDictSub.__getitem__ is dict.__getitem__

    mp = dict.fromkeys(range(15))
    setup = 'from __main__ import mp, %s as Dict; d=Dict(mp)'
    print(f'Comparing execution time of heap allocated dict subtype '
          f'versus PyODict_Type (who also inherits dict.__getitem__)...\n')
    slown, slowt = timeit.Timer('d[10]', setup%'SlowDictSub').autorange()
    print(f'avg. exec {slown/slowt:_.0f} SlowDictSub[x] statements per second')
    fastn, fastt = timeit.Timer('d[10]', setup%'FastDictSub').autorange()
    print(f'avg. exec {fastn/fastt:_.0f} OrderedDict[x] statements per second')
    print()
    print(f'SlowDictSub was {1/(fastt/slowt):.2f}x slower than OrderedDict... '
          f"Let's see what happens when we fix SlowDictSub's 'broken' "
          "mp_subscript slot:\n")
    slow_tp = cast(id(SlowDictSub), py_type).contents
    fast_tp = cast(id(FastDictSub), py_type).contents
    
    slow_tp.tp_as_mapping.contents.mp_subscript = (
        fast_tp.tp_as_mapping.contents.mp_subscript)
    postn, postt = timeit.Timer('d[10]', setup%'SlowDictSub').autorange()
    print(f'avg. exec {postn/postt:_.0f} SlowDictSub[x] after slot change')
    print(f'which is now {1/(fastt/postt):.2}x the speed of dict_item')


Comparing execution time of heap allocated dict subtype versus PyODict_Type (who also inherits dict.__getitem__)...

avg. exec 6_220_709 SlowDictSub[x] statements per second
avg. exec 21_894_971 OrderedDict[x] statements per second

SlowDictSub was 3.52x slower than OrderedDict... Let's see what happens when we fix SlowDictSub's 'broken' mp_subscript slot:

avg. exec 21_665_595 SlowDictSub[x] after slot change
which is now 1.0x the speed of dict_item

----------
components: Interpreter Core
messages: 323490
nosy: bup
priority: normal
severity: normal
status: open
title: Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty
type: performance
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34396>
_______________________________________

From report at bugs.python.org  Mon Aug 13 15:38:54 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Mon, 13 Aug 2018 19:38:54 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
Message-ID: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

Max size of list and tuples is limited by PY_SSIZE_T_MAX / sizeof(PyObject*), so the sum of any two list/tuples sizes always <= PY_SSIZE_T_MAX if sizeof(PyObject*) > 1, which seems true for all supported (existing?) platforms.
It means that overflow checks in app1, ins1, list_concat and tupleconcat are redundant and can be safely removed.

----------
components: Interpreter Core
messages: 323491
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: remove redundant overflow checks in tuple and list implementations
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Mon Aug 13 15:39:51 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Mon, 13 Aug 2018 19:39:51 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1534189191.67.0.56676864532.issue34397@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +8233
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Mon Aug 13 15:59:35 2018
From: report at bugs.python.org (Xavier Hardy)
Date: Mon, 13 Aug 2018 19:59:35 +0000
Subject: [issue34356] Add support for args and kwargs in logging.conf
In-Reply-To: <1533715378.01.0.56676864532.issue34356@psf.upfronthosting.co.za>
Message-ID: <1534190375.94.0.56676864532.issue34356@psf.upfronthosting.co.za>


Change by Xavier Hardy <hardyxavier at gmail.com>:


----------
keywords: +patch
pull_requests: +8234
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34356>
_______________________________________

From report at bugs.python.org  Mon Aug 13 16:37:19 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Aug 2018 20:37:19 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534192639.6.0.56676864532.issue34395@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hi and thank you for the report. Could you elaborate a bit more on how/where the leak happens? This will help when reviewing the Pull Request. Thanks!

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Mon Aug 13 17:33:17 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Aug 2018 21:33:17 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy
In-Reply-To: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>
Message-ID: <1534195997.54.0.56676864532.issue34387@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I agree with Eric that without concrete details I suspect everything is working as expected. E.g.

```python
class Foo:
   attr = -13

ins = Foo()
ins.attr = 42
print(ins.attr)
del ins.attr
print(ins.attr)
```

----------
nosy: +brett.cannon
title: Deletion of attributes in dataclass is buggy! -> Deletion of attributes in dataclass is buggy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Mon Aug 13 18:12:06 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Aug 2018 22:12:06 +0000
Subject: [issue34394] Descriptors HowTo doesn't mention __set_name__
In-Reply-To: <1534163786.32.0.56676864532.issue34394@psf.upfronthosting.co.za>
Message-ID: <1534198326.69.0.56676864532.issue34394@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks. I'm already working on this.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34394>
_______________________________________

From report at bugs.python.org  Mon Aug 13 19:04:39 2018
From: report at bugs.python.org (Erik Janssens)
Date: Mon, 13 Aug 2018 23:04:39 +0000
Subject: [issue27186] add os.fspath()
In-Reply-To: <20160602220647.10416.48472.A244A1B0@psf.io>
Message-ID: <1534201479.7.0.56676864532.issue27186@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

thank you for the info ... I'll have a look at making the posix module easier to port ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27186>
_______________________________________

From report at bugs.python.org  Mon Aug 13 20:53:51 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Aug 2018 00:53:51 +0000
Subject: [issue34117] Rename "generator expressions" to "generator
 comprehensions"
In-Reply-To: <1531614433.94.0.56676864532.issue34117@psf.upfronthosting.co.za>
Message-ID: <1534208031.62.0.56676864532.issue34117@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Results from two Python courses:

* In terms of teaching gexexps, there was no net gain or loss.  When genexps are show side-by-side with list/dict/set comps the symmetric relationship was obvious regardless of terminology.

* In terms of being able to search StackOverflow, blog posts, and external resources, the new terminology made the resources unfindable.

* When using the new terminology, I did get questions that never came up before, "why don't the parentheses mean tuple-comprehension".

Based on those results, I recommend we keep the terminology the same as it is now.  The loss of searchability isn't worth it (there doesn't seem to be any upside) and it is concerning that a new category of confusion (list/tuple comprehension) seems to be arising from the change in terminology.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34117>
_______________________________________

From report at bugs.python.org  Mon Aug 13 20:55:28 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Aug 2018 00:55:28 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1534208128.62.0.56676864532.issue34397@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +mark.dickinson, serhiy.storchaka, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Tue Aug 14 00:15:47 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Aug 2018 04:15:47 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1534220147.1.0.56676864532.issue34270@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8235

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Tue Aug 14 00:32:34 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Aug 2018 04:32:34 +0000
Subject: [issue34270] Add names to asyncio tasks
In-Reply-To: <1532856337.57.0.56676864532.issue34270@psf.upfronthosting.co.za>
Message-ID: <1534221154.51.0.56676864532.issue34270@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset aa4e4a40db531f7095513a4b0aa6510f18162a07 by Benjamin Peterson in branch 'master':
Make regular expressions in test_tasks.py raw strings. (GH-8759)
https://github.com/python/cpython/commit/aa4e4a40db531f7095513a4b0aa6510f18162a07


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34270>
_______________________________________

From report at bugs.python.org  Tue Aug 14 00:40:20 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Aug 2018 04:40:20 +0000
Subject: [issue34396] Certain methods that heap allocated subtypes inherit
 suffer a 50-80% performance penalty
In-Reply-To: <1534189001.92.0.56676864532.issue34396@psf.upfronthosting.co.za>
Message-ID: <1534221620.84.0.56676864532.issue34396@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Amusingly, this is because of an old hack to make directly calling somedict.__getitem__ fast: https://github.com/python/cpython/commit/8f5cdaa784f555149adf5e94fd2e989f99d6b1db

Reverting the dictobject.c changes of the commit, i.e., the following patch, fixes your example.

diff --git a/Objects/dictobject.c b/Objects/dictobject.c
index 413557d667..d85834977d 100644
--- a/Objects/dictobject.c
+++ b/Objects/dictobject.c
@@ -3032,8 +3032,6 @@ dict_sizeof(PyDictObject *mp, PyObject *Py_UNUSED(ignored))
     return PyLong_FromSsize_t(_PyDict_SizeOf(mp));
 }
 
-PyDoc_STRVAR(getitem__doc__, "x.__getitem__(y) <==> x[y]");
-
 PyDoc_STRVAR(sizeof__doc__,
 "D.__sizeof__() -> size of D in memory, in bytes");
 
@@ -3071,8 +3069,6 @@ PyDoc_STRVAR(values__doc__,
 
 static PyMethodDef mapp_methods[] = {
     DICT___CONTAINS___METHODDEF
-    {"__getitem__", (PyCFunction)dict_subscript,        METH_O | METH_COEXIST,
-     getitem__doc__},
     {"__sizeof__",      (PyCFunction)dict_sizeof,       METH_NOARGS,
      sizeof__doc__},
     DICT_GET_METHODDEF

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34396>
_______________________________________

From report at bugs.python.org  Tue Aug 14 00:41:13 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 14 Aug 2018 04:41:13 +0000
Subject: [issue34390] arparse.ArgumentParser misparses list arguments followed
 by undefined arguments
In-Reply-To: <1534130705.52.0.56676864532.issue34390@psf.upfronthosting.co.za>
Message-ID: <1534221673.85.0.56676864532.issue34390@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

Parsing is a two step process.  First the strings are passed through

def _parse_optional(self, arg_string):

which classifies them as 'O', an optional flag, or 'A', an argument.

- no prefix char => A
- the string is in the dictionary of option_strings (e.g. '--list-arg') => O
- one char => A
- has '=' and first part in option_strings => O
- test for abreviations
- negative number => O or A
- contains space => A
- else => unmatched O?

(read it for the details)

With your inputs, the pattern is:

['--list-arg', 'a', '--text-arg', 'hello world']
O A O? A

['--list-arg', 'a', '--text-arg=hello']
O A O?

['--list-arg', 'a', '--text-arg=hello world']
O A A

It's the space in the string marks it as an argument that can be added to the '--list-arg' list.

Unmatched optionals go on the 'extras' list.

---

In [25]: parser.parse_known_args(['--list-arg', 'a', '--text-arg', 'hello world'])
Out[25]: (Namespace(list_arg=['a']), ['--text-arg', 'hello world'])

In [26]: parser.parse_known_args(['--list-arg', 'a', '--text-arg=hello'])
Out[26]: (Namespace(list_arg=['a']), ['--text-arg=hello'])

In [32]: parser.parse_known_args(['--list-arg', 'a', '--text-arg=hello world'])
Out[32]: (Namespace(list_arg=['a', '--text-arg=hello world']), [])

---

So '--text-arg=hello world' is split into ['--text-arg', 'hello world'] only if '--text-arg' is an option_string.

Any ways, the behavior is explainable.  Whether the blank should have this priority might be debatable, but I suspect any changes will be rejected on the grounds of backward incompatibility.  

Your users still have the option of using:

--text-arg 'hello world'

It may be worth search the issues for an earlier discussion.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34390>
_______________________________________

From report at bugs.python.org  Tue Aug 14 00:51:50 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 14 Aug 2018 04:51:50 +0000
Subject: [issue34390] arparse.ArgumentParser misparses list arguments followed
 by undefined arguments
In-Reply-To: <1534130705.52.0.56676864532.issue34390@psf.upfronthosting.co.za>
Message-ID: <1534222310.03.0.56676864532.issue34390@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

Duplicate of

https://bugs.python.org/issue22909 [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg (closed as duplicate)

https://bugs.python.org/issue22433 Argparse considers unknown optional arguments with spaces as a known positional argument

In 22433 I suggested a patch but worried about backward incompatibility.  

I propose closing this as a duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34390>
_______________________________________

From report at bugs.python.org  Tue Aug 14 01:17:08 2018
From: report at bugs.python.org (Preston Moore)
Date: Tue, 14 Aug 2018 05:17:08 +0000
Subject: [issue30400] Race condition in shutil.copyfile(): source file
 replaced file during copy
In-Reply-To: <1495138920.07.0.300372261513.issue30400@psf.upfronthosting.co.za>
Message-ID: <1534223828.3.0.56676864532.issue30400@psf.upfronthosting.co.za>


Preston Moore <prestonkmoore at gmail.com> added the comment:

Hello everyone,

I've just updated my pull request to include an additional test so everything should be in shape testing wise.

Once I get confirmation that this strategy is acceptable and/or this PR is merged I will get to work addressing the other identified problem areas in a similar fashion.  There are a few more weeks before classes start back up for the fall semester so I should have available bandwidth to make good progress.

Thanks,
Preston

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30400>
_______________________________________

From report at bugs.python.org  Tue Aug 14 01:24:18 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Aug 2018 05:24:18 +0000
Subject: [issue34356] Add support for args and kwargs in logging.conf
In-Reply-To: <1533715378.01.0.56676864532.issue34356@psf.upfronthosting.co.za>
Message-ID: <1534224258.35.0.56676864532.issue34356@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Adding Vinay for his thoughts on this. Also Python 3.4 and 3.5 are in security fixes only mode and can be removed.

Thanks

----------
nosy: +vinay.sajip, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34356>
_______________________________________

From report at bugs.python.org  Tue Aug 14 01:42:56 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 14 Aug 2018 05:42:56 +0000
Subject: [issue34357] situation where urllib3 works, but urllib does not work
In-Reply-To: <1533730627.83.0.56676864532.issue34357@psf.upfronthosting.co.za>
Message-ID: <1534225376.16.0.56676864532.issue34357@psf.upfronthosting.co.za>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
superseder:  -> Cannot override 'connection: close' in urllib2 headers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34357>
_______________________________________

From report at bugs.python.org  Tue Aug 14 03:40:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 07:40:21 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1534232421.09.0.56676864532.issue32947@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8236

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Tue Aug 14 03:44:21 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 07:44:21 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1534232661.72.0.56676864532.issue32947@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8237

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Tue Aug 14 03:52:28 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Tue, 14 Aug 2018 07:52:28 +0000
Subject: [issue34398] Docs search does not index glossary
Message-ID: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

The docs contain a very useful page https://docs.python.org/3.5/glossary.html. However, the search feature does not index the glossary.

Thus, the search https://docs.python.org/3.5/search.html?q=iterable does not produce the helpful glossary entry
===
iterable
An object capable of returning its members one at a time. Examples of iterables include all sequence types (such as list, str, and tuple) and some non-sequence types like dict, file objects, and objects of any  [...]
===

#788509 is the only docs issue I could find, whose title contains glossary. It gives insight into the thoughts then about the tutorial. In msg44460 Skip Montaro says (1) that the glossary is "for the tutorial", and (2) he'd like to improve links into the tutorial. 

I suggest that part of the fix for this issue is on the home page page Glossary in the first grouping "Parts of the documentation."

----------
assignee: docs at python
components: Documentation
messages: 323503
nosy: docs at python, jfine2358
priority: normal
severity: normal
status: open
title: Docs search does not index glossary
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Tue Aug 14 04:46:29 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 08:46:29 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
Message-ID: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Downstream vendors have started to tighten security. 1024 bits RSA and DH params are no longer considered as secure. Python 3.7 and master already use 2048 bits RSA keys for some tests (bpo-32602). 3.6 and 2.7 don't have 1024bit keys. DH params and some other certs are still 1024 bits.

I'm going to update all keys and parameters to 2048.

----------
assignee: christian.heimes
components: SSL, Tests
messages: 323504
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: [TLS] Update test keys to >= 2048bit
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 04:50:59 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 08:50:59 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534236659.21.0.56676864532.issue34399@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +8238
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 05:46:55 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 14 Aug 2018 09:46:55 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
Message-ID: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

In parsetok(), null pointers are used in pointer arithmetic.

----------
components: Interpreter Core
messages: 323505
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Undefined behavior in Parser/parsetok.c
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Tue Aug 14 05:47:23 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 14 Aug 2018 09:47:23 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534240043.71.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8239
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Tue Aug 14 06:10:26 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 14 Aug 2018 10:10:26 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534241426.06.0.56676864532.issue34395@psf.upfronthosting.co.za>


Sergey Fedoseev <fedoseev.sergey at gmail.com> added the comment:

> Could you elaborate a bit more on how/where the leak happens?

It happens when PyMem_Resize() fails. It was used like this:

Py_UCS4 *field = self->field;
self->field = PyMem_Resize(field, Py_UCS4, self->field_size);

The last statement changes both self->field and field (macro magic!), so in the case PyMem_Resize() fails, previously allocated memory can't be freed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Tue Aug 14 06:54:26 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 10:54:26 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534244066.94.0.56676864532.issue34399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 88bfd0bce05043f658e50addd21366f317995e35 by Christian Heimes in branch 'master':
bpo-34399: 2048 bits RSA keys and DH params (#8762)
https://github.com/python/cpython/commit/88bfd0bce05043f658e50addd21366f317995e35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 06:54:52 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Aug 2018 10:54:52 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534244092.85.0.56676864532.issue34399@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8240

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 07:54:16 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 11:54:16 +0000
Subject: [issue34401] Make test_gdb work on HP-UX
Message-ID: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

Regex in test_gdb.py needs to be changed and test can continue, though will be skipped due to old version.

----------
components: Tests
files: test_gdb.patch
keywords: patch
messages: 323508
nosy: michael-o
priority: normal
severity: normal
status: open
title: Make test_gdb work on HP-UX
versions: Python 3.7
Added file: https://bugs.python.org/file47749/test_gdb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:01:14 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 12:01:14 +0000
Subject: [issue34401] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534248074.18.0.56676864532.issue34401@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:05:56 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Aug 2018 12:05:56 +0000
Subject: [issue34387] Deletion of attributes in dataclass is buggy
In-Reply-To: <1534074920.67.0.56676864532.issue34387@psf.upfronthosting.co.za>
Message-ID: <1534248356.84.0.56676864532.issue34387@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I assume this is the behavior you're seeing:

>>> @dataclass
... class C:
...   i: int = 0
...
>>> c = C(10)
>>> c
C(i=10)
>>> del c.i
>>> c
C(i=0)
>>> del c.i
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: i
>>>

If so, that's the expected behavior. You're deleting an instance attribute, so that the class attribute with the same name is seen.

This also happens without dataclasses:

>>> class C:
...   i = 0
...   def __init__(self, i):
...     self.i = i
...
>>> c = C(10)
>>> c.i
10
>>> del c.i
>>> c.i
0
>>> del c.i
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: i
>>>

If you're seeing something different, please re-open this issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34387>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:22:27 2018
From: report at bugs.python.org (Anuj)
Date: Tue, 14 Aug 2018 12:22:27 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1534249347.55.0.56676864532.issue18709@psf.upfronthosting.co.za>


Anuj <anujgupta0310 at gmail.com> added the comment:

Do we have patch for 3.1 version, or 3.2 patch will be also OK?

----------
nosy: +Anuj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:34:22 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 14 Aug 2018 12:34:22 +0000
Subject: [issue15258] argparse documentation: Improve optparse section
 regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1534250062.98.0.56676864532.issue15258@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

ArgumentParser.parse_intermixed_arg() has been added in https://github.com/python/cpython/commit/0f6b9d230674da784ca79a0cf1a03d2af5a8b6a8 (Issue 14191) and the "Upgrading optparse code" section now has the following item:

* Replace optparse.OptionParser.disable_interspersed_args()
  by using ArgumentParser.parse_intermixed_args() instead of
  ArgumentParser.parse_args().

Closing this as 'outdated'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15258>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:36:57 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 12:36:57 +0000
Subject: [issue34402] [SOLUTION] strftime fails on HP-UX
Message-ID: <1534250217.83.0.56676864532.issue34402@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

strftime() fails on HP-UX. It is mapped to wcsftime(3). It has a quirk on HP-UX that is does not conform to POSIX. To enable POSIX compat one has to do (excerpt from manpage):
> APPLICATION USAGE
>       The "Unix Standards Only" prototype of wcsftime() is available to
>       applications if they are:
>            a. c99 conformant.
> 
>            b. Compiled with -D_XOPEN_SOURCE macro with a value >=500.
> 
>            c. Compiled with -D_POSIX_C_SOURCE macro with a value >= 200112.
> 
>       Also the application must be compiled with the environment variable
>       UNIX_STD set to the value 98 or above and exported.

b and c are satasfied according to config.log. Let's get to a). The manpage of aCC says:
>  EXTERNAL INFLUENCES
>     Environment Variables
>       [...]
>       UNIX95 or UNIX_STD specify the XPG4 behavior for c89(1) and c99(1).
>       -D_XOPEN_UNIX is also set.  UNIX_STD must be set to 1995, 1998 or
>       2003.  Both these variables cause an appropriate object file to be
>       linked into executables in order to customize libc to match ISO/IEC
>       9899:1990/Amendment 1:1995 (1995) and the C++ and C99 Standards for
>       the various wide char (1998) or other C99 libc functions (2003).
>       NOTE: 2003 is only available on HP-UX 11.31.

So one must at least do "export UNIX_STD=1998".

I am quite certain that other parts of Python are affected too.

The safest bet would be actually to test wcsftime at configure time wether the output is fine and have this env var set in the Makefile, unfortunately, this will only work for GNU make. Alternatively, a warning at the very end of the configure run has to be printed to export this env var.

If done, test_strftime and test_teststrptime will pass flawlessly.

----------
components: Library (Lib)
messages: 323512
nosy: michael-o
priority: normal
severity: normal
status: open
title: [SOLUTION] strftime fails on HP-UX
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34402>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:39:30 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 12:39:30 +0000
Subject: [issue34402] [SOLUTION] strftime fails on HP-UX
In-Reply-To: <1534250217.83.0.56676864532.issue34402@psf.upfronthosting.co.za>
Message-ID: <1534250370.43.0.56676864532.issue34402@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

The worst thing about wcsftime(3) is that it silently fails by not writing to output buffer. timemodule.c allocates more and more memory and then gives up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34402>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:40:23 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 12:40:23 +0000
Subject: [issue34401] [solution] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534250423.09.0.56676864532.issue34401@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
title: Make test_gdb work on HP-UX -> [solution] Make test_gdb work on HP-UX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:45:53 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 12:45:53 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1534250753.03.0.56676864532.issue18709@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

These Python versions no longer receive security updates. Please update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:49:15 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Aug 2018 12:49:15 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534250955.94.0.56676864532.issue34393@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

There are too many types of compression for this to be built-in to json. There's zlib, gzip, bzip, zip, and no doubt dozens of others. How would we chose one, or several? Which to leave out? How to pass in the many parameters to all of these compression algorithms?

As rushter points out, if your current compression library only compresses a file on disk, you should switch to a streaming compressor, like zlib.compressobj or gzip.GzipFile.

If Google Storage won't let you pass a streaming compressor as a parameter, then that should be a feature request to Google. I suspect you can actually pass a streaming compressor to it, but I have't investigated their API.

In any event, compression does not belong in the json library.

----------
nosy: +eric.smith
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Tue Aug 14 08:57:12 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 12:57:12 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
Message-ID: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

Running from 3.7 branch on HP-UX 11.31 ia64, 32 bit, big endian.
The test output is:
> Re-running failed tests in verbose mode
> Re-running test 'test_utf8_mode' in verbose mode
> test_cmd_line (test.test_utf8_mode.UTF8ModeTests) ... FAIL
> test_env_var (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_filesystemencoding (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_io (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_io_encoding (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_locale_getpreferredencoding (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_optim_level (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_posix_locale (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_stdio (test.test_utf8_mode.UTF8ModeTests) ... ok
> test_xoption (test.test_utf8_mode.UTF8ModeTests) ... ok
> 
> ======================================================================
> FAIL: test_cmd_line (test.test_utf8_mode.UTF8ModeTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 230, in test_cmd_line
>     check('utf8=0', [c_arg], LC_ALL='C')
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 223, in check
>     self.assertEqual(args, ascii(expected), out)
> AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
> - ['h\xc3\xa9\xe2\x82\xac']
> + ['h\udcc3\udca9\udce2\udc82\udcac']
>  : roman8:['h\xc3\xa9\xe2\x82\xac']
> 
> ----------------------------------------------------------------------
> Ran 10 tests in 2.595s
> 
> FAILED (failures=1)
> test test_utf8_mode failed
> 1 test failed again:
>     test_utf8_mode
> 
> == Tests result: FAILURE then FAILURE ==
> 
> 1 test failed:
>     test_utf8_mode
> 
> 1 re-run test:
>     test_utf8_mode
> 
> Total duration: 7 sec 265 ms
> Tests result: FAILURE then FAILURE
> Makefile:1066: recipe for target 'test' failed
> gmake: *** [test] Error 2
> 

I tried to understand the issue, but my Python knowledge is too low, especially I do not understand by a byte array "arg = 'h\xe9\u20ac'.encode('utf-8')" is passed as one arg to the forked process.

I highly assume that this is related to the non-standard, default character encoding on HP-UX: https://en.wikipedia.org/wiki/HP_Roman#HP_Roman-8 (roman8).

A stupid 8 bit encoding. The very same snippet on FreeBSD says:
> $ LC_ALL=C python3.6 test_utf8.py
> US-ASCII:[]

Willing to test and modify if someone tells what to do.

----------
components: Library (Lib), Tests
messages: 323516
nosy: michael-o
priority: normal
severity: normal
status: open
title: test_utf8_mode.test_cmd_line() fails on HP-UX due to false assumptions
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:16:02 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 13:16:02 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534252562.69.0.56676864532.issue34399@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:16:41 2018
From: report at bugs.python.org (liad)
Date: Tue, 14 Aug 2018 13:16:41 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534252601.21.0.56676864532.issue34393@psf.upfronthosting.co.za>


liad <liad at mailinator.com> added the comment:

True there are endless versions of compression just like there are endless version of file formats. Still there are some build-ins like conversion from string to json. For example you don't support of json to orc file. Same argument could have been raise here : how would we choose which conversions to also? Still a choice has been made and some basic conversion behavior is supported.

You are claiming that it's all or nothing which I don't think is the right approach.

Many are now moving their storage into cloud platforms. The storage is as it sound - storage. It doesn't offer any programming service what you stream is what you will have. Streaming huge files without compression = bleeding money for no reason. Saving the files to disk, compress them and then upload them might be very slow and also the idea is having machine with big memory and low storage - if you have to save huge files localy you'll also need big storage which costs more money.

Regarding google there is a pending request for who chooses to use GoogleCloudPlatform package but not all use that. 

https://github.com/GoogleCloudPlatform/google-cloud-python/issues/5791

Not to mention that there are dozes of other service providers. So even if Google will support it - this doesn't give answer to storage service providers 

I still claim that this is a basic legit request and can be handled by the json.dump() function.

gzip is fine. It also supported by pandas extension and is well known.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:16:53 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 14 Aug 2018 13:16:53 +0000
Subject: [issue33451] Start pyc file lock the file
In-Reply-To: <1525898638.9.0.682650639539.issue33451@psf.upfronthosting.co.za>
Message-ID: <1534252613.58.0.56676864532.issue33451@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

All PRs have been merged (commit message from the 3.6 branch doesn't listed here but PR 7889 has been merged in https://github.com/python/cpython/commit/8f8ad2c38237caf5ee48f690289e8c811d245455) Closing this as 'fixed'. Please reopen if this issue needs to stay open.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33451>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:20:34 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 13:20:34 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534252834.86.0.56676864532.issue34399@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8242

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:36:49 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 13:36:49 +0000
Subject: [issue34404] test_time incorrectly defined
Message-ID: <1534253809.16.0.56676864532.issue34404@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

I see a test failure on HP-UX:
> test_negative (test.test_time.TestStrftime4dyear) ... FAIL
> ======================================================================
> FAIL: test_negative (test.test_time.TestStrftime4dyear)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/var/osipovmi/cpython/Lib/test/test_time.py", line 687, in test_negative
>     return super().test_negative()
>   File "/var/osipovmi/cpython/Lib/test/test_time.py", line 713, in test_negative
>     self.assertEqual(self.yearstr(-1), self._format % -1)
> AssertionError: '-0001' != '-001'
> - -0001
> ?  -
> + -001

The bug is in the test class, not cause by HP-UX.
Lib/test/test_time.py:713 says "self.assertEqual(self.yearstr(-1), self._format % -1)" where self._format is set in line 654 to "_format = '%04d'" because
> Python 3.7.0+ (heads/3.7-dirty:ea8835fb30, Aug 14 2018, 14:44:19) [C] on hp-ux11
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import time
> >>> time.strftime('%Y', (1,) + (0,) * 8)
> '0001'

Unfortunately, the zero padding in printf() applies to the entire string length. So
> >>> "%+04d" % -1
> '-001'

on HP-UX, Linux and FreeBSD.

The format string must add an additional zero for negative numbers.

----------
components: Tests
messages: 323519
nosy: michael-o
priority: normal
severity: normal
status: open
title: test_time incorrectly defined
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34404>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:43:58 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Aug 2018 13:43:58 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534254238.09.0.56676864532.issue34393@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

If you really want to see this added to Python, then I suggest you put together a proposal on what the API would be, what options you would or wouldn't support, and post that on python-ideas. But I'll warn you that your chances of success are low.

Your better chance of success is to write a wrapper around json and whatever compression library you want to use, and post that to PyPI to see if it gets traction. I believe you can do what you want without a temporary disk file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Tue Aug 14 09:52:47 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 13:52:47 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
Message-ID: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

1.0.2p and 1.1.0i were released today. Please update the Windows and macOS installers.

----------
components: Windows, macOS
messages: 323521
nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade to OpenSSL 1.1.0i / 1.0.2p
type: security
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Aug 14 10:09:12 2018
From: report at bugs.python.org (liad)
Date: Tue, 14 Aug 2018 14:09:12 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534255752.47.0.56676864532.issue34393@psf.upfronthosting.co.za>


liad <liad at mailinator.com> added the comment:

I'm sure I will find a work-around.
I posted it for other who will face the same issue as me.
There are many who uses cloud storage but not many work with PB size files. This will likely to change in the near future as more and more company start to process huge amount of data.

I'm not sure what you mean by designing an API. I think you sale it up for no need. It simply add of optional parameter which will trigger compression of gzip. That's it. Nothing sophisticated. 

Something like:

json.dumps(data, outfile, sort_keys=True,compression='gzip')

compression - Optional. A string representing the compression to use in the output. Allowed values are ?gzip?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Tue Aug 14 10:19:31 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 14 Aug 2018 14:19:31 +0000
Subject: [issue34404] test_time incorrectly defined
In-Reply-To: <1534253809.16.0.56676864532.issue34404@psf.upfronthosting.co.za>
Message-ID: <1534256371.71.0.56676864532.issue34404@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

The proper format for int < 0 must be "%05d".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34404>
_______________________________________

From report at bugs.python.org  Tue Aug 14 10:40:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Aug 2018 14:40:36 +0000
Subject: [issue34390] arparse.ArgumentParser misparses list arguments followed
 by undefined arguments
In-Reply-To: <1534130705.52.0.56676864532.issue34390@psf.upfronthosting.co.za>
Message-ID: <1534257636.19.0.56676864532.issue34390@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34390>
_______________________________________

From report at bugs.python.org  Tue Aug 14 10:52:33 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 14:52:33 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534258353.57.0.56676864532.issue34399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset e3228a3f44e382b6cdd2b5e001b651347013a7d3 by Christian Heimes (Miss Islington (bot)) in branch '3.7':
bpo-34399: 2048 bits RSA keys and DH params (GH-8762) (GH-8763)
https://github.com/python/cpython/commit/e3228a3f44e382b6cdd2b5e001b651347013a7d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 10:53:06 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 14:53:06 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534258386.94.0.56676864532.issue34399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 1f34aece28d143edb94ca202e661364ca394dc8c by Christian Heimes in branch '2.7':
[2.7] bpo-34399: 2048 bits RSA keys and DH params (GH-8762) (GH-8765)
https://github.com/python/cpython/commit/1f34aece28d143edb94ca202e661364ca394dc8c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Tue Aug 14 10:56:35 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 14 Aug 2018 14:56:35 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1534258595.34.0.56676864532.issue32947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 2a4ee8aa01d61b6a9c8e9c65c211e61bdb471826 by Christian Heimes in branch '3.6':
bpo-32947: Fixes for TLS 1.3 and OpenSSL 1.1.1 (GH-8761)
https://github.com/python/cpython/commit/2a4ee8aa01d61b6a9c8e9c65c211e61bdb471826


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Tue Aug 14 11:04:48 2018
From: report at bugs.python.org (Alisue Lambda)
Date: Tue, 14 Aug 2018 15:04:48 +0000
Subject: [issue34406] Type in documentation
Message-ID: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>


New submission from Alisue Lambda <lambdalisue at hashnote.net>:

https://docs.python.org/3.8/using/windows.html#removing-the-max-path-limitation

Current
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem at LongPathsEnabled

Should be
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled

----------
assignee: docs at python
components: Documentation
messages: 323527
nosy: Alisue Lambda, docs at python
priority: normal
severity: normal
status: open
title: Type in documentation
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Tue Aug 14 11:04:57 2018
From: report at bugs.python.org (Alisue Lambda)
Date: Tue, 14 Aug 2018 15:04:57 +0000
Subject: [issue34406] Typo in documentation
In-Reply-To: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>
Message-ID: <1534259097.23.0.56676864532.issue34406@psf.upfronthosting.co.za>


Change by Alisue Lambda <lambdalisue at hashnote.net>:


----------
title: Type in documentation -> Typo in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Tue Aug 14 11:25:43 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 14 Aug 2018 15:25:43 +0000
Subject: [issue34398] Docs search does not index glossary
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534260343.01.0.56676864532.issue34398@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Hmm the search is built-in functionality in Sphinx, and I don't think we have any way to control or customize that.

----------
nosy: +Mariatta
resolution:  -> third party
status: open -> pending
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Tue Aug 14 11:58:55 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Tue, 14 Aug 2018 15:58:55 +0000
Subject: [issue34398] Docs search does not index glossary
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534262335.11.0.56676864532.issue34398@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

Good discovery. The glossary uses the RST glossary directive.
https://github.com/python/cpython/blob/master/Doc/glossary.rst

The Sphinx docs have a glossary, which is indexed by its search.
http://www.sphinx-doc.org/en/master/search.html?q=domain

So maybe Sphinx already has the functionality we require. Perhaps it's simply a matter of configuring the Python docs to use it. (This is optimism.)

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Tue Aug 14 12:13:59 2018
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Aug 2018 16:13:59 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534263239.89.0.56676864532.issue34405@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I've pushed the new sources for the Windows build, and am about to do the new binaries.

If someone else gets to updating the references in the CPython repo before I do, that's fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Tue Aug 14 14:18:04 2018
From: report at bugs.python.org (Maksym Shalenyi (Enkidulan))
Date: Tue, 14 Aug 2018 18:18:04 +0000
Subject: [issue34407] datetime.time.isoformat function has inconsistent
 behavior with timezone
Message-ID: <1534270684.14.0.56676864532.issue34407@psf.upfronthosting.co.za>


New submission from Maksym Shalenyi (Enkidulan) <supamaxy at gmail.com>:

In some cases datetime.time.isoformat shows timezone info, but in some does not. Consider the example below.

import datetime
import pytz

t = dict(hour=12, minute=31, second=21, microsecond=213456)

# `datetime.time.isoformat` has inconsistent behavior. Some of printed has timezone, but others does not.
print(datetime.time(tzinfo=pytz.timezone('Asia/Seoul'), **t).isoformat())
print(datetime.time(tzinfo=pytz.timezone('Etc/GMT-9'), **t).isoformat())
print(datetime.time(tzinfo=pytz.timezone('Australia/Sydney'), **t).isoformat())
print(datetime.time(tzinfo=pytz.timezone('Etc/UTC'), **t).isoformat())
# output:
# 12:31:21.213456
# 12:31:21.213456+09:00
# 12:31:21.213456
# 12:31:21.213456+00:00



# `datetime.time.isoformat` is inconsistent with `datetime.datetime.isoformat`. `datetime` objects always shows tz information when tz is present.
d = dict(year=2018, month=2, day=2, **t)
print(datetime.datetime(tzinfo=pytz.timezone('Asia/Seoul'), **d).isoformat())
print(datetime.datetime(tzinfo=pytz.timezone('Etc/GMT-9'), **d).isoformat())
print(datetime.datetime(tzinfo=pytz.timezone('Australia/Sydney'), **d).isoformat())
print(datetime.datetime(tzinfo=pytz.timezone('Etc/UTC'), **d).isoformat())
# output:
# 2018-02-02T12:31:21.213456+08:28
# 2018-02-02T12:31:21.213456+09:00
# 2018-02-02T12:31:21.213456+10:05
# 2018-02-02T12:31:21.213456+00:00

----------
components: ctypes
messages: 323531
nosy: Maksym Shalenyi (Enkidulan)
priority: normal
severity: normal
status: open
title: datetime.time.isoformat function has inconsistent behavior with timezone
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34407>
_______________________________________

From report at bugs.python.org  Tue Aug 14 14:30:15 2018
From: report at bugs.python.org (ppperry)
Date: Tue, 14 Aug 2018 18:30:15 +0000
Subject: [issue19050] [Windows] fflush called on pointer to potentially closed
 file
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1534271415.08.0.56676864532.issue19050@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: [Python 2, Windows] fflush called on pointer to potentially closed file -> [Windows] fflush called on pointer to potentially closed file

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Tue Aug 14 14:32:33 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Aug 2018 18:32:33 +0000
Subject: [issue34356] Add support for args and kwargs in logging.conf
In-Reply-To: <1533715378.01.0.56676864532.issue34356@psf.upfronthosting.co.za>
Message-ID: <1534271553.45.0.56676864532.issue34356@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There aren't any changes planned to the fileConfig code, other than bug fixes. If you need improved functionality, you can use dictConfig, which already supports improved configuration features when compared to fileConfig.

The fileConfig API was present when the logging package was first added to Python, and dictConfig is a later enhancement (PEP 391).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34356>
_______________________________________

From report at bugs.python.org  Tue Aug 14 15:05:38 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 14 Aug 2018 19:05:38 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1534273538.75.0.56676864532.issue11192@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

The original error reported was fixed by AIX - in AIX 6.1.

It will remain unresolved in AIX 5.3.

There are currently two other errors in test_socket.

FAIL: test_getnameinfo_ipv6_scopeid_symbolic (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.7/Lib/test/test_socket.py", line 1649, in test_getnameinfo_ipv6_scopeid_symbolic
    self.assertEqual(nameinfo, ('ff02::1de:c0:face:8d%' + test_interface, '1234'))
AssertionError: Tuples differ: ('ff02::1de:c0:face:8d', '1234') != ('ff02::1de:c0:face:8d%en0', '1234')

First differing element 0:
'ff02::1de:c0:face:8d'
'ff02::1de:c0:face:8d%en0'

- ('ff02::1de:c0:face:8d', '1234')
+ ('ff02::1de:c0:face:8d%en0', '1234')
?                       ++++

I assume the capital D in the argument in the test:
        sockaddr = ('ff02::1de:c0:face:8D', 1234, 0, ifindex)  # Note capital letter `D`.

is meant to trigger getting the IPv6 zoneinfo based on ifindex.

AIX does have a routine to strip zoneinfo off an IPv6 address, but the getnameinfo() and getaddrinfo() do not support this.

I can create a new issue specifically for IPv6 zone id issue, or I can add a PR here. 

Please advise (the PR is merely adding "skipUnless" logic to test_socket.py.

ERROR: test_getaddrinfo_ipv6_scopeid_symbolic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Tue Aug 14 15:11:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 19:11:41 +0000
Subject: [issue34406] Typo in documentation
In-Reply-To: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>
Message-ID: <1534273901.84.0.56676864532.issue34406@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Isn't this saying that LongPathsEnabled is a value on the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Tue Aug 14 15:12:54 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 19:12:54 +0000
Subject: [issue34406] Typo in documentation
In-Reply-To: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>
Message-ID: <1534273974.98.0.56676864532.issue34406@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am not sure how people usually refer to the Windows register but this seems that the current line is differentiating from the path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

and the value

LongPathsEnabled

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Tue Aug 14 15:21:14 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 19:21:14 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534274474.87.0.56676864532.issue34381@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

You can run all the tests except the ones that require external network (like SSL for sockets) using:

./python -m test -uall,network

or you can exclude tests using the -x flag.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Tue Aug 14 15:21:47 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 19:21:47 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534274507.9.0.56676864532.issue34381@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg323536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Tue Aug 14 15:21:50 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 19:21:50 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534274510.02.0.56676864532.issue34381@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

You can run all the tests except the ones that require external network (like SSL for sockets) using:

./python -m test -uall,-network

or you can exclude tests using the -x flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Tue Aug 14 16:09:38 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 20:09:38 +0000
Subject: [issue34408] possible null pointer dereference in pystate.c
Message-ID: <1534277378.73.0.56676864532.issue34408@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

The problem occurs here:

https://github.com/python/cpython/blob/master/Python/pystate.c#L185

If _PyRuntime.interpreters.next_id < 0 then interp is set to NULL and it will be dereferenced later:

interp

----------
components: Interpreter Core
messages: 323538
nosy: pablogsal
priority: normal
severity: normal
status: open
title: possible null pointer dereference in pystate.c
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34408>
_______________________________________

From report at bugs.python.org  Tue Aug 14 16:11:14 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 20:11:14 +0000
Subject: [issue34408] possible null pointer dereference in pystate.c
In-Reply-To: <1534277378.73.0.56676864532.issue34408@psf.upfronthosting.co.za>
Message-ID: <1534277474.32.0.56676864532.issue34408@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8243
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34408>
_______________________________________

From report at bugs.python.org  Tue Aug 14 16:43:28 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Aug 2018 20:43:28 +0000
Subject: [issue34392] Add sys.isinterned()
In-Reply-To: <1534155873.32.0.56676864532.issue34392@psf.upfronthosting.co.za>
Message-ID: <1534279408.15.0.56676864532.issue34392@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I agree with Christian; this is an implementation detail so it should be flagged as private/internal somehow.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34392>
_______________________________________

From report at bugs.python.org  Tue Aug 14 17:27:40 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 14 Aug 2018 21:27:40 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1534282060.97.0.56676864532.issue34397@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I agree there's pointless code now, but don't understand why the patch replaces it with mysterious asserts.  For example, what's the point of this?

assert(Py_SIZE(a) <= PY_SSIZE_T_MAX / sizeof(PyObject*));
assert(Py_SIZE(b) <= PY_SSIZE_T_MAX / sizeof(PyObject*));

The invariant that needs to be maintained is that the number of elements is no larger than PY_SSIZE_T_MAX, so the _relevant_ thing to assert is:

assert(Py_SIZE(a) + Py_SIZE(b) <= PY_SSIZE_T_MAX);

That in turn cries out for an explanation of why it must be true.  The asserts actually in the patch are part of that explanation, but on their own appear to be coming from Mars.  They're missing the conclusion, and rely on further unstated subtleties.

Suggest adding a comment where the structs are defined, like:

"""
Note:  Python's memory allocators return at most PY_SSIZE_T_MAX bytes.  Therefore a vector of PyObject* can contain no more than PY_SSIZE_T_MAX / sizeof(PyObject*) elements.  In particular, a PyObject* consumes at least 2 bytes, so a vector can contain no more than PY_SSIZE_T_MAX / 2 elements.  Code freely relies on that.

#if SIZEOF_VOID_P < 2
#   error "size of pointer less than 2 bytes?!"
#endif
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Tue Aug 14 17:37:03 2018
From: report at bugs.python.org (Tim Peters)
Date: Tue, 14 Aug 2018 21:37:03 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1534282623.78.0.56676864532.issue34397@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Bah - the relevant thing to assert is really

assert((size_t)Py_SIZE(a) + (size_t)Py_SIZE(b) <= (size_t)PY_SSIZE_T_MAX);

C sucks ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Tue Aug 14 18:02:17 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 22:02:17 +0000
Subject: [issue33930] Segfault with deep recursion into object().__dir__
In-Reply-To: <1529580477.24.0.56676864532.issue33930@psf.upfronthosting.co.za>
Message-ID: <1534284137.03.0.56676864532.issue33930@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33930>
_______________________________________

From report at bugs.python.org  Tue Aug 14 18:02:37 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Aug 2018 22:02:37 +0000
Subject: [issue32485] Multiprocessing dict sharing between forked processes
In-Reply-To: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>
Message-ID: <1534284157.02.0.56676864532.issue32485@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Tue Aug 14 19:11:20 2018
From: report at bugs.python.org (mkurnikov)
Date: Tue, 14 Aug 2018 23:11:20 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
Message-ID: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>


New submission from mkurnikov <maxim.kurnikov at gmail.com>:

Suppose I have two dataclasses:

@dataclass
class NestedDataclass(object):
    name: str
    options: Dict[str, Any] = field(default_factory=dict)

@dataclass
class RootDataclass(object):
    nested_list: List[NestedDataclass]

I want a dict under the key "options" to be merged in the NestedDataclass dict in the dataclasses.asdict(root_dcls_instance). 

For that, according to docs, I need to specify dict_factory= for dataclasses.asdict() function. 

The problem is that, according to the implementation, when this function "meets" dataclass, there's no way to customize how result dict will be built. Dataclass itself is never passed to the function. 

    if _is_dataclass_instance(obj):
        result = []
        for f in fields(obj):
            value = _asdict_inner(getattr(obj, f.name), dict_factory)
            result.append((f.name, value))
        return dict_factory(result)

Yes, I can catch "result" obj (what I did in the end):

def root_dataclass_dict_factory(obj):
    if isinstance(obj, list):
        dataclass_dict = dict(obj)
        if 'options' in dataclass_dict:
            dataclass_dict.update(dataclass_dict.pop('options'))

    return dict(obj)

The problem is that type of the dataclass is lost for the list, and if by any chance later I'll have "options" key in the RootDataclass, there's no way for me to distinguish between them cleanly. 

Other solution is to iterate over the RootDataclass dictionary, follow the path to the NestedDataclass and change dictionary there, but it even uglier. 

Would be nice to be able to somehow hook into the field traversal of the dataclass instance.

----------
components: Library (Lib)
messages: 323542
nosy: mkurnikov
priority: normal
severity: normal
status: open
title: Add a way to customize iteration over fields in asdict() for the nested dataclasses
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Tue Aug 14 19:31:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Aug 2018 23:31:22 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1534289482.5.0.56676864532.issue34409@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Could you show some example dataclass instances? Also, show the output you get with asdict(), and show what output you'd like to get instead.

I'm not sure I understand it correctly from the description you've given.

Thanks!

----------
nosy: +eric.smith
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Tue Aug 14 19:31:34 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Aug 2018 23:31:34 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1534289494.98.0.56676864532.issue34409@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Tue Aug 14 19:53:57 2018
From: report at bugs.python.org (mkurnikov)
Date: Tue, 14 Aug 2018 23:53:57 +0000
Subject: [issue34409] Add a way to customize iteration over fields in asdict()
 for the nested dataclasses
In-Reply-To: <1534288280.15.0.56676864532.issue34409@psf.upfronthosting.co.za>
Message-ID: <1534290837.91.0.56676864532.issue34409@psf.upfronthosting.co.za>


mkurnikov <maxim.kurnikov at gmail.com> added the comment:

from pprint import pprint
from typing import List, Any, Dict

import dataclasses
from dataclasses import field


def service_interface_dict_factory(obj: Any) -> Dict[str, Any]:
    print(type(obj)) # <- type(obj) here is a list, but there's no way to understand whether it's a ServiceInterface or
    # InputVar except for looking for the presence of certain keys which is not very convenient
    return dict(obj)


@dataclasses.dataclass
class InputVar(object):
    name: str
    required: bool = False
    options: Dict[str, Any] = field(default_factory=dict)


@dataclasses.dataclass
class ServiceInterface(object):
    input: List[InputVar] = field(default_factory=list)


if __name__ == '__main__':
    inputvar_inst = InputVar(name='myinput',
                             required=False,
                             options={'default': 'mytext'})
    interface = ServiceInterface(input=[inputvar_inst])

    outdict = dataclasses.asdict(interface, dict_factory=service_interface_dict_factory)
    print('outdict', end=' ')
    pprint(outdict)

    # prints:
    # outdict {'input': [{'name': 'myinput',
    #         'options': {'default': 'mytext'},
    #         'required': False}]}

    # desirable output
    # {'input': [{
    #     'name': 'myinput',
    #     'required': False,
    #     'default': 'mytext'
    # }]}
    # "default" key moved to the root of the dictionary (inside list)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34409>
_______________________________________

From report at bugs.python.org  Tue Aug 14 20:13:57 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 15 Aug 2018 00:13:57 +0000
Subject: [issue34392] Add sys.isinterned()
In-Reply-To: <1534155873.32.0.56676864532.issue34392@psf.upfronthosting.co.za>
Message-ID: <1534292037.91.0.56676864532.issue34392@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Agreed it should be non-public, but can we please call it sys._is_interned()?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34392>
_______________________________________

From report at bugs.python.org  Tue Aug 14 22:08:28 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Wed, 15 Aug 2018 02:08:28 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
Message-ID: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>


New submission from Carlo Rosati <crosati777 at icloud.com>:

Hello, 

When I run the attached code, I encounter a segmentation fault.

Thanks,
Carlo

----------
files: 3.py
messages: 323546
nosy: carlorosati
priority: normal
severity: normal
status: open
title: Segfault/TimeoutError: itertools.tee of multiprocessing.pool.imap_unordered
type: crash
versions: Python 2.7, Python 3.7
Added file: https://bugs.python.org/file47750/3.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Tue Aug 14 22:40:53 2018
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 15 Aug 2018 02:40:53 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1534300853.46.0.56676864532.issue34370@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

I just committed http://core.tcl.tk/tk/info/26a029b4a88ff97f, which fixes the scrolling issue in Tk. Running the test scripts here indicate the behavior is now correct; clicking several pixels below the bottom part of the scroll button causes the scroll to jump, instead of smoothly scrolling. (One must click the scroll button directly for smooth scrolling, which is the expected behavior.) The fix involved removing support for a small scroll button variant, which was causing the confusion; by sticking with a single variant, the normal size scroller, the behavior is correct and consistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:27:29 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Aug 2018 06:27:29 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534314449.11.0.56676864532.issue34400@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 7c4ab2afb17b99eb3f61f9c73cbd548b5e0ad2c0 by Benjamin Peterson (Zackery Spytz) in branch 'master':
closes bpo-34400: Fix undefined behavior in parsetok(). (GH-4439)
https://github.com/python/cpython/commit/7c4ab2afb17b99eb3f61f9c73cbd548b5e0ad2c0


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:27:54 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 06:27:54 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534314474.35.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:28:02 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 06:28:02 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534314482.26.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:28:10 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 06:28:10 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534314490.46.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8246

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:51:15 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 06:51:15 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534315875.62.0.56676864532.issue34400@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2275b773ebfacb94f6a9c81d6a8b9d54771a68e8 by Miss Islington (bot) in branch '3.7':
closes bpo-34400: Fix undefined behavior in parsetok(). (GH-4439)
https://github.com/python/cpython/commit/2275b773ebfacb94f6a9c81d6a8b9d54771a68e8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:57:55 2018
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Aug 2018 06:57:55 +0000
Subject: [issue34406] Typo in documentation
In-Reply-To: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>
Message-ID: <1534316275.35.0.56676864532.issue34406@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

For what its worth, window's reg command also makes a distinction between the registry key and value:


C:\Users\ammar>reg.exe QUERY HKLM\Software\Microsoft\.NETFramework\Enable64Bit
ERROR: The system was unable to find the specified registry key or value.

C:\Users\ammar>reg.exe QUERY HKLM\Software\Microsoft\.NETFramework /V Enable64Bit

HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework
    Enable64Bit    REG_DWORD    0x1


Maybe it can just be phrased as something like, "set the registry value LongPathsEnabled in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem"

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Wed Aug 15 02:59:13 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 06:59:13 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534316353.93.0.56676864532.issue34400@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 00aebabc7139741fadfe877372c733a2160c7dbd by Miss Islington (bot) in branch '2.7':
closes bpo-34400: Fix undefined behavior in parsetok(). (GH-4439)
https://github.com/python/cpython/commit/00aebabc7139741fadfe877372c733a2160c7dbd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:07:31 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 15 Aug 2018 07:07:31 +0000
Subject: [issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes
In-Reply-To: <1526648438.42.0.682650639539.issue33570@psf.upfronthosting.co.za>
Message-ID: <1534316851.19.0.56676864532.issue33570@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 3e630c541b35c96bfe5619165255e559f577ee71 by Christian Heimes in branch '3.6':
bpo-33570: TLS 1.3 ciphers for OpenSSL 1.1.1 (GH-6976) (GH-8760)
https://github.com/python/cpython/commit/3e630c541b35c96bfe5619165255e559f577ee71


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33570>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:08:31 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 07:08:31 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534316911.87.0.56676864532.issue34400@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 981aa46dce926ce54ec1a2adbb73d1f405ef66ff by Miss Islington (bot) in branch '3.6':
closes bpo-34400: Fix undefined behavior in parsetok(). (GH-4439)
https://github.com/python/cpython/commit/981aa46dce926ce54ec1a2adbb73d1f405ef66ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:16:31 2018
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Aug 2018 07:16:31 +0000
Subject: [issue34398] Docs search does not index glossary
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534317391.84.0.56676864532.issue34398@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Hmm, are you sure its not indexed? Look at this search result: https://docs.python.org/3/search.html?q=__slots__

The glossary page shows up in the results for me.

Or are you suggesting that if you search for a term defined in the glossary, it be prominently shown at the top of the search page?

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:24:11 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 15 Aug 2018 07:24:11 +0000
Subject: [issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes
In-Reply-To: <1526648438.42.0.682650639539.issue33570@psf.upfronthosting.co.za>
Message-ID: <1534317851.61.0.56676864532.issue33570@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8247

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33570>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:24:53 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 15 Aug 2018 07:24:53 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534317893.08.0.56676864532.issue34399@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 5e9551b4090095fa94cc2dd4afa5bd2177aa3d09 by Christian Heimes in branch '3.6':
[3.6] bpo-34399: 2048 bits RSA keys and DH params (GH-8762) (GH-8764)
https://github.com/python/cpython/commit/5e9551b4090095fa94cc2dd4afa5bd2177aa3d09


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:43:41 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 15 Aug 2018 07:43:41 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1534319021.83.0.56676864532.issue34399@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:45:04 2018
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Aug 2018 07:45:04 +0000
Subject: [issue34372] Compiler could output more accurate line numbers
In-Reply-To: <1533913344.46.0.56676864532.issue34372@psf.upfronthosting.co.za>
Message-ID: <1534319104.98.0.56676864532.issue34372@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Note that even just adding an extra arithmetic in your first expression breaks the line numbers:

>>> code = """(                                    
... [                                              
...   call1(),                                     
...   call2()                                      
... ]                                              
... + call3()                                      
... * call4()                                      
... + call5()                                      
... )"""                                           
>>> dis.dis(code)                                  
  8           0 LOAD_NAME                0 (call1) 
              2 CALL_FUNCTION            0         
              4 LOAD_NAME                1 (call2) 
              6 CALL_FUNCTION            0         
              8 BUILD_LIST               2         
             10 LOAD_NAME                2 (call3) 
             12 CALL_FUNCTION            0         
             14 LOAD_NAME                3 (call4) 
             16 CALL_FUNCTION            0         
             18 BINARY_MULTIPLY                    
             20 BINARY_ADD                         
             22 LOAD_NAME                4 (call5) 
             24 CALL_FUNCTION            0         
             26 BINARY_ADD                         
             28 RETURN_VALUE                       

The closest existing bug to this would be issue 12458, specifically with Serhiy's last comment.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:49:02 2018
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Aug 2018 07:49:02 +0000
Subject: [issue34372] Parenthesized expression has incorrect line numbers
In-Reply-To: <1533913344.46.0.56676864532.issue34372@psf.upfronthosting.co.za>
Message-ID: <1534319342.26.0.56676864532.issue34372@psf.upfronthosting.co.za>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
title: Compiler could output more accurate line numbers -> Parenthesized expression has incorrect line numbers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________

From report at bugs.python.org  Wed Aug 15 03:51:48 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 15 Aug 2018 07:51:48 +0000
Subject: [issue34406] Typo in documentation
In-Reply-To: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>
Message-ID: <1534319508.61.0.56676864532.issue34406@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Wed Aug 15 04:08:48 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 15 Aug 2018 08:08:48 +0000
Subject: [issue34398] Docs search does not index glossary items
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534320528.62.0.56676864532.issue34398@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

You're right! Thank you. However, there's still a problem. A user searches for a technical term, and the carefully written glossary entry defining it does not appear.

For my search term (iterable), there was a single entry with a link to the Glossary page, whose associated text was simply the first few entries in the glossary.
===
Glossary
...active shell when entering code for an indented code block or within a pair of matching left and right delimiters (parentheses, square brackets or curly braces). 2to3 A tool that tries to convert Python 2.x code to Pyt...
===

On a related matter. Sphinx provides an anchor, used for internal navigation with the glossary. But it doesn't provide a permalink to that anchor. Compare 
https://docs.python.org/3.5/glossary.html#term-iterable
https://docs.python.org/3.5/reference/compound_stmts.html#with

I think there's a real problem, and that my initial diagnosis was wrong. So I've changed the issue title slightly. (I hope you don't mind.)

The problem is, perhaps, that it is the glossary page that is indexed, rather than the glossary items. Another fix would be, as you suggest, pop up at top of results page a glossary item.

----------
title: Docs search does not index glossary -> Docs search does not index glossary items

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Wed Aug 15 04:42:32 2018
From: report at bugs.python.org (Vlad Tudorache)
Date: Wed, 15 Aug 2018 08:42:32 +0000
Subject: [issue34370] Tkinter scroll issues on macOS
In-Reply-To: <1533895636.89.0.56676864532.issue34370@psf.upfronthosting.co.za>
Message-ID: <1534322552.16.0.56676864532.issue34370@psf.upfronthosting.co.za>


Vlad Tudorache <tudorache.vlad at gmail.com> added the comment:

It seems that Kevin's fix solves the issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34370>
_______________________________________

From report at bugs.python.org  Wed Aug 15 05:05:56 2018
From: report at bugs.python.org (Jens Troeger)
Date: Wed, 15 Aug 2018 09:05:56 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1534323956.6.0.56676864532.issue24218@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

@David, any thoughts on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Wed Aug 15 06:03:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 15 Aug 2018 10:03:52 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1534327432.67.0.56676864532.issue34384@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e0b5b2096ead4cc094a129ce7602ac5c0e998086 by Berker Peksag in branch 'master':
bpo-34384: Fix os.readlink() on Windows (GH-8740)
https://github.com/python/cpython/commit/e0b5b2096ead4cc094a129ce7602ac5c0e998086


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Wed Aug 15 06:45:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Aug 2018 10:45:03 +0000
Subject: [issue34372] Parenthesized expression has incorrect line numbers
In-Reply-To: <1533913344.46.0.56676864532.issue34372@psf.upfronthosting.co.za>
Message-ID: <1534329903.63.0.56676864532.issue34372@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________

From report at bugs.python.org  Wed Aug 15 07:01:09 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Aug 2018 11:01:09 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
 setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1534330869.85.0.56676864532.issue17180@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I am looking at this.

Based on the comments from a historical perspective - copyfile() needs to be calling the copy_mode function before any copying actually occurs.

As the dest is already open for writing it does not matter (on posix)
what mode it has later on.

Question: in copystat() there is a block that talks about chown() in the comments but in the code it only seems to be accessing chmod(). Should there (also) be a call to chown "if _SUPER"?

_SUPER = _POSIX and os.geteuid() == 0

basically - mode becomes:

    # remove setuid, setgid and sticky bits if _POSIX and not _SUPER
    mode = stat.S_IMODE(st.st_mode) & _REMOVE_HARMFUL_MASK if _POSIX and not _SUPER else stat.S_IMODE(st.st_mode)

Comments?

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Aug 15 07:02:01 2018
From: report at bugs.python.org (Michael Felt)
Date: Wed, 15 Aug 2018 11:02:01 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
 setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1534330921.97.0.56676864532.issue17180@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

my bad: forgot the snippet I mentioned in the previous post:

    try:
        lookup("chmod")(dst, mode, follow_symlinks=follow)
    except NotImplementedError:
        # if we got a NotImplementedError, it's because
        #   * follow_symlinks=False,
        #   * lchown() is unavailable, and
        #   * either
        #       * fchownat() is unavailable or
        #       * fchownat() doesn't implement AT_SYMLINK_NOFOLLOW.
        #         (it returned ENOSUP.)
        # therefore we're out of options--we simply cannot chown the
        # symlink.  give up, suppress the error.
        # (which is what shutil always did in this circumstance.)
        pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Aug 15 07:03:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Aug 2018 11:03:44 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1534331024.09.0.56676864532.issue2122@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If we break compatibility in any case, what if return None instead of 0? The function always returning 0 looks strange. The function always returning None is common.

----------
nosy: +serhiy.storchaka
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Wed Aug 15 07:53:05 2018
From: report at bugs.python.org (Michael Osipov)
Date: Wed, 15 Aug 2018 11:53:05 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534333985.63.0.56676864532.issue34381@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

That looks promising, I figured out that there is "./python -m test -h".

make test TESTOPTS="-uall,-network" works flawlessly.

I would have expected a link to https://devguide.python.org/runtests/ from https://github.com/python/cpython/blob/master/README.rst#testing.

So my request is just to update the rst file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Wed Aug 15 07:53:27 2018
From: report at bugs.python.org (Michael Osipov)
Date: Wed, 15 Aug 2018 11:53:27 +0000
Subject: [issue34401] [SOLUTION] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534334007.66.0.56676864532.issue34401@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
title: [solution] Make test_gdb work on HP-UX -> [SOLUTION] Make test_gdb work on HP-UX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Wed Aug 15 09:19:30 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Aug 2018 13:19:30 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1534339170.68.0.56676864532.issue24218@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Sorry, I haven't had time to look at it yet :(  Not sure when I will, things are more than a bit busy for me right now.  Ping me again in two weeks if I haven't responded, please.  The proposed solution sounds reasonable, though, so you could also propose a PR with tests and that would take me less time to review and I might get to it sooner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Wed Aug 15 09:31:13 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 13:31:13 +0000
Subject: [issue34406] Typo in documentation
In-Reply-To: <1534259088.23.0.56676864532.issue34406@psf.upfronthosting.co.za>
Message-ID: <1534339873.21.0.56676864532.issue34406@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, it definitely shouldn't be a backslash there. The @ isn't my invention, but last time someone questioned it I couldn't find any public examples, so it may be an internal Microsoft thing? I'm not totally attached to it, but if you want to fix it it'll need to be written out in full that it's "a value named X of type Y".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34406>
_______________________________________

From report at bugs.python.org  Wed Aug 15 09:48:16 2018
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Aug 2018 13:48:16 +0000
Subject: [issue34398] Docs search does not index glossary items
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534340896.57.0.56676864532.issue34398@psf.upfronthosting.co.za>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +8248
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Wed Aug 15 09:50:41 2018
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 15 Aug 2018 13:50:41 +0000
Subject: [issue34398] Docs search does not index glossary items
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534341041.0.0.56676864532.issue34398@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

I think showing glossary results up top in the search page is a good idea, so I wrote up a quick proof of concept sphinx extension to do so. The diff isn't very big or complicated but it does need a bit of cleanup, especially the javascript and presentation side.

There are some screenshots in the pull request.

(Adding Berker since they reviewed the change to move the search bar in the header for the docs)

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Wed Aug 15 09:57:33 2018
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 15 Aug 2018 13:57:33 +0000
Subject: [issue33255] json.dumps has different behaviour if encoding='utf-8'
 or encoding='utf8'
In-Reply-To: <1523352074.24.0.682650639539.issue33255@psf.upfronthosting.co.za>
Message-ID: <1534341453.61.0.56676864532.issue33255@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33255>
_______________________________________

From report at bugs.python.org  Wed Aug 15 10:00:27 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 15 Aug 2018 14:00:27 +0000
Subject: [issue34398] Docs search does not index glossary items
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534341627.15.0.56676864532.issue34398@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

Thank you for this, Ammar. Proof of concept solution is good progress. I'm well impressed. The screen shots convince me that it's well worth doing.

For me, the one thing that's missing is a link just above the glossary item. Something like "Glossary: iterable". You're probably aware of this, and so far it's only proof-of-concept.

Oh, and of course that the links in the displayed item work. My be a gotcha here for links to other glossary items.

So, well done, and thank you very much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Wed Aug 15 10:05:52 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 15 Aug 2018 14:05:52 +0000
Subject: [issue34398] Docs search does not index glossary items
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1534341952.36.0.56676864532.issue34398@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Ammar's pull request looks good to me, but it would be nice to include the item's title in the box. I will add my comments about the design and implementation in the pull request.

----------
resolution: third party -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Wed Aug 15 11:09:53 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 15 Aug 2018 15:09:53 +0000
Subject: [issue27026] async/await keywords are missing from reference docs
In-Reply-To: <1463299580.57.0.0973198258941.issue27026@psf.upfronthosting.co.za>
Message-ID: <1534345793.1.0.56676864532.issue27026@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The list has been updated in https://github.com/python/cpython/commit/bf9d317626eebcf79bd0756b4dd43df82d5cc186 (Issue 31810

Closing this as 'outdated'. Thanks for the report and for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27026>
_______________________________________

From report at bugs.python.org  Wed Aug 15 11:40:45 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 15:40:45 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1534347645.81.0.56676864532.issue2122@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I agree. We should definitely document it as a change, but I don't think there's anything useful you can do in the case of a flush failing anyway, so it seems unlikely that anyone could depend on the return value.

Returning None for success and exception on error sounds like a good change. Technically this is no longer returning zero, as previously documented, so if anyone wants to get *really* pedantic, we're not returning the "failed" result for success ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Wed Aug 15 11:56:16 2018
From: report at bugs.python.org (ysangkok+launchpad)
Date: Wed, 15 Aug 2018 15:56:16 +0000
Subject: [issue34411] ProactorEventLoop should use implement GetAddrInfo,
 GetNameInfo
Message-ID: <1534348576.75.0.56676864532.issue34411@psf.upfronthosting.co.za>


New submission from ysangkok+launchpad <ysangkok at gmail.com>:

Since socket.getaddrinfo and socket.getnameinfo take a lock on Windows, it would be nice to have their corresponding methods in asyncio.ProactorEventLoop use IOCP, so that they wouldn't block the whole event loop.

Overlapped I/O flags are available, so I am wondering how hard this would be: https://docs.microsoft.com/en-us/windows/desktop/api/ws2tcpip/nf-ws2tcpip-getaddrinfoexa

----------
components: asyncio
messages: 323572
nosy: asvetlov, ysangkok+launchpad, yselivanov
priority: normal
severity: normal
status: open
title: ProactorEventLoop should use implement GetAddrInfo, GetNameInfo
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34411>
_______________________________________

From report at bugs.python.org  Wed Aug 15 12:19:07 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 15 Aug 2018 16:19:07 +0000
Subject: [issue34411] ProactorEventLoop should use implement GetAddrInfo,
 GetNameInfo
In-Reply-To: <1534348576.75.0.56676864532.issue34411@psf.upfronthosting.co.za>
Message-ID: <1534349947.03.0.56676864532.issue34411@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> so that they wouldn't block the whole event loop.

The aren't blocking it now as they are executed in a thread pool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34411>
_______________________________________

From report at bugs.python.org  Wed Aug 15 13:38:52 2018
From: report at bugs.python.org (ysangkok+launchpad)
Date: Wed, 15 Aug 2018 17:38:52 +0000
Subject: [issue34411] ProactorEventLoop should use implement GetAddrInfo,
 GetNameInfo
In-Reply-To: <1534348576.75.0.56676864532.issue34411@psf.upfronthosting.co.za>
Message-ID: <1534354732.89.0.56676864532.issue34411@psf.upfronthosting.co.za>


ysangkok+launchpad <ysangkok at gmail.com> added the comment:

As far as our experiments show, the requests are blocking each other irrespective of thread pool size. Which is expected since the lock is global across threads.

Am I correct in assuming that an implementation for the ProactorEventLoop with IOCP would not require a global lock?

Here is our code, this takes 12 sec on Ubuntu and ~12*100 secs on Windows (cause a failed DNS request takes 10 sec):

import asyncio

futs = []
for i in range(100):
  t = asyncio.get_event_loop().getaddrinfo("aa000000aa"+str(i)+".onion.", 80)
  futs.append(t)

print(asyncio.get_event_loop().run_until_complete(asyncio.gather(*futs, return_exceptions=True)))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34411>
_______________________________________

From report at bugs.python.org  Wed Aug 15 13:44:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 15 Aug 2018 17:44:37 +0000
Subject: [issue34411] ProactorEventLoop should use implement GetAddrInfo,
 GetNameInfo
In-Reply-To: <1534348576.75.0.56676864532.issue34411@psf.upfronthosting.co.za>
Message-ID: <1534355077.54.0.56676864532.issue34411@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> As far as our experiments show, the requests are blocking each other irrespective of thread pool size. Which is expected since the lock is global across threads.

It looks like you don't understand how GIL works in Python (sorry if I'm mistaken).

The GIL prevents two threads from simultaneously executing *pure Python* code.  Whenever Python code does a system call, the GIL is released for that thread, allowing other Python code in other threads to execute.  Therefore, getaddrname calls in threadpools can't block each other or the event loop thread in any way.

There's a max capacity for the threadpool though, so if you're making 100s of getaddrname calls you'll indeed see some slowdown.  Using IOCP for getaddsname can remove this bottleneck.

> Am I correct in assuming that an implementation for the ProactorEventLoop with IOCP would not require a global lock?

I think so, because we can have as many getaddrcalls as we want all monitored by IOCP for us.  But I'm not an expert in IOCP, so if you want to work on the patch I can't really help you with details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34411>
_______________________________________

From report at bugs.python.org  Wed Aug 15 13:49:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Aug 2018 17:49:21 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
 lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1534355361.83.0.56676864532.issue12458@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +8249
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Wed Aug 15 13:58:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Aug 2018 17:58:19 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
 lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1534355899.25.0.56676864532.issue12458@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems PR 8774 fixes all mentioned examples (as well as examples in issue34372), except that tracebacks show the single line number of the first line of the multiline expression instead of the range of lines as was suggested. Showing the range of lines requires much more significant changes and changing the marshal format.

The drawback is minor increasing the size of code objects in memory (due to saving additional line numbers in lnotab), pyc files, and disassembly output for multiline expressions.

----------
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Wed Aug 15 14:00:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Aug 2018 18:00:44 +0000
Subject: [issue34372] Parenthesized expression has incorrect line numbers
In-Reply-To: <1533913344.46.0.56676864532.issue34372@psf.upfronthosting.co.za>
Message-ID: <1534356044.85.0.56676864532.issue34372@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If the proposed solution for issue12458 be merged, this issue will be closed as a duplicate. Otherwise I have a simpler solution for this particular case (and few other cases, but not all cases in issue12458).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34372>
_______________________________________

From report at bugs.python.org  Wed Aug 15 14:01:18 2018
From: report at bugs.python.org (ysangkok+launchpad)
Date: Wed, 15 Aug 2018 18:01:18 +0000
Subject: [issue34411] ProactorEventLoop should use implement GetAddrInfo,
 GetNameInfo
In-Reply-To: <1534348576.75.0.56676864532.issue34411@psf.upfronthosting.co.za>
Message-ID: <1534356078.31.0.56676864532.issue34411@psf.upfronthosting.co.za>


ysangkok+launchpad <ysangkok at gmail.com> added the comment:

The lock I was referring to is https://github.com/python/cpython/blob/e0b5b2096ead4cc094a129ce7602ac5c0e998086/Modules/socketmodule.c#L222

Is netdb_lock the GIL?

If the thread pooling was effective, the slowdown wouldn't be linear, but it does indeed appear to be. How can this be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34411>
_______________________________________

From report at bugs.python.org  Wed Aug 15 14:08:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 15 Aug 2018 18:08:23 +0000
Subject: [issue34411] ProactorEventLoop should use implement GetAddrInfo,
 GetNameInfo
In-Reply-To: <1534348576.75.0.56676864532.issue34411@psf.upfronthosting.co.za>
Message-ID: <1534356503.19.0.56676864532.issue34411@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Is netdb_lock the GIL?

No, it's a lock used by getaddrinfo specifically on *some* platforms. It doesn't look like it's used on Windows.

> If the thread pooling was effective, the slowdown wouldn't be linear, but it does indeed appear to be. How can this be?

I don't know, hard to tell without seeing how you test that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34411>
_______________________________________

From report at bugs.python.org  Wed Aug 15 14:44:12 2018
From: report at bugs.python.org (Ilya Kulakov)
Date: Wed, 15 Aug 2018 18:44:12 +0000
Subject: [issue30811] A venv created and activated from within a virtualenv
 uses the outer virtualenv's site-packages rather than its own.
In-Reply-To: <1498813368.34.0.349011380575.issue30811@psf.upfronthosting.co.za>
Message-ID: <1534358652.22.0.56676864532.issue30811@psf.upfronthosting.co.za>


Ilya Kulakov <kulakov.ilya at gmail.com> added the comment:

Also hit this issue while trying to run venv on Travis.

Perhaps venv should detect if it's running under virtualenv (e.g. the VIRTUAL_ENV env is present) and issue a warning?

----------
nosy: +Kentzo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________

From report at bugs.python.org  Wed Aug 15 15:04:01 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 15 Aug 2018 19:04:01 +0000
Subject: [issue30811] A venv created and activated from within a virtualenv
 uses the outer virtualenv's site-packages rather than its own.
In-Reply-To: <1498813368.34.0.349011380575.issue30811@psf.upfronthosting.co.za>
Message-ID: <1534359841.25.0.56676864532.issue30811@psf.upfronthosting.co.za>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

Unfortunately it is not a viable solution. If you run the virtualenv python without activation, e.g.

    virtualenv --python=python3.7 foo
    foo/bin/python -m venv bar

The VIRTUAL_ENV environment variable wouldn?t be set in this situation, but the created venv (bar) would still be broken.

The only viable cue I find to detect virtualenv existence is it sets sys.real_prefix to point to the prefix of the actual Python isntallation (i.e. the value of sys.prefix without virtualenv), while this variable does not exist by default. This is, however, obviously very hacky and unreliable, and not something venv should do IMO. virtualenv is the problem here, and should be responsible for fixing this situation instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________

From report at bugs.python.org  Wed Aug 15 15:14:32 2018
From: report at bugs.python.org (Erik Janssens)
Date: Wed, 15 Aug 2018 19:14:32 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534360472.95.0.56676864532.issue34217@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

Attached a small helper script to detect camelcase windows headers,
2 more occurences found :

Modules/socketmodule.c versionhelpers.h 306 #include <VersionHelpers.h>
Tools/msi/bundle/bootstrap/pch.h uxtheme.h 18 #include <Uxtheme.h>

----------
status: closed -> open
Added file: https://bugs.python.org/file47751/windows_headers.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Wed Aug 15 15:15:14 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 19:15:14 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534360514.42.0.56676864532.issue34405@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +8250
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Wed Aug 15 15:20:25 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 19:20:25 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534360825.68.0.56676864532.issue34405@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +8251

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Wed Aug 15 16:29:28 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 20:29:28 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534364968.12.0.56676864532.issue34405@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 864a892af38afefb0a0464af298cf09d2e1195f7 by Steve Dower in branch 'master':
bpo-34405: Updated to OpenSSL 1.1.0i for Windows builds. (GH-8775)
https://github.com/python/cpython/commit/864a892af38afefb0a0464af298cf09d2e1195f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Wed Aug 15 16:29:43 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 20:29:43 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534364983.31.0.56676864532.issue34405@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset eeca87cf3ce5b866dbb210548e23ee91ec5411f2 by Steve Dower in branch '3.6':
bpo-34405: Updated to OpenSSL 1.0.2p for Windows builds. (GH-8776)
https://github.com/python/cpython/commit/eeca87cf3ce5b866dbb210548e23ee91ec5411f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Wed Aug 15 16:29:57 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 20:29:57 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534364997.62.0.56676864532.issue34405@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8252

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Wed Aug 15 16:55:14 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Aug 2018 20:55:14 +0000
Subject: [issue34405] Upgrade to OpenSSL 1.1.0i / 1.0.2p
In-Reply-To: <1534254767.16.0.56676864532.issue34405@psf.upfronthosting.co.za>
Message-ID: <1534366514.07.0.56676864532.issue34405@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 64336dc0a5907b04fe85a911cd1b8be9b663587e by Miss Islington (bot) in branch '3.7':
bpo-34405: Updated to OpenSSL 1.1.0i for Windows builds. (GH-8775)
https://github.com/python/cpython/commit/64336dc0a5907b04fe85a911cd1b8be9b663587e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34405>
_______________________________________

From report at bugs.python.org  Wed Aug 15 18:03:57 2018
From: report at bugs.python.org (ppperry)
Date: Wed, 15 Aug 2018 22:03:57 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE
Message-ID: <1534370637.49.0.56676864532.issue1529353@psf.upfronthosting.co.za>


Change by ppperry <mapreader at olum.org>:


----------
title: Squeezer - squeeze large output in the interpreter -> Squeezer - squeeze large output in IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Wed Aug 15 19:12:00 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Aug 2018 23:12:00 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534374720.76.0.56676864532.issue34217@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Are those bugs? On Windows, they are spelled with that casing (and while NTFS is case-insensitive, it *is* case-preserving).

Whatever package you have used for cross-compiling may have renamed them (similarly Shlwapi.h). In which case, perhaps you could request that the package you are using preserve the case of the files it is cloning, rather than changing it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Wed Aug 15 21:36:44 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Thu, 16 Aug 2018 01:36:44 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534383404.22.0.56676864532.issue34410@psf.upfronthosting.co.za>


Carlo Rosati <crosati777 at icloud.com> added the comment:

I figured out that the problem is itertools.tee does not use a multiprocessing.Manager proxied object for shared state. I was able to create a workaround tee as follows.

def multiprocessing_tee(iterable, n=2):
    """Write a multiprocessing safe itertools.tee"""
    it = iter(iterable)
    m = multiprocessing.Manager()
    lists = [m.list() for i in range(n)]
    def gen(local_list):
        keep_m_alive = m
        while True:
            if not local_list:         # when the local list is empty
                newval = next(it)      # fetch a new value and
                for l in lists:        # load it to all the lists
                    l.append(newval)
            yield local_list.pop(-1)
    return tuple(gen(l) for l in lists)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Wed Aug 15 21:50:42 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Thu, 16 Aug 2018 01:50:42 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534384242.52.0.56676864532.issue34410@psf.upfronthosting.co.za>


Carlo Rosati <crosati777 at icloud.com> added the comment:

Okay I needed to do .pop(0) instead of .pop(-1) which is probably O(N)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Thu Aug 16 00:27:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Aug 2018 04:27:52 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534393672.88.0.56676864532.issue34395@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 67b9cc8e6072a919d2ed7e7ecc8124c8acfb3733 by Serhiy Storchaka (Sergey Fedoseev) in branch 'master':
bpo-34395: Fix memory leaks caused by incautious usage of PyMem_Resize(). (GH-8756)
https://github.com/python/cpython/commit/67b9cc8e6072a919d2ed7e7ecc8124c8acfb3733


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 00:28:15 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 04:28:15 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534393695.53.0.56676864532.issue34395@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8253

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 00:28:26 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 04:28:26 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534393706.84.0.56676864532.issue34395@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8254

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 00:53:03 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 04:53:03 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534395183.78.0.56676864532.issue34395@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 962051eeb0ba486b8ffe4082779b4fa432e3dfb2 by Miss Islington (bot) in branch '3.7':
bpo-34395: Fix memory leaks caused by incautious usage of PyMem_Resize(). (GH-8756)
https://github.com/python/cpython/commit/962051eeb0ba486b8ffe4082779b4fa432e3dfb2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 00:57:07 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 04:57:07 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534395427.45.0.56676864532.issue34395@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b14ab447ee3f47d479d899b4001d870569a76c44 by Miss Islington (bot) in branch '3.6':
bpo-34395: Fix memory leaks caused by incautious usage of PyMem_Resize(). (GH-8756)
https://github.com/python/cpython/commit/b14ab447ee3f47d479d899b4001d870569a76c44


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 01:38:31 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Thu, 16 Aug 2018 05:38:31 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534397911.01.0.56676864532.issue34410@psf.upfronthosting.co.za>


Carlo Rosati <crosati777 at icloud.com> added the comment:

You'll also need to lock when modifying the manager's list. Does anyone know how to do this using the multiprocessing.Queues without deadlocking?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Thu Aug 16 01:40:12 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Aug 2018 05:40:12 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534398012.93.0.56676864532.issue34410@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the script. I can reproduce this on master and Python 3.6 too. Sometimes the attached script causes timeout error. Running it under gdb gives me below : 

[New Thread 0x18ab of process 10682]
[New Thread 0x1903 of process 10682]
[New Thread 0x1a03 of process 10682]

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x18ab of process 10682]
0x000000010033e509 in teedataobject_getitem (tdo=0x1014361c0, i=1)
    at ./Modules/itertoolsmodule.c:454
454	    Py_INCREF(value);


Backtrace : 

#0  0x000000010033e509 in teedataobject_getitem (tdo=0x100645640, i=1)
    at ./Modules/itertoolsmodule.c:454
#1  0x000000010033e290 in tee_next (to=0x10308a668) at ./Modules/itertoolsmodule.c:637
#2  0x0000000100059844 in enum_next (en=0x10308fc20) at Objects/enumobject.c:156
#3  0x00000001002297e1 in _PyEval_EvalFrameDefault (
    f=Frame 0x100646710, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py, line 292, in _guarded_task_generation (self=<Pool(_ctx=<ForkContext at remote 0x101ddce90>, _inqueue=<SimpleQueue(_reader=<Connection(_handle=4, _readable=True, _writable=False) at remote 0x101c236b0>, _writer=<Connection(_handle=5, _readable=False, _writable=True) at remote 0x101c23c50>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x101f53e10>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x101f53e10>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x101f53e10>) at remote 0x101f50050>, _poll=<method at remote 0x10186e2c0>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078178>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078178>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078178>) at remote 0x101f54dd0>) at remote 0x101bf5cb0>, _ou...(truncated), throwflag=0) at Python/ceval.c:2905
#4  0x0000000100215277 in PyEval_EvalFrameEx (
    f=Frame 0x100646710, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py, line 292, in _guarded_task_generation (self=<Pool(_ctx=<ForkContext at remote 0x101ddce90>, _inqueue=<SimpleQueue(_reader=<Connection(_handle=4, _readable=True, _writable=False) at remote 0x101c236b0>, _writer=<Connection(_handle=5, _readable=False, _writable=True) at remote 0x101c23c50>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x101f53e10>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x101f53e10>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x101f53e10>) at remote 0x101f50050>, _poll=<method at remote 0x10186e2c0>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078178>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078178>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078178>) at remote 0x101f54dd0>) at remote 0x101bf5cb0>, _ou...(truncated), throwflag=0) at Python/ceval.c:536
#5  0x000000010006a3e2 in gen_send_ex (gen=0x1030349b0, arg=0x0, exc=0, closing=0)
    at Objects/genobject.c:221
#6  0x000000010006ba1f in gen_iternext (gen=0x1030349b0) at Objects/genobject.c:542
#7  0x00000001002297e1 in _PyEval_EvalFrameDefault (
    f=Frame 0x101909730, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py, line 426, in _handle_tasks (taskqueue=<_queue.SimpleQueue at remote 0x101f1daa0>, put=<method at remote 0x101db5ae0>, outqueue=<SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078c08>) at remote 0x10306df50>) a...(truncated), throwflag=0) at Python/ceval.c:2905
#8  0x0000000100215277 in PyEval_EvalFrameEx (
    f=Frame 0x101909730, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py, line 426, in _handle_tasks (taskqueue=<_queue.SimpleQueue at remote 0x101f1daa0>, put=<method at remote 0x101db5ae0>, outqueue=<SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, ac---Type <return> to continue, or q <return> to quit---
quire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078c08>) at remote 0x10306df50>) a...(truncated), throwflag=0) at Python/ceval.c:536
#9  0x0000000100045d63 in function_code_fastcall (co=0x101de77c0, args=0x1030693a0, nargs=5,
    globals={'__name__': 'multiprocessing.pool', '__doc__': None, '__package__': 'multiprocessing', '__loader__': <SourceFileLoader(name='multiprocessing.pool', path='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py') at remote 0x101c23b90>, '__spec__': <ModuleSpec(name='multiprocessing.pool', loader=<...>, origin='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/__pycache__/pool.cpython-38.pyc', _initializing=False) at remote 0x101c23bf0>, '__file__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/pool.py', '__cached__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/multiprocessing/__pycache__/pool.cpython-38.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis repr...(truncated)) at Objects/call.c:283
#10 0x0000000100043d91 in _PyFunction_FastCallDict (func=<function at remote 0x101f41f70>,
    args=0x103069378, nargs=5, kwargs={}) at Objects/call.c:322
#11 0x0000000100045902 in PyObject_Call (callable=<function at remote 0x101f41f70>,
    args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078c08>) at remote 0x10306df50>) at remote 0x101f50530>, [<ForkProcess(_identity=(1,), _config={'authkey': <AuthenticationString at remote 0x101bfcdd0>, 'semprefix': '/mp', 'daemon': True}, _pa...(truncated), kwargs={}) at Objects/call.c:226
#12 0x00000001002342bc in do_call_core (func=<function at remote 0x101f41f70>,
    callargs=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078c08>) at remote 0x10306df50>) at remote 0x101f50530>, [<ForkProcess(_identity=(1,), _config={'authkey': <AuthenticationString at remote 0x101bfcdd0>, 'semprefix': '/mp', 'daemon': True}, _pa...(truncated), kwdict={}) at Python/ceval.c:4652
#13 0x000000010022ca2b in _PyEval_EvalFrameDefault (
    f=Frame 0x10308d050, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py, line 865, in run (self=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_hand---Type <return> to continue, or q <return> to quit---
le=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x1...(truncated), throwflag=0) at Python/ceval.c:3267
#14 0x0000000100215277 in PyEval_EvalFrameEx (
    f=Frame 0x10308d050, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py, line 865, in run (self=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x1...(truncated), throwflag=0) at Python/ceval.c:536
#15 0x0000000100045d63 in function_code_fastcall (co=0x101c7aa00, args=0x10190a8f8, nargs=1,
    globals={'__name__': 'threading', '__doc__': "Thread module emulating a subset of Java's threading model.", '__package__': '', '__loader__': <SourceFileLoader(name='threading', path='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py') at remote 0x101c6a4d0>, '__spec__': <ModuleSpec(name='threading', loader=<...>, origin='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/__pycache__/threading.cpython-38.pyc', _initializing=False) at remote 0x101c6a530>, '__file__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py', '__cached__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/__pycache__/threading.cpython-38.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '...(truncated)) at Objects/call.c:283
#16 0x0000000100045069 in _PyFunction_FastCallKeywords (func=<function at remote 0x101d9e890>,
    stack=0x10190a8f0, nargs=1, kwnames=0x0) at Objects/call.c:408
#17 0x0000000100233e50 in call_function (pp_stack=0x103b522b8, oparg=1, kwnames=0x0)
    at Python/ceval.c:4623
#18 0x000000010022bcf9 in _PyEval_EvalFrameDefault (
    f=Frame 0x10190a750, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py, line 917, in _bootstrap_inner (self=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object ...(truncated), throwflag=0) at Python/ceval.c:3186
#19 0x0000000100215277 in PyEval_EvalFrameEx (
    f=Frame 0x10190a750, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.p---Type <return> to continue, or q <return> to quit---
y, line 917, in _bootstrap_inner (self=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object ...(truncated), throwflag=0) at Python/ceval.c:536
#20 0x0000000100045d63 in function_code_fastcall (co=0x101c7ad00, args=0x103086b68, nargs=1,
    globals={'__name__': 'threading', '__doc__': "Thread module emulating a subset of Java's threading model.", '__package__': '', '__loader__': <SourceFileLoader(name='threading', path='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py') at remote 0x101c6a4d0>, '__spec__': <ModuleSpec(name='threading', loader=<...>, origin='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/__pycache__/threading.cpython-38.pyc', _initializing=False) at remote 0x101c6a530>, '__file__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py', '__cached__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/__pycache__/threading.cpython-38.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '...(truncated)) at Objects/call.c:283
#21 0x0000000100045069 in _PyFunction_FastCallKeywords (func=<function at remote 0x101d9eb50>,
    stack=0x103086b60, nargs=1, kwnames=0x0) at Objects/call.c:408
#22 0x0000000100233e50 in call_function (pp_stack=0x103b54508, oparg=1, kwnames=0x0)
    at Python/ceval.c:4623
#23 0x000000010022bcf9 in _PyEval_EvalFrameDefault (
    f=Frame 0x1030869d8, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py, line 885, in _bootstrap (self=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at rem...(truncated), throwflag=0) at Python/ceval.c:3186
#24 0x0000000100215277 in PyEval_EvalFrameEx (
    f=Frame 0x1030869d8, for file /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py, line 885, in _bootstrap (self=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.S---Type <return> to continue, or q <return> to quit---
emLock object at rem...(truncated), throwflag=0) at Python/ceval.c:536
#25 0x0000000100045d63 in function_code_fastcall (co=0x101c7aac0, args=0x103b55d68, nargs=1,
    globals={'__name__': 'threading', '__doc__': "Thread module emulating a subset of Java's threading model.", '__package__': '', '__loader__': <SourceFileLoader(name='threading', path='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py') at remote 0x101c6a4d0>, '__spec__': <ModuleSpec(name='threading', loader=<...>, origin='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py', loader_state=None, submodule_search_locations=None, _set_fileattr=True, _cached='/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/__pycache__/threading.cpython-38.pyc', _initializing=False) at remote 0x101c6a530>, '__file__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/threading.py', '__cached__': '/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/__pycache__/threading.cpython-38.pyc', '__builtins__': {'__name__': 'builtins', '__doc__': "Built-in functions, exceptions, and other objects.\n\nNoteworthy: None is the `nil' object; Ellipsis represents `...' in slices.", '__package__': '', '...(truncated)) at Objects/call.c:283
#26 0x0000000100043d91 in _PyFunction_FastCallDict (func=<function at remote 0x101d9e940>,
    args=0x103b55d60, nargs=1, kwargs=0x0) at Objects/call.c:322
#27 0x00000001000437e4 in _PyObject_FastCallDict (callable=<function at remote 0x101d9e940>,
    args=0x103b55d60, nargs=1, kwargs=0x0) at Objects/call.c:98
#28 0x0000000100047d29 in _PyObject_Call_Prepend (callable=<function at remote 0x101d9e940>,
    obj=<Thread(_target=<function at remote 0x101f41f70>, _name='Thread-2', _args=(<_queue.SimpleQueue at remote 0x101f1daa0>, <method at remote 0x101db5ae0>, <SimpleQueue(_reader=<Connection(_handle=8, _readable=True, _writable=False) at remote 0x10306d410>, _writer=<Connection(_handle=9, _readable=False, _writable=True) at remote 0x10306d9b0>, _rlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078ba0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078ba0>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078ba0>) at remote 0x10306de90>, _poll=<method at remote 0x1018eddb8>, _wlock=<Lock(_semlock=<_multiprocessing.SemLock at remote 0x103078c08>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0x103078c08>, release=<built-in method release of _multiprocessing.SemLock object at remote 0x103078c08>) at remote 0x10306df50>) at remote 0x101f50530>, [<ForkProcess(_identity=(1,), _config={'authkey': <Authenticat...(truncated), args=(), kwargs=0x0) at Objects/call.c:904
#29 0x000000010004b5bd in method_call (method=<method at remote 0x101ec2bb0>, args=(), kwargs=0x0)
    at Objects/classobject.c:306
#30 0x0000000100045a02 in PyObject_Call (callable=<method at remote 0x101ec2bb0>, args=(),
    kwargs=0x0) at Objects/call.c:245
#31 0x0000000100349e16 in t_bootstrap (boot_raw=0x10303dd30) at ./Modules/_threadmodule.c:992
#32 0x00007fff87a53268 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
#33 0x00007fff87a531e5 in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
#34 0x00007fff87a5141d in thread_start () from /usr/lib/system/libsystem_pthread.dylib
#35 0x0000000000000000 in ?? ()



Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Thu Aug 16 02:20:33 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 16 Aug 2018 06:20:33 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1534400433.7.0.56676864532.issue1529353@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
title: Squeezer - squeeze large output in IDLE -> Squeezer - squeeze large output in IDLE's shell

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Thu Aug 16 02:41:00 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 16 Aug 2018 06:41:00 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534401660.76.0.56676864532.issue34217@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset e6a4755e6793942b950c1595e0c34bd66a0ee13e by INADA Naoki (Erik Janssens) in branch 'master':
bpo-34217: Use lowercase for windows headers (GH-8472)
https://github.com/python/cpython/commit/e6a4755e6793942b950c1595e0c34bd66a0ee13e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 02:41:27 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 06:41:27 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534401687.97.0.56676864532.issue34217@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8255
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 02:49:43 2018
From: report at bugs.python.org (Erik Janssens)
Date: Thu, 16 Aug 2018 06:49:43 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534402183.32.0.56676864532.issue34217@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

@inada.naoki : thank you !

@steve.dower : I would not consider those bugs per se, but they are
inconsistencies, for example in the master branch :

number of "Windows.h" includes : 2
number of "windows.h" includes : 55

whatever might be the 'right' solution, it's always an advantage to
have a consistent codebase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 03:28:30 2018
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 16 Aug 2018 07:28:30 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534404510.87.0.56676864532.issue34217@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

New windows will support case sensitive filesystem too.
Stop relying to case insensitive filesystem makes sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 03:29:24 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 07:29:24 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534404564.03.0.56676864532.issue34217@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bf8e9d18dd75f58ce3b9761763ae10c0800b43d8 by Miss Islington (bot) in branch '3.7':
bpo-34217: Use lowercase for windows headers (GH-8472)
https://github.com/python/cpython/commit/bf8e9d18dd75f58ce3b9761763ae10c0800b43d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 05:07:50 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 16 Aug 2018 09:07:50 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
 setuid/setgit bits
In-Reply-To: <1534330869.85.0.56676864532.issue17180@psf.upfronthosting.co.za>
Message-ID: <3836f08b-afe3-fa03-a73f-7bdf69f4fdf1@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I want to believe this can be resolved - without breakage on POSIX.

Clarification: while Mac/OS falls under "posix" in python terms - maybe
"breakage" will need to be accepted,
or, for "back-ports" Mac/OS will be "as if root or super-user" and use
an additional (optional) argument in 3.8 and beyond
to keep backwards compatibility.

Short text: to proceed I think we should start with getting some
additional tests into test_shutil.py asap so that we can see how systems
respond without any changes.

My experience is that cp -r[pP] behaves the same as shutil.copy*() when
the EUID==0, aka superuser,
but strips special bits from files and cannot copy the UID/GID owner
bits of the inode.

I would appreciate someone helping me writing more extensive testing.

We need to test:
* root
* not-root, but owner
* not-root, not owner, but in group
* not-root, "other", other "read" access exists

* if the test does not already exist - also check behavior when directories
? have/do not have "search" (x-bit) enabled.

I am working on a patch to address these different conditions.

Ideally, the "not-owner" and "not-group" tests can be run
by creating the "copy.me" area as root, setting perms, etc.
and then using su -c to run the shutil.copy*() call
and back as root make the verification.

??? Perspective ???

If this is too much discussion, please reply with suggestions - privately -
on what I could do better to not waste your time.

The issue seems unchanged since original posting.

The original report states:
hen copying the mode of a file with copy, copy2, copymode, copystat or
copytree, all permission bits are copied (including setuid and setgit),
but the owner of the file is not. This can be used for privilege escalation.

...snip...

The behaviour of copymode/copystat in this case is the same as `chmod
--reference', and there can be some expectation of unsafety, but
copy/copy2/copytree's behaviour differs from that of `cp -p', and this
is a non-obvious difference.

For clarity: GNU chmod states:

--reference=RFILE
??? use RFILE's mode instead of MODE values

Additionally, the chmod man page reminds us the "special bit" masking
behavior is different for files and directries.
Specifically, SUID, SGID and SVTX should not be cleared unless
specifically requested by a chmod "u-s,g-s" specification.

"... a directory's unmentioned set user and group ID bits are not affected"

Additional comments discuss:
short window of opportunity (files are copied first, then mode bits copied)
breakage with the past (copytree used as "backup", regardless of version)

And the comment/opinion that shutil.copy() should emulate cp (implies
emulate "cp -r", so neither -p nor -P)

it seems shutil.copy2() is adding the -p (or -P if follow_symlinks=false)

There was a modification to test_shutil.py suggested as part of a patch.
I added that to verify the issue is still current.

???
diff --git a/Lib/test/test_shutil.py b/Lib/test/test_shutil.py
index 7e0a3292e0..7ceefd1ebc 100644
--- a/Lib/test/test_shutil.py
+++ b/Lib/test/test_shutil.py
@@ -1471,6 +1471,24 @@ class TestShutil(unittest.TestCase):
???????? rv = shutil.copytree(src_dir, dst_dir)
???????? self.assertEqual(['foo'], os.listdir(rv))

+??? @unittest.skipUnless((os.name == "posix" and os.geteuid() != 0),
"Requires POSIX compatible OS and non-root userid")
+??? def test_copy_remove_setuid(self):
+??????? src_dir = self.mkdtemp()
+??????? src_file = os.path.join(src_dir, 'foo')
+??????? write_file(src_file, 'foo')
+??????? dst_file = os.path.join(src_dir, 'bar')
+??????? harmful_mode = stat.S_IRUSR | stat.S_IXUSR | stat.S_ISUID
+??????? harmless_mode = stat.S_IRUSR | stat.S_IXUSR
+
+??????? # set mode and verify
+??????? os.chmod(src_file, harmful_mode)
+??????? mode = stat.S_IMODE(os.stat(src_file).st_mode)
+??????? self.assertTrue(oct(mode), oct(harmful_mode))
+
+??????? # check that copy does not preserve harmful bits
+??????? shutil.copy(src_file, dst_file)
+??????? mode = stat.S_IMODE(os.stat(dst_file).st_mode)
+??????? self.assertEqual(oct(mode), oct(harmless_mode))

?class TestWhich(unittest.TestCase):
???
The result is:
root at x066:[/data/prj/python/python3-3.8]./python -m test -v test_shutil
== CPython 3.8.0a0 (heads/master:cca4eec3c0, Aug 13 2018, 04:53:15) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /data/prj/python/python3-3.8/build/test_python_10944516
== CPU count: 8
== encodings: locale=ISO8859-1, FS=iso8859-1
Run tests sequentially
...
test_copy_remove_setuid (test.test_shutil.TestShutil) ... FAIL
...
======================================================================
FAIL: test_copy_remove_setuid (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
? File "/data/prj/python/git/python3-3.8/Lib/test/test_shutil.py", line
1491, in test_copy_remove_setuid
??? self.assertEqual(oct(mode), oct(harmless_mode))
AssertionError: '0o4500' != '0o500'
- 0o4500
??? -
+ 0o500

----------------------------------------------------------------------

On 8/15/2018 1:01 PM, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> I am looking at this.

----------
Added file: https://bugs.python.org/file47752/pEpkey.asc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17180>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1765 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20180816/fad82cae/attachment-0001.key>

From report at bugs.python.org  Thu Aug 16 05:20:09 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 16 Aug 2018 09:20:09 +0000
Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and
 later)
In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za>
Message-ID: <1534411209.68.0.56676864532.issue27435@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

as this is not (likely) to be backported to Python2 (by python, fyi: I do include full ctypes-load_library() support in my "independent" packaging)

and it is "resolved" for Python3-3.7 issue26439

this issue may, imho, be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27435>
_______________________________________

From report at bugs.python.org  Thu Aug 16 05:23:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Aug 2018 09:23:27 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1534411407.21.0.56676864532.issue33216@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8256

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Thu Aug 16 06:25:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Aug 2018 10:25:31 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1534415131.16.0.56676864532.issue33216@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8257

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Thu Aug 16 06:29:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Aug 2018 10:29:29 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1534415369.9.0.56676864532.issue34246@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +email
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34246>
_______________________________________

From report at bugs.python.org  Thu Aug 16 08:37:14 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 16 Aug 2018 12:37:14 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534423034.63.0.56676864532.issue34395@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
pull_requests: +8258

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 10:46:03 2018
From: report at bugs.python.org (Michael Osipov)
Date: Thu, 16 Aug 2018 14:46:03 +0000
Subject: [issue34401] [SOLUTION] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534430763.82.0.56676864532.issue34401@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


Removed file: https://bugs.python.org/file47749/test_gdb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Thu Aug 16 10:47:52 2018
From: report at bugs.python.org (Michael Osipov)
Date: Thu, 16 Aug 2018 14:47:52 +0000
Subject: [issue34412] strsignal(3) does not exist on HP-UX
Message-ID: <1534430872.24.0.56676864532.issue34412@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

HP-UX does not provide any mappings from signals to strings. The proper approach is to map just like for Windows. Alternatively, one could simply return the singal as an int.

----------
components: Library (Lib)
messages: 323600
nosy: michael-o
priority: normal
severity: normal
status: open
title: strsignal(3) does not exist on HP-UX
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34412>
_______________________________________

From report at bugs.python.org  Thu Aug 16 10:51:54 2018
From: report at bugs.python.org (Michael Osipov)
Date: Thu, 16 Aug 2018 14:51:54 +0000
Subject: [issue34412] strsignal(3) does not exist on HP-UX
In-Reply-To: <1534430872.24.0.56676864532.issue34412@psf.upfronthosting.co.za>
Message-ID: <1534431113.99.0.56676864532.issue34412@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

References:
* https://github.com/google/cmockery/issues/11
* https://www.spinics.net/lists/dash/msg00547.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34412>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:06:29 2018
From: report at bugs.python.org (Michael Osipov)
Date: Thu, 16 Aug 2018 15:06:29 +0000
Subject: [issue34412] strsignal(3) does not exist on HP-UX
In-Reply-To: <1534430872.24.0.56676864532.issue34412@psf.upfronthosting.co.za>
Message-ID: <1534431989.57.0.56676864532.issue34412@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8259
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34412>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:12:04 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 16 Aug 2018 15:12:04 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534432324.83.0.56676864532.issue34217@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> Stop relying to case insensitive filesystem makes sense to me.

If this is the case, then we need to normalise the casing to match the actual files (which are mixed-case, not lowercase). You just broke this with your PR :)

So which is it? Do we match the casing of the real files? Or do we change to match someone's unofficial versions of the files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:13:08 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 16 Aug 2018 15:13:08 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534432388.31.0.56676864532.issue34217@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> whatever might be the 'right' solution, it's always an advantage to
> have a consistent codebase.

Not when you are consistently wrong, it's not.

Let's figure out the right answer here before making many changes to the codebase. First, can you tell me where you got your lowercased named files from? Because it wasn't the official SDK...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:34:25 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Aug 2018 15:34:25 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
 setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1534433665.35.0.56676864532.issue17180@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't understand this clarification:

> Clarification: while Mac/OS falls under "posix" in python terms - maybe
> "breakage" will need to be accepted,
> or, for "back-ports" Mac/OS will be "as if root or super-user" and use
> an additional (optional) argument in 3.8 and beyond
> to keep backwards compatibility.

AFAIK macOS should behave just like other posix-y platforms here.  In particular, I've verified that cp(1) behaves the same as on other platforms: the SUID bit is stripped when copying a setuid file.

Do you have a reason to assume that macOS is special here?


P.S. macOS is spelled macOS, not Mac/OS

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:46:13 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 16 Aug 2018 15:46:13 +0000
Subject: [issue34413] Porting section of 3.5 "What's New" doc does not mention
 bytecode changes.
Message-ID: <1534434373.24.0.56676864532.issue34413@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In the 3.5 "What's New" doc, the porting section [1] does not mention the bytecode changes resulting from the PEP 448 implementation. [2][3]  It should.

I've marked this issue for the versions past 3.5 because each branch has its own "What's New" doc for 3.5.

[1] https://docs.python.org/3/whatsnew/3.5.html#porting-to-python-3-5
[2] bpo-33216
[3] https://github.com/python/cpython/pull/8783#discussion_r210642202

----------
assignee: docs at python
components: Documentation
messages: 323605
nosy: docs at python, eric.snow, serhiy.storchaka
priority: low
severity: normal
stage: needs patch
status: open
title: Porting section of 3.5 "What's New" doc does not mention bytecode changes.
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34413>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:48:42 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 16 Aug 2018 15:48:42 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1534434522.07.0.56676864532.issue33216@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FTR, the change was introduced by the PEP 448 implementation. [1]

[1] https://github.com/python/cpython/pull/8338#issuecomment-406256152

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Thu Aug 16 11:51:00 2018
From: report at bugs.python.org (Eric Snow)
Date: Thu, 16 Aug 2018 15:51:00 +0000
Subject: [issue33216] [3.5] Wrong order of stack for CALL_FUNCTION_VAR and
 CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1534434660.89.0.56676864532.issue33216@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I opened bpo-34413 to address how the bytecode change is not mentioned in the porting section of the 3.5 "What's New" doc.  In retrospect (I didn't notice that this issue was still open), I suppose that doesn't need a separate issue so feel free to close #34413 in favor of this one. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33216>
_______________________________________

From report at bugs.python.org  Thu Aug 16 12:40:02 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 16:40:02 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534437602.58.0.56676864532.issue34391@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The "OSError: [Errno 0] Error" failures are caused by session ticket handling in two way shutdown. I reported the issue a while ago https://github.com/openssl/openssl/issues/6262 and it's fixed in OpenSSL git master (to be released as 1.1.1-pre9).

The error in test_data_connection is actually "[SSL] shutdown while in init". The dummy server code is failing, because the client starts a two way shutdown before the full handshake has been established. A simple recv() call is good enough to finalize the handshake.

----------
assignee:  -> christian.heimes
components: +SSL
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 12:45:25 2018
From: report at bugs.python.org (Jonathan Hadida)
Date: Thu, 16 Aug 2018 16:45:25 +0000
Subject: [issue34414] Absolute imports conflict with local files
Message-ID: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>


New submission from Jonathan Hadida <ariel.hadida at gmail.com>:

This submission follows a post on StackOverflow: https://stackoverflow.com/q/51878397/472610

I have reproduced the unexpected behaviour with multiple python versions, either with a Homebrew install, or using Anaconda/Miniconda. Note that comments to the post on StackOverflow indicate that this behaviour could only be reproduced on Windows and Linux using conda with late versions of Python.


THE ISSUE
---------

Absolute imports seem to conflict with local files (not in any module). 
This is at odds with the documented behaviour (https://docs.python.org/3/tutorial/modules.html#the-module-search-path):

"When a module named spam is imported, the interpreter first searches for a built-in module with that name."


STEPS TO REPRODUCE
------------------

STEP 1:
On OSX, use either:

 - A Homebrew-installed version (e.g. /usr/local/bin/python2 or 3)
 - A Miniconda2 or 3 installation
 - An Anaconda3 v5.2.0 installation (not tested with other versions, nor Anaconda2)

NOTE: in cases 1 and 2, you need to install numpy manually.


STEP 2:
Create a directory structure as follows:

  .
  ??? foo
      ??? a.py
      ??? math.py

  1 directory, 2 files

where a.py contains "import numpy", and math.py contains "x++" (intentionally invalid).
For example, the following bash code sets this up in a temporary folder:

  D=$(mktemp -d)
  mkdir "$D/foo"
  echo "import numpy" >| "$D/foo/a.py"
  echo "x++" >| "$D/foo/math.py"


STEP 3:
Go to that directory (the one containing folder "foo"), and run:

  <PythonExecutableFromStep1> foo/a.py

The previous command causes the following error, for example using /usr/local/bin/python3 (Homebrew):

Traceback (most recent call last):
  File "foo/a.py", line 1, in <module>
    import numpy
  File "/usr/local/lib/python3.6/site-packages/numpy/__init__.py", line 142, in <module>
    from . import add_newdocs
  File "/usr/local/lib/python3.6/site-packages/numpy/add_newdocs.py", line 13, in <module>
    from numpy.lib import add_newdoc
  File "/usr/local/lib/python3.6/site-packages/numpy/lib/__init__.py", line 3, in <module>
    import math
  File "/private/var/folders/j7/kd8mc69j25j0yw50q_08wmlm0000gt/T/tmp.FfJzdVuG/foo/math.py", line 1
    x++
      ^
SyntaxError: invalid syntax


PROBLEM:
The statement "import math" in numpy/lib/__init__.py should not resolve to foo/math.py, but rather, it should find the standard module "math".


ADDITIONAL INFO
---------------

Although I do not know what this list should look like, I would expect the list of builtin modules to be larger than this:

> python3 -c "import sys; print(sys.builtin_module_names)"
('_ast', '_codecs', '_collections', '_functools', '_imp', '_io', '_locale', '_operator', '_signal', '_sre', '_stat', '_string', '_symtable', '_thread', '_tracemalloc', '_warnings', '_weakref', 'atexit', 'builtins', 'errno', 'faulthandler', 'gc', 'itertools', 'marshal', 'posix', 'pwd', 'sys', 'time', 'xxsubtype', 'zipimport')

> python2 -c "import sys; print sys.builtin_module_names"
('__builtin__', '__main__', '_ast', '_codecs', '_sre', '_symtable', '_warnings', '_weakref', 'errno', 'exceptions', 'gc', 'imp', 'marshal', 'posix', 'pwd', 'signal', 'sys', 'thread', 'xxsubtype', 'zipimport')

----------
components: macOS
messages: 323609
nosy: jhadida, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Absolute imports conflict with local files
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Thu Aug 16 12:51:26 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 16:51:26 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534438286.11.0.56676864532.issue34391@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +8261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 12:55:56 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 16 Aug 2018 16:55:56 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534438556.59.0.56676864532.issue34414@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is expected behaviour: When your run a script the directory containing the script is added to the start of sys.path. Running "python3.6 a/foo.py" therefore adds "a" to the start of sys.path, and "math.py" then shadows the stdlib module "math".

This has nothing to do with absolute imports. That is shown by "python3.6 -m foo.a". This runs the code in foo/a.py as module foo.a, and "math.py" is now only accessible as "foo.math" (it won't shadow the builtin module "math", even if you add "import math" to foo/a.py).

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Thu Aug 16 13:02:32 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 16 Aug 2018 17:02:32 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534438952.7.0.56676864532.issue34395@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
pull_requests: +8262

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Thu Aug 16 13:13:11 2018
From: report at bugs.python.org (Jonathan Hadida)
Date: Thu, 16 Aug 2018 17:13:11 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534439591.56.0.56676864532.issue34414@psf.upfronthosting.co.za>


Jonathan Hadida <ariel.hadida at gmail.com> added the comment:

Thank you for your quick reply.

How can this be expected behaviour? Could I please kindly ask you to point to an documented explanation, specifically for why the folder is PREpended to sys.path (put before), instead of being APpended (put after).

The fact that local files conflict with absolute imports _within dependent modules_ is nothing short of a hack (think from the point of view of the dependencies themselves), and IMO clearly conflicts with the idea of absolute imports in the first place. This is crazy!

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Thu Aug 16 13:43:48 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 17:43:48 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534441428.2.0.56676864532.issue34391@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 1590c393360df059160145e7475754427bfc6680 by Christian Heimes in branch 'master':
bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787)
https://github.com/python/cpython/commit/1590c393360df059160145e7475754427bfc6680


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 13:44:13 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 17:44:13 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534441453.9.0.56676864532.issue34391@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8263

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 13:44:25 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Aug 2018 17:44:25 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534441465.67.0.56676864532.issue34391@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 13:46:49 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 17:46:49 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534441609.61.0.56676864532.issue34391@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8265

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 14:27:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Aug 2018 18:27:58 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534444078.93.0.56676864532.issue34410@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Davin, is there anything itertools.tee() can do about this or is this a multiprocessing issue?

----------
nosy: +davin, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Thu Aug 16 14:58:06 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 16 Aug 2018 18:58:06 +0000
Subject: [issue20849] add exist_ok to shutil.copytree
In-Reply-To: <1393908922.06.0.91052425832.issue20849@psf.upfronthosting.co.za>
Message-ID: <1534445886.96.0.56676864532.issue20849@psf.upfronthosting.co.za>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
pull_requests: +8266

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20849>
_______________________________________

From report at bugs.python.org  Thu Aug 16 15:33:06 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 16 Aug 2018 19:33:06 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
 setuid/setgit bits
In-Reply-To: <1534433665.35.0.56676864532.issue17180@psf.upfronthosting.co.za>
Message-ID: <5cd971b7-1d14-6dab-6890-809fec66ce98@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 16/08/2018 17:34, Ronald Oussoren wrote:
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
>
> I don't understand this clarification:
>
>> Clarification: while Mac/OS falls under "posix" in python terms - maybe
>> "breakage" will need to be accepted,
>> or, for "back-ports" Mac/OS will be "as if root or super-user" and use
>> an additional (optional) argument in 3.8 and beyond
>> to keep backwards compatibility.
> AFAIK macOS should behave just like other posix-y platforms here.  In particular, I've verified that cp(1) behaves the same as on other platforms: the SUID bit is stripped when copying a setuid file.
Glad to hear!
>
> Do you have a reason to assume that macOS is special here?
No reason to assume that macOS is different. "They" are all called
"posix" by python (Linux, macOS, AIX, FreeBSD, and I am sure there is
something else I have forgotten). So, I was trying to neither assume
that macOS is more "posix" or more "gnu". As the comments refer to gnu
coreutils behavior, not "posix" behavior (chmod --reference...) I am
looking for responses to be able to come up with better ideas for tests
we need - and then define/design code that meets the demands of the tests.

I was expecting or hoping macOS would behave as you describe but I was
also trying to prepare myself for a discussion of macOS user experience
being a discord.
>
>
> P.S. macOS is spelled macOS, not Mac/OS
Should be clear I am not a macOS user. Corrected!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Thu Aug 16 15:37:22 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 19:37:22 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534448242.75.0.56676864532.issue34391@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 870247a57e84ccaa3f6a6ce955f4168632b967a8 by Christian Heimes (Miss Islington (bot)) in branch '3.7':
[3.7] bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) (GH-8789)
https://github.com/python/cpython/commit/870247a57e84ccaa3f6a6ce955f4168632b967a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 15:38:05 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 19:38:05 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534448285.89.0.56676864532.issue34391@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset cabe916dc694997d4892b58986e73a713d5a2f8d by Christian Heimes (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) (#8790)
https://github.com/python/cpython/commit/cabe916dc694997d4892b58986e73a713d5a2f8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 15:38:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 16 Aug 2018 19:38:46 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534448326.5.0.56676864532.issue34391@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 2ec530cd5537dfda5ca0af6ac696e45013ed31d2 by Christian Heimes in branch '2.7':
[2.7] bpo-34391: Fix ftplib test for TLS 1.3 (GH-8787) (GH-8791)
https://github.com/python/cpython/commit/2ec530cd5537dfda5ca0af6ac696e45013ed31d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Thu Aug 16 15:52:26 2018
From: report at bugs.python.org (Semyon)
Date: Thu, 16 Aug 2018 19:52:26 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
Message-ID: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>


New submission from Semyon <simeon+bpo at maryasin.name>:

There is a typo in the docstring for logging.Formatter:

> default value of "%s(message)\\n" is used.

I am sure it should be different (and in sync with the actual value):

> default value of "%(message)s\\n" is used.

The problem is in py2.7, py3.7 and most likely other versions.

----------
components: Library (Lib)
messages: 323618
nosy: MarSoft
priority: normal
severity: normal
status: open
title: Typo in logging.Formatter docstring
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Thu Aug 16 15:53:47 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 16 Aug 2018 19:53:47 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534449227.37.0.56676864532.issue34217@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

> New windows will support case sensitive filesystem too.

NTFS in Windows 10 supports a flag to mark a directory as case sensitive [*] via NtSetInformationFile: FileCaseSensitiveInformation, which can be set from the command line via fsutil.exe. In recent builds this flag was made inheritable by child directories, so it doesn't have to be set individually on every directory in a tree. This feature was added for inter-operation with (WSL) Linux programs. It's not intended for system directories such as "Windows Kits".

> can you tell me where you got your lowercased named files from?

IIRC, MinGW lower-cases the filenames in its modified version of the SDK.

---

[*] Prior to Windows XP, case-sensitive file access was possible via FILE_FLAG_POSIX_SEMANTICS (CreateFile) and FIND_FIRST_EX_CASE_SENSITIVE (FindFirstFileEx). Windows XP (the first consumer version of NT) broke those flags by adding a (default-enabled) global flag in the kernel object manager that makes all device and file access case-insensitive -- regardless of the system call's OBJ_CASE_INSENSITIVE flag. Now in Windows 10 they're bringing back selective case sensitivity in NTFS, but this time using a per-directory flag that overrides the API. It seems they don't care that this breaks the existing OBJ_CASE_INSENSITIVE flag in the NT API. IMO, this could have been handled more cleanly by combining the per-directory flag with one or two new API flags.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 17:15:03 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 16 Aug 2018 21:15:03 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
Message-ID: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

I was recently debugging some multithreaded Rust code that was deadlocking, and I tracked it down to what I'm fairly certain is a bug somewhere in PyCapsule_Import, where it seems that PyCapsule_Import releases the GIL without first acquiring it.

I've attached a MWE of a multi-threaded application that is able to simultaneously acquire the GIL twice. The relevant portion is here:

void *acquire_gil(void *arg) {
    bool import = ((arg_t *)arg)->import;
    int n = ((arg_t *)arg)->id;

    printf("Waiting for GIL (%d)\n", n);
    int gstate = PyGILState_Ensure();
    printf("Gil acquired! (%d)\n", n);
    usleep(125000);
    if (import) {
        PyCapsule_Import(CAPSULE_NAME, 0);
    }
    usleep(125000);
    PyGILState_Release(gstate);
    printf("Gil released! (%d)\n", n);
    return NULL;
}

If you run it with `./gil` such that the PyCapsule_Import call is never reached, you get:

    Waiting for GIL (0)
    Gil acquired! (0)
    Waiting for GIL (1)
    Gil released! (0)
    Gil acquired! (1)
    Gil released! (1)

However, if you run with `./gil import` such that PyCapsule_Import is reached, you get (emphasis mine):

    Waiting for GIL (0)
    Gil acquired! (0)
    Waiting for GIL (1)
    **Gil acquired! (1)**
    **Gil released! (1)**
    Gil released! (0)

For convenience sake, I have created a small repo with a make file for the PoC: https://github.com/pganssle/capsule-gil-poc

I have tested this on version 3.6.6 and 3.7.0. The makefile works in a virtualenv, but you have to manually tweak the PY_MAJOR and PY_MINOR variables in Makefile because I didn't get too fancy with it.

----------
files: main.c
messages: 323620
nosy: p-ganssle, pablogsal
priority: normal
severity: normal
status: open
title: PyCapsule_Import seems to release the GIL without acquiring it
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47753/main.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 17:31:56 2018
From: report at bugs.python.org (Erik Janssens)
Date: Thu, 16 Aug 2018 21:31:56 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534455116.35.0.56676864532.issue34217@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

The lowercase headers are indeed part of the mingw-w64 SDK, which is the most convenient option to cross compile on a linux host for a windows target.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 17:40:55 2018
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Thu, 16 Aug 2018 21:40:55 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534455655.71.0.56676864532.issue34416@psf.upfronthosting.co.za>


Change by Eric N. Vander Weele <ericvw at gmail.com>:


----------
nosy: +ericvw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 17:48:12 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 16 Aug 2018 21:48:12 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534456092.36.0.56676864532.issue34217@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Have you posted to their mailing list to ask why they use different casing from the official SDK and whether they would consider supporting both (via symlink, presumably)?

I think it would be strange for CPython to add a style rule for a non-supported toolset. The supported tooling will default to using the correct case for the header files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 17:51:44 2018
From: report at bugs.python.org (Phillip M. Feldman)
Date: Thu, 16 Aug 2018 21:51:44 +0000
Subject: [issue34417] imp.find_module reacts badly to iterator
Message-ID: <1534456304.96.0.56676864532.issue34417@psf.upfronthosting.co.za>


New submission from Phillip M. Feldman <Phillip.M.Feldman at gmail.com>:

`imp.find_module` goes down in flames if one tries to pass an iterator rather than a list of folders.  Firstly, the message that it produces is somewhat misleading:

   RuntimeError: sys.path must be a list of directory names

Secondly, it would be helpful if one could pass an iterator. I'm thinking in particular of the situation where one wants to import something from a large folder tree, and the module in question is likely to be found early in the search process, so that it is more efficient to explore the folder tree incrementally.

----------
components: Library (Lib)
messages: 323623
nosy: Phillip.M.Feldman at gmail.com
priority: normal
severity: normal
status: open
title: imp.find_module reacts badly to iterator
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34417>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:07:35 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 16 Aug 2018 22:07:35 +0000
Subject: [issue8478] tokenize.untokenize first token missing failure case
In-Reply-To: <1271816312.19.0.485614247328.issue8478@psf.upfronthosting.co.za>
Message-ID: <1534457255.71.0.56676864532.issue8478@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8478>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:08:40 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 16 Aug 2018 22:08:40 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534457320.34.0.56676864532.issue34416@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Using a modified version of Python 3.7.0 that prints "Releasing GIL" whenever PyGILState_Release, I get this:

Waiting for GIL (0)
Gil acquired! (0)
Waiting for GIL (1)
Gil acquired! (1)
Releasing GIL
Gil released! (0)
Releasing GIL
Gil released! (1)

So whatever is allowing the GIL to be acquired twice is not calling PyGILState_Release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:20:11 2018
From: report at bugs.python.org (Erik Janssens)
Date: Thu, 16 Aug 2018 22:20:11 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534458011.67.0.56676864532.issue34217@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

As I understand it, if mingw-w64 would change to camelcase headers, it would break backwards compatibility, since a lot of windows source code uses file names in includes that differ from those on this, which works in MSVC, so it goes unnoticed.  There is no good solution.

Even if camelcase headers would be available, the CPython source code would break in much more places.

I agree that it would be strange to have a style rule for a specific toolset, however mixing different styles is even stranger.

The current situation is that 100% of the windows includes are lowercase and allow cross compilation.  I would tend to see that as an advantage.

If a more comprehensive solution would be available, that would be ideal of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:22:20 2018
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 16 Aug 2018 22:22:20 +0000
Subject: [issue20849] add exist_ok to shutil.copytree
In-Reply-To: <1393908922.06.0.91052425832.issue20849@psf.upfronthosting.co.za>
Message-ID: <1534458140.39.0.56676864532.issue20849@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I think this feature request is reasonable for 2 reasons:

1) As it stands if dst directory exists copytree() cannot be used. The only possible workaround is using rmtree(dst) first, but that doesn't seem to make much sense. The change may look extremely easy but the fact that copytree() cannot be used in a specific circumstance justifies the cost of introducing a new argument, basically because there is no other way around it.

2) "cp -r" does this by default, which is probably indicative (I don't think the default should be True though).

I think the new argument should be called "dirs_exists_ok" instead of "exists_ok" though, so that it's clear that the behavior does not affect files.

[ R. David Murray ]
> I do not think that *just* making it OK for the destination directory to exist would be a good API.

I don't think that refusing (or allowing) to copy existing files is a common enough use case to justify the addition of a new parameter (note: also "cp" does not provide this use case). If such a  behavior is desired the user can simply provide its own custom "copy_function".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20849>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:33:44 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Aug 2018 22:33:44 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534458824.26.0.56676864532.issue34416@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Breaking in take_gil and drop_gil I get this trace:

Thread 2 "gil" hit Breakpoint 1, 0x000055555559563d in acquire_gil ()
Thread 3 "gil" hit Breakpoint 1, 0x000055555559563d in acquire_gil ()
Waiting for GIL (0)
Waiting for GIL (1)
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Gil acquired! (0)
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Gil acquired! (1)
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=0x0) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=0x0) at Python/ceval_gil.h:150
Gil released! (0)


which seems normal to me. This is tested on current master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:34:36 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Aug 2018 22:34:36 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534458876.47.0.56676864532.issue34416@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg323627

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:35:16 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Aug 2018 22:35:16 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534458916.59.0.56676864532.issue34416@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Breaking in take_gil and drop_gil I get this trace:

Thread 2 "gil" hit Breakpoint 1, 0x000055555559563d in acquire_gil ()
Thread 3 "gil" hit Breakpoint 1, 0x000055555559563d in acquire_gil ()
Waiting for GIL (0)
Waiting for GIL (1)
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Gil acquired! (0)
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Gil acquired! (1)
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:150
Thread 3 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7fffe8000b30) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 3 "gil" hit Breakpoint 3, drop_gil (tstate=0x0) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
 Gil released! (1)
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:150
Thread 2 "gil" hit Breakpoint 2, take_gil (tstate=tstate at entry=0x7ffff0000f40) at Python/ceval_gil.h:192
Thread 2 "gil" hit Breakpoint 3, drop_gil (tstate=0x0) at Python/ceval_gil.h:150
Gil released! (0)


which seems normal to me. This is tested on current master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:59:09 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 16 Aug 2018 22:59:09 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534460349.8.0.56676864532.issue34217@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> The current situation is that 100% of the windows includes are lowercase and allow cross compilation.

Please be precise with what you are saying - the "current situation" is only so because you proposed changes and got them merged without proper discussion, and "allow cross compilation" with only one alternate toolset. Pretending this is the status quo is dishonest, so please don't insult me like that.

> if mingw-w64 would change to camelcase headers, it would break backwards compatibility

I'm not recommending camel case - I'm recommending matching the casing used for each file in the official SDK (which I agree is a weird mix, but there are certainly compatibility reasons involved in keeping them this way). And yes, it would be a compatibility break for the clones of the SDK, but to a large extent that is their fault for choosing different casing in the first place, so I'm only a little bit sympathetic to that argument.


What I'm mostly opposed to is the very weak bug report and the random selection of changes that came with it. Failing to compile on an unsupported toolset is not an immediate "must-fix" issue, and it really ought to go through the affected platform experts so they can confirm acceptable impact on developers who are using the supported tools. There also needs to be this central point so that, assuming we decide to keep them this way, the next person who comes in and complains that the casing doesn't match the actual files is given the correct explanation - otherwise we'll keep switching them back and forth forever.

You're also likely to face a maintenance burden for this change, since there is currently no rule or validation that will prevent people from adding properly cased includes in the future (as I hinted, most IDEs on Windows will autocorrect filename casing for headers). If you want one, propose a change to PEP 7 on python-dev, and if it's approved then you can add a build step to validate. Otherwise, you'll have to track changes that are made and fix them as necessary. Without an explicit rule, our default position is "whatever the native target platform/tools prefer".

I hope that explains the position a bit better, and why I push back against changes with insufficient justification being provided. At this point, I'm not going to revert these particular changes, as the cases where they will affect native developers are startlingly few these days, but I'm also explicitly saying that this does not mean open-season for all the fixes required for mingw to be happy. Each one will be taken on its merits (primarily compatibility and maintainability), at least until someone has committed to fully support the toolset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Thu Aug 16 18:59:53 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 16 Aug 2018 22:59:53 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534460393.75.0.56676864532.issue34414@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

See https://docs.python.org/3/tutorial/modules.html#the-module-search-path

Calling this a "hack", and "crazy", is not the way to get volunteers to help you with your issue. Please show a little more tolerance, please.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Thu Aug 16 19:02:21 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Aug 2018 23:02:21 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534460541.73.0.56676864532.issue34416@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Summary of how I see this dump:

1) Thread 2 tries to get the GIL.
2) Thread 3 tries to get the GIL.
3 Gil acquired! (0)
4) Thread 2 drops the GIL, which means that thread 2 managed to get it before.
5) Gil acquired! (1)
6) Thread 2 tries to get the GIL.
7) Thread 3 drops the GIL which means that thread 2 managed to get the GIL.

... thread 2 and 3 battle for the GIL

8) Gil released! (1)


... thread 2 and 3 battle for the GIL


9) Gil released! (0)

It does not seem to me that two threads have the GIL at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Thu Aug 16 22:18:16 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Fri, 17 Aug 2018 02:18:16 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534472296.58.0.56676864532.issue34410@psf.upfronthosting.co.za>


Carlo Rosati <crosati777 at icloud.com> added the comment:

I've actually written a few workarounds that should be considered a multiprocessing specific tee function. I need feedback/critique on these. Hopefully we can all agree on one solution that's the best. It is unfortunate that the multiprocessing manager does not provide a dequeue.

The first one I wrote uses a managed list. 

def multiprocessing_tee(iterable, n=2):
    """Write a multiprocessing safe itertools.tee"""
    it = iter(iterable)
    m = multiprocessing.Manager()
    mylock = m.Lock()
    lists = [m.list() for i in range(n)]
    def gen(local_list):
        for i in itertools.count():
            with mylock:
                if not local_list:         # when the local list is empty
                    newval = next(it)      # fetch a new value and
                    for l in lists:        # load it to all the lists
                        l.append(newval)
            yield local_list.pop(0)
    return tuple(gen(l) for l in lists)

The second two implementations use queues. 

def multiprocessing_tee_q(iterable, n=2):
    """Write a multiprocessing safe itertools.tee"""
    it = iter(iterable)
    m = multiprocessing.Manager()
    lock = m.Lock()
    queues = [m.Queue(-1) for _ in range(n)] # -1 means infinite maxsize (so puts won't block)
    def gen(myqueue):
        while True:
            with lock: # no one else touches anything
                try:
                    newval = myqueue.get_nowait()
                except Queue.Empty:
                    newval = next(it)
                    for q in queues:
                        q.put(newval)
                    newval = myqueue.get()
            yield newval
    return tuple(gen(q) for q in queues)

class Sentinel(object):
    """used as Queue Sentinel"""

def multiprocessing_tee_q2(iterable, n=2):
    """Write a multiprocessing safe itertools.tee"""
    it = iter(iterable)
    m = multiprocessing.Manager()
    lock = m.Lock()
    queues = [m.Queue(-1) for _ in range(n)] # -1 means infinite maxsize (so puts won't block)
    def gen(myqueue):
        while True:
            try:
                retval = myqueue.get_nowait()
            except Queue.Empty:
                # what happens if the other process puts last item in my queue before i get lock?
                with lock: # no one else touches anything
                    try:
                        newval = next(it)
                    except StopIteration:
                        newval = Sentinel
                    for q in queues:
                        q.put(newval)
                retval = myqueue.get()
            if retval is Sentinel:
                raise StopIteration
            yield retval
    return tuple(gen(q) for q in queues)

I'm just throwing out my sketches here. I'm hoping the more experienced here can weigh in on these implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Thu Aug 16 22:21:27 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Fri, 17 Aug 2018 02:21:27 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534472487.13.0.56676864532.issue34410@psf.upfronthosting.co.za>


Carlo Rosati <crosati777 at icloud.com> added the comment:

`for i in itertools.count()` in the first implementation I posted should be `while True`. I was using that for debugging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Fri Aug 17 00:19:47 2018
From: report at bugs.python.org (Jens Troeger)
Date: Fri, 17 Aug 2018 04:19:47 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1534479587.36.0.56676864532.issue24218@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

Thanks David: PR on Github (which is R/O) or where should I submit to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Fri Aug 17 00:19:52 2018
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 17 Aug 2018 04:19:52 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1534479592.08.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by Aivar Annamaa <aivar.annamaa at gmail.com>:


----------
nosy: +Aivar.Annamaa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 17 00:21:47 2018
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 17 Aug 2018 04:21:47 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1534479707.15.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by Aivar Annamaa <aivar.annamaa at gmail.com>:


----------
title: inspect.getsource() returns incorrect source lines -> inspect.getsource() returns incorrect source lines at the module level
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 17 01:36:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Aug 2018 05:36:27 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1534484187.41.0.56676864532.issue34395@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ae1f0127298b1193618062fd0c8a3b434656e780 by Serhiy Storchaka (Sergey Fedoseev) in branch '2.7':
bpo-34395: Fix memory leaks caused by incautious usage of PyMem_Realloc(). (GH-8785)
https://github.com/python/cpython/commit/ae1f0127298b1193618062fd0c8a3b434656e780


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Fri Aug 17 02:02:40 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 17 Aug 2018 06:02:40 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534485760.75.0.56676864532.issue34414@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This has nothing to do with absolute imports at all.

You have two toplevel modules in an entry on sys.path that is before the stdlib (see the earlier message by Eric V. Smit for documentation on how the path is initialised). The name of one of those modules shadows the name of a stdlib module.

Absolute imports are what avoids a similar problem in another situation. Given:

   foo/
     __init__.py
     a.py
     math.py

When you import "foo.a" the code in "a.py" is executed as a module in package. When that code does "import math" absolute imports ensure that this always references the stdlib version, not the module in the package. Module "foo.a" should use "from . import math" (relative import) or "import foo.math" (absolute import) to access functionality in foo.math.

Again, this is not a bug but normal behaviour.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Fri Aug 17 02:08:18 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Aug 2018 06:08:18 +0000
Subject: [issue34413] Porting section of 3.5 "What's New" doc does not mention
 bytecode changes.
In-Reply-To: <1534434373.24.0.56676864532.issue34413@psf.upfronthosting.co.za>
Message-ID: <1534486098.75.0.56676864532.issue34413@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I don't think this needs to be exposed in What's New. This is a very low level implementation detail and isn't interested for most users. I think it would just distract attention from more significant changes.

But it may be worth to document this change in the NEWS file.

Changes in BUILD_MAP affected more users and also was not mentioned in the NEWS file. It was documented in the dis module documentation only in issue26213.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34413>
_______________________________________

From report at bugs.python.org  Fri Aug 17 03:45:47 2018
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 17 Aug 2018 07:45:47 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
Message-ID: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at rittau.biz>:

The documentation at https://docs.python.org/3/library/urllib.request.html#urllib.request.HTTPErrorProcessor does not list the two arguments "request" and "response" that HTTPErrorProcessor.http_response() and https_response() actually require. (I checked the implementation in Python 3.5 and 3.7.)

----------
assignee: docs at python
components: Documentation
messages: 323638
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: Arguments missing from documentation for HTTPErrorProcessor.http(s)_response()
versions: Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 03:53:41 2018
From: report at bugs.python.org (Sebastian Rittau)
Date: Fri, 17 Aug 2018 07:53:41 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534492421.25.0.56676864532.issue34418@psf.upfronthosting.co.za>


Change by Sebastian Rittau <srittau at rittau.biz>:


----------
keywords: +patch
pull_requests: +8267
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:11:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Aug 2018 09:11:55 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1534497115.52.0.56676864532.issue20104@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Benjamin, Gregory, could you please look at PR 6693? Is it what you want?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20104>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:28:09 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 09:28:09 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c5beb99e8bf5eb04cc836d53fa9aee
Message-ID: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

It seems like an oversight of the author, though it is not clear why this happily compiles with clang 3.4.1 on FreeBSD 10.4-STABLE and GCC on RHEL6.

The error is (HP-UX 11.31 and HP C/aC++ B3910B A.06.28.03 [Dec 13 2016]):

> /opt/aCC/bin/cc -Ae +z -O -I./Include -I. -I/usr/local/include -I/var/osipovmi/cpython/Include -I/var/osipovmi/cpython -c /var/osipovmi/cpython/Modules/selectmodule.c -o build/temp.hp-ux-B.11.31-ia64-3.8-pydebug/var/osipovmi/cpython/Modules/selectmodule.o
> "/var/osipovmi/cpython/Modules/selectmodule.c", line 412: warning #4232-D:
>           conversion from "PyObject *" to a more strictly aligned type
>           "PyDictObject *" may cause misaligned access
>       self->ufd_len = PyDict_GET_SIZE(self->dict);
>                       ^
> 
> "/var/osipovmi/cpython/Modules/selectmodule.c", line 849: error #2130:
>           expected a "{"
>   static PyObject *
>   ^
> 
> "/var/osipovmi/cpython/Modules/selectmodule.c", line 898: error #2101:
>           "timeout_obj" has already been declared in the current scope
>       PyObject *result_list = NULL, *timeout_obj = NULL;
>                                      ^
> 
> 2 errors detected in the compilation of "/var/osipovmi/cpython/Modules/selectmodule.c".


caused by:

> +static PyObject *
> +select_devpoll_modify_impl(devpollObject *self, int fd,
> +                           unsigned short eventmask)
> +/*[clinic end generated code: output=bc2e6d23aaff98b4 input=f0d7de3889cc55fb]*/
>  static PyObject *
>  devpoll_modify(devpollObject *self, PyObject *args)
>  {
> -    return internal_devpoll_register(self, args, 1);
> +    return internal_devpoll_register(self, fd, eventmask, 1);
>  }

Signature change, but prototype has not been changed.

>  static PyObject *
> -poll_poll(pollObject *self, PyObject *args)
> +select_poll_poll_impl(pollObject *self, PyObject *timeout_obj)
> +/*[clinic end generated code: output=876e837d193ed7e4 input=7a446ed45189e894]*/
>  {
> -    PyObject *result_list = NULL, *timeout_obj = NULL;
> +    PyObject *result_list = NULL;
>      int poll_result, i, j;
>      PyObject *value = NULL, *num = NULL;
>      _PyTime_t timeout = -1, ms = -1, deadline = 0;
>      int async_err = 0;
> 
> -    if (!PyArg_ParseTuple(args, "|O:poll", &timeout_obj)) {
> -        return NULL;
> -    }
> -
> -    if (timeout_obj != NULL && timeout_obj != Py_None) {
> +    if (timeout_obj != Py_None) {

timeout_obj has been added to the function signature, but the internal NULL assignment has not been removed.

----------
components: Build, Library (Lib)
messages: 323640
nosy: michael-o
priority: normal
severity: normal
status: open
title: selectmodule.c does not compile on HP-UX due to bpo-31938/6dc57e2a20c5beb99e8bf5eb04cc836d53fa9aee
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:37:54 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 09:37:54 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534498674.01.0.56676864532.issue34419@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
title: selectmodule.c does not compile on HP-UX due to bpo-31938/6dc57e2a20c5beb99e8bf5eb04cc836d53fa9aee -> selectmodule.c does not compile on HP-UX due to bpo-31938/6dc57e2a20c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:41:01 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Aug 2018 09:41:01 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534498861.08.0.56676864532.issue34419@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy (C)
nosy: +taleinat
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:47:35 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 09:47:35 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534499255.72.0.56676864532.issue34418@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c53aaec793e018edef4e72a3edbd338b10db10aa by Berker Peksag (Sebastian Rittau) in branch 'master':
bpo-34418: Fix HTTPErrorProcessor documentation (GH-8793)
https://github.com/python/cpython/commit/c53aaec793e018edef4e72a3edbd338b10db10aa


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:48:23 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 09:48:23 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534499303.5.0.56676864532.issue34418@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8269

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:48:34 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 09:48:34 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534499314.45.0.56676864532.issue34418@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 05:50:50 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 09:50:50 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534499450.65.0.56676864532.issue34419@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

A PR is in preparation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:02:14 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 10:02:14 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534500134.31.0.56676864532.issue34418@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 05d89ef785ab3cb6dd28f10f312f68f8e6a163ce by Miss Islington (bot) in branch '3.7':
bpo-34418: Fix HTTPErrorProcessor documentation (GH-8793)
https://github.com/python/cpython/commit/05d89ef785ab3cb6dd28f10f312f68f8e6a163ce


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:05:30 2018
From: report at bugs.python.org (Jonathan Hadida)
Date: Fri, 17 Aug 2018 10:05:30 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534500330.47.0.56676864532.issue34414@psf.upfronthosting.co.za>


Jonathan Hadida <ariel.hadida at gmail.com> added the comment:

Thanks again for your reply, I really appreciate your time.

Every language I know has reserved keywords, and a restricted syntax. Nothing to complain about there. Banning the use of tabs (PEP8) is pretty odd; but restricting file-names is just a whole new level. 

Is the list of python modules set in stone somewhere, or are we supposed to rename scripts every time a new module with a conflicting name is introduced?

Should we start checking for the authenticity of the modules loaded when writing a Python library? Maybe keep a version-specific, platform-specific list of checksums and iterate all builtin modules at the beginning of any script?

Not being able to tell whether "import math" will load the standard math module, not only because of the names of local files, **but also because of those surrounding ANY script that will ever load my library**; are we supposed to control for the user's folders too then? I would happily stop complaining and just reverse sys.path at the beginning of my script if I could, but I cannot even trust that "import sys" will work as intended!

What a feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:35:55 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 10:35:55 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534502155.84.0.56676864532.issue34418@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 02c4d4b6dcd772ec3a7fdca517118f3fa53b0b88 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-34418: Fix HTTPErrorProcessor documentation (GH-8793)
https://github.com/python/cpython/commit/02c4d4b6dcd772ec3a7fdca517118f3fa53b0b88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:37:24 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 10:37:24 +0000
Subject: [issue34418] Arguments missing from documentation for
 HTTPErrorProcessor.http(s)_response()
In-Reply-To: <1534491947.25.0.56676864532.issue34418@psf.upfronthosting.co.za>
Message-ID: <1534502244.29.0.56676864532.issue34418@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report and for the patch! 3.5 is in security-fix-only mode, so it doesn't get documentation fixes anymore.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.6, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34418>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:48:58 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 10:48:58 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534502938.67.0.56676864532.issue34419@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8271
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:48:58 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 10:48:58 +0000
Subject: [issue31938] Convert selectmodule.c to Argument Clinic
In-Reply-To: <1509744030.41.0.213398074469.issue31938@psf.upfronthosting.co.za>
Message-ID: <1534502938.76.0.665841612001.issue31938@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
pull_requests: +8272

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31938>
_______________________________________

From report at bugs.python.org  Fri Aug 17 06:54:30 2018
From: report at bugs.python.org (Jonathan Hadida)
Date: Fri, 17 Aug 2018 10:54:30 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534503270.42.0.56676864532.issue34414@psf.upfronthosting.co.za>


Jonathan Hadida <ariel.hadida at gmail.com> added the comment:

With regards to "This has nothing to do with absolute imports at all.", I would like to point out that the "import math" statement that I am complaining about IS WITHIN THE NUMPY MODULE. So it seems very related to this bug.

How can "import math", **written within NumPy**, be an absolute import if I import numpy from within my own module, but not from a script?  According to your example, NumPy shouldn't have any issue loading the standard math module instead of my local file.

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Fri Aug 17 07:00:54 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 17 Aug 2018 11:00:54 +0000
Subject: [issue34414] Absolute imports conflict with local files
In-Reply-To: <1534437925.07.0.56676864532.issue34414@psf.upfronthosting.co.za>
Message-ID: <1534503654.15.0.56676864532.issue34414@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This behaviour is not a bug, even if it can be confusing at times.

Please read <https://docs.python.org/3/tutorial/modules.html>.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34414>
_______________________________________

From report at bugs.python.org  Fri Aug 17 07:18:12 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 11:18:12 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534504692.53.0.56676864532.issue34381@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8273
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 07:35:13 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 17 Aug 2018 11:35:13 +0000
Subject: [issue14886] json C vs pure-python implementation difference
In-Reply-To: <1337765129.86.0.0917200779683.issue14886@psf.upfronthosting.co.za>
Message-ID: <1534505713.64.0.56676864532.issue14886@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

We have received a notification about this bug for 3.5

----------
nosy: +matrixise
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14886>
_______________________________________

From report at bugs.python.org  Fri Aug 17 07:43:06 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 17 Aug 2018 11:43:06 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534506186.95.0.56676864532.issue34419@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 0e6e7a1e52a53090e33ebef13f8f1fbe9bec2375 by Tal Einat (Michael Osipov) in branch 'master':
bpo-34419: selectmodule.c does not compile on HP-UX due to bpo-31938 (GH-8796)
https://github.com/python/cpython/commit/0e6e7a1e52a53090e33ebef13f8f1fbe9bec2375


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 07:43:07 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 17 Aug 2018 11:43:07 +0000
Subject: [issue31938] Convert selectmodule.c to Argument Clinic
In-Reply-To: <1509744030.41.0.213398074469.issue31938@psf.upfronthosting.co.za>
Message-ID: <1534506187.04.0.902498594338.issue31938@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 0e6e7a1e52a53090e33ebef13f8f1fbe9bec2375 by Tal Einat (Michael Osipov) in branch 'master':
bpo-34419: selectmodule.c does not compile on HP-UX due to bpo-31938 (GH-8796)
https://github.com/python/cpython/commit/0e6e7a1e52a53090e33ebef13f8f1fbe9bec2375


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31938>
_______________________________________

From report at bugs.python.org  Fri Aug 17 07:45:01 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 17 Aug 2018 11:45:01 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534506301.74.0.56676864532.issue34419@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Michael, thanks for catching this and supplying a PR!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 08:01:36 2018
From: report at bugs.python.org (Michael Osipov)
Date: Fri, 17 Aug 2018 12:01:36 +0000
Subject: [issue34419] selectmodule.c does not compile on HP-UX due to
 bpo-31938/6dc57e2a20c
In-Reply-To: <1534498089.92.0.56676864532.issue34419@psf.upfronthosting.co.za>
Message-ID: <1534507296.83.0.56676864532.issue34419@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Bevakasha!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34419>
_______________________________________

From report at bugs.python.org  Fri Aug 17 08:02:57 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 17 Aug 2018 12:02:57 +0000
Subject: [issue14886] json C vs pure-python implementation difference
In-Reply-To: <1337765129.86.0.0917200779683.issue14886@psf.upfronthosting.co.za>
Message-ID: <1534507377.58.0.56676864532.issue14886@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

FWIW, the C implementation of the sequence encoder uses PySequence_Fast(), so adding a lower priority instance check that calls the same encoding function would solve this.

https://github.com/python/cpython/blob/cfa797c0681b7fef47cf93955fd06b54ddd09a7f/Modules/_json.c#L1730

Probably not something to fix in Py3.5/6 anymore, though.

----------
nosy: +scoder
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14886>
_______________________________________

From report at bugs.python.org  Fri Aug 17 08:10:44 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 17 Aug 2018 12:10:44 +0000
Subject: [issue19050] [Windows] fflush called on pointer to potentially closed
 file
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1534507844.36.0.56676864532.issue19050@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I agree this should probably be ignored for security-only branches.  However, AFAIK 2.7 is still in bugfix status, not security-only.  If there's interest, I'm happy to build with AMK's fix on 2.7 on Windows to see if it works, and if so provide a PR.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Fri Aug 17 08:56:55 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 17 Aug 2018 12:56:55 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534510615.37.0.56676864532.issue34416@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> It does not seem to me that two threads have the GIL at the same time.

To be clear, this was never my contention. I was under the impression that if you take the GIL with PyGILState_Ensure(), the GIL was held until you called PyGILState_Release(), as with a traditional lock, so I was puzzled as to why Thread 2 was *releasing* the GIL even though I had very much not released it.

>From our discussion off the issue tracker, it seems that your contention is that any C API calls can arbitrarily release the GIL, and the calling function can not be said to "hold" the GIL. If this is true than this is not a bug and can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Fri Aug 17 09:56:19 2018
From: report at bugs.python.org (sai arjun)
Date: Fri, 17 Aug 2018 13:56:19 +0000
Subject: [issue34420] Complete your registration to Python tracker --
 keysnSwaZe6PtikiEZf4bdIXIiuwFyFZFxp
In-Reply-To: <20180816113813.9CDD8117A17@psf.upfronthosting.co.za>
Message-ID: <1534514179.66.0.094306209913.issueNone@psf.upfronthosting.co.za>


New submission from sai arjun <venkkarjun at yahoo.com>:

I have received the email.

Sent from Mail for Windows 10

From: Python tracker
Sent: 16 August 2018 17:08
To: venkkarjun at yahoo.com
Subject: Complete your registration to Python tracker -- keysnSwaZe6PtikiEZf4bdIXIiuwFyFZFxp

To complete your registration of the user "arjun" with
Python tracker, please do one of the following:

- send a reply to report at bugs.python.org and maintain the subject line as is (the
reply's additional "Re:" is ok),

- or visit the following URL:

https://bugs.python.org/?@action=confrego&otk=snSwaZe6PtikiEZf4bdIXIiuwFyFZFxp

----------
messages: 323657
nosy: arjun
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker -- keysnSwaZe6PtikiEZf4bdIXIiuwFyFZFxp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34420>
_______________________________________

From report at bugs.python.org  Fri Aug 17 10:07:00 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 14:07:00 +0000
Subject: [issue34420] Complete your registration to Python tracker --
 keysnSwaZe6PtikiEZf4bdIXIiuwFyFZFxp
In-Reply-To: <1534514179.66.0.094306209913.issueNone@psf.upfronthosting.co.za>
Message-ID: <1534514820.48.0.56676864532.issue34420@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34420>
_______________________________________

From report at bugs.python.org  Fri Aug 17 10:19:24 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 14:19:24 +0000
Subject: [issue28113] Remove Py_CreateSymbolicLinkW
In-Reply-To: <1473747548.28.0.648303309588.issue28113@psf.upfronthosting.co.za>
Message-ID: <1534515564.33.0.56676864532.issue28113@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Eryk, would you like to address Steve's comments and convert your patch to a GitHub pull request? Let me know if you don't have time to prepare a new patch.

----------
nosy: +berker.peksag
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28113>
_______________________________________

From report at bugs.python.org  Fri Aug 17 11:13:23 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Aug 2018 15:13:23 +0000
Subject: [issue28113] Remove Py_CreateSymbolicLinkW
In-Reply-To: <1473747548.28.0.648303309588.issue28113@psf.upfronthosting.co.za>
Message-ID: <1534518803.66.0.56676864532.issue28113@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

One other thing, I have come across some CI configurations recently where TEMP is not the best choice (e.g. when it's a mount point in a VM/container). It seems likely that at some point we'll centralize the "working directory" for the test suite in a way that can be overridden easily, so using one of the test.support members instead of %TEMP% directly will make that easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28113>
_______________________________________

From report at bugs.python.org  Fri Aug 17 11:22:53 2018
From: report at bugs.python.org (Matej Cepl)
Date: Fri, 17 Aug 2018 15:22:53 +0000
Subject: [issue23847] Add xml pretty print option to ElementTree
In-Reply-To: <1427958110.33.0.788273316254.issue23847@psf.upfronthosting.co.za>
Message-ID: <1534519373.06.0.56676864532.issue23847@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23847>
_______________________________________

From report at bugs.python.org  Fri Aug 17 11:23:10 2018
From: report at bugs.python.org (Matej Cepl)
Date: Fri, 17 Aug 2018 15:23:10 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1534519390.44.0.56676864532.issue14465@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Fri Aug 17 12:05:36 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 17 Aug 2018 16:05:36 +0000
Subject: [issue34417] imp.find_module reacts badly to iterator
In-Reply-To: <1534456304.96.0.56676864532.issue34417@psf.upfronthosting.co.za>
Message-ID: <1534521936.01.0.56676864532.issue34417@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

There are several issues at hand here, Phillip.  I'll enumerate them below.

Thanks for taking the time to let us know about this.  However, I'm closing this issue since realistically the behavior of imp.find_module() isn't going to change, particularly in Python 2.7.  Even though the issue is closed, feel free to reply, particularly about how you are using imp.find_module() (we may be able to point you toward how to use importlib instead).

Also, I've changed this issue's type to "enhancement".  imp.find_module() is working as designed, so what you are looking for is a feature request.  Consequently there's a much higher bar for justifying a change.  Here are reasons why the requested change doesn't reach that bar:

1. Python 2.7 is closed to new features.

So imp.find_module() is not going to change.

2. Python 2.7 is nearing EOL.

We highly recommend that everyone move to Python 3 as soon as possible.  Hopefully you are in a position to do so.  If you're stuck on Python 2.7 then you miss the advantages of importlib, along with a ton of other benefits.

If you are not going to be able to migrate before 2020 then send an email to python-list at python.org asking for recommendations on what to do.

3. Starting in Python 3.4, using the imp module is discouraged/deprecated.

  "Deprecated since version 3.4: The imp package is pending deprecation in favor of importlib." [1]

The importlib package should have everything you need.  What are you using imp.find_module() for?  We should be able to demonstrate the equivalent using importlib.

4. The import machinery is designed around using a list (the builtin type, not the concept) for the "module search path".

* imp.find_module(): "the list of directory names given by sys.path is searched" [2]
* imp.find_module(): "Otherwise, path must be a list of directory names" [2]
* importlib.find_loader() (deprecated): "optionally within the specified path" (which defaults to sys.path) [3]
* importlib.util.find_spec(): doesn't even have a "path" parameter [4]
* ModuleSpec.submodule_search_locations: "List of strings for where to find submodules" [5]
* sys.path: "A list of strings that specifies the search path for modules. ... Only strings and bytes should be added to sys.path; all other data types are ignored during import." [6]


[1] https://docs.python.org/3/library/imp.html#module-imp
[2] https://docs.python.org/3/library/imp.html#imp.find_module
[3] https://docs.python.org/3/library/importlib.html#importlib.find_loader
[4] https://docs.python.org/3/library/importlib.html#importlib.util.find_spec
[5] https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations
[6] https://docs.python.org/3/library/sys.html#sys.path

----------
nosy: +brett.cannon, eric.snow
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34417>
_______________________________________

From report at bugs.python.org  Fri Aug 17 12:55:01 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Aug 2018 16:55:01 +0000
Subject: [issue34416] PyCapsule_Import seems to release the GIL without
 acquiring it
In-Reply-To: <1534454103.63.0.56676864532.issue34416@psf.upfronthosting.co.za>
Message-ID: <1534524901.45.0.56676864532.issue34416@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

"From our discussion off the issue tracker, it seems that your contention is that any C API calls can arbitrarily release the GIL, and the calling function can not be said to "hold" the GIL. If this is true than this is not a bug and can be closed."

Correct, because the GIL is a global lock for the whole process, anyone can release it and then acquire it, leading to interleaving and no one owning their locking of it.

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34416>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:04:57 2018
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Aug 2018 17:04:57 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1534525497.24.0.56676864532.issue24218@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

check out https://devguide.python.org.  (Basically, banch and generate a PR on github).  And please open a new issue for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:06:15 2018
From: report at bugs.python.org (Julien Malard)
Date: Fri, 17 Aug 2018 17:06:15 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
Message-ID: <1534525575.04.0.56676864532.issue34421@psf.upfronthosting.co.za>


Change by Julien Malard <julien.malard at mail.mcgill.ca>:


----------
components: Distutils
nosy: dstufft, eric.araujo, julien.malard
priority: normal
severity: normal
status: open
title: Cannot install package with unicode module names on Windows
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:10:09 2018
From: report at bugs.python.org (Julien Malard)
Date: Fri, 17 Aug 2018 17:10:09 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
Message-ID: <1534525809.25.0.56676864532.issue34421@psf.upfronthosting.co.za>


Change by Julien Malard <julien.malard at mail.mcgill.ca>:


----------
keywords: +patch
pull_requests: +8274
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:21:06 2018
From: report at bugs.python.org (Gabriel Tremblay)
Date: Fri, 17 Aug 2018 17:21:06 +0000
Subject: [issue34422] __name__ not available for classes in typing module
Message-ID: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>


New submission from Gabriel Tremblay <gabriel at delvelabs.ca>:

Types under the typing module used to behave like other python classes regarding the __name__ attribute before Python 3.7. The behavior seems to have changed to a non-standard way.

Py3.6 
>>> from typing import List
>>> dir(List)
['__abstractmethods__', '__add__', '__args__', '__class__', '__contains__', '__delattr__', '__delitem__', 
'__dir__', '__doc__', '__eq__', '__extra__', '__format__', '__ge__', '__getattribute__', '__getitem__', '_
_gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__init_subclass__', '__iter__', '__le__', '__len_
_', '__lt__', '__module__', '__mul__', '__ne__', '__new__', '__next_in_mro__', '__orig_bases__', '__origin
__', '__parameters__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__
', '__setitem__', '__sizeof__', '__slots__', '__str__', '__subclasshook__', '__tree_hash__', '_abc_cache',
 '_abc_negative_cache', '_abc_negative_cache_version', '_abc_registry', 'append', 'clear', 'copy', 'count'
, 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
>>> List.__name__
'List'


Py3.7:
>>> from typing import List
>>> dir(List)
['__args__', '__call__', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattr__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__instancecheck__', '__le__', '__lt__', '__module__', '__mro_entries__', '__ne__', '__new__', '__origin__', '__parameters__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__slots__', '__str__', '__subclasscheck__', '__subclasshook__', '__weakref__', '_inst', '_name', '_special', 'copy_with']
>>> List.__name__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/typing.py", line 699, in __getattr__
    raise AttributeError(attr)
AttributeError: __name__
>>> List._name
'List'

----------
components: Interpreter Core
messages: 323663
nosy: Gabriel Tremblay
priority: normal
severity: normal
status: open
title: __name__ not available for classes in typing module
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:26:47 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Aug 2018 17:26:47 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1534526807.29.0.56676864532.issue34200@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I can't reproduce with master on macOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:41:31 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 17 Aug 2018 17:41:31 +0000
Subject: [issue20849] add exist_ok to shutil.copytree
In-Reply-To: <1393908922.06.0.91052425832.issue20849@psf.upfronthosting.co.za>
Message-ID: <1534527691.42.0.56676864532.issue20849@psf.upfronthosting.co.za>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20849>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:45:14 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 17 Aug 2018 17:45:14 +0000
Subject: [issue20849] add exist_ok to shutil.copytree
In-Reply-To: <1393908922.06.0.91052425832.issue20849@psf.upfronthosting.co.za>
Message-ID: <1534527914.49.0.56676864532.issue20849@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

I submitted a new PR in https://github.com/python/cpython/pull/8792 that addresses the outstanding concerns in @ofekmeister's original PR. It includes passing tests and passes all the GitHub PR status checks. Does it look ok to merge? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20849>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:57:33 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Aug 2018 17:57:33 +0000
Subject: [issue34408] possible null pointer dereference in pystate.c
In-Reply-To: <1534277378.73.0.56676864532.issue34408@psf.upfronthosting.co.za>
Message-ID: <1534528653.82.0.56676864532.issue34408@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy: +eric.snow, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34408>
_______________________________________

From report at bugs.python.org  Fri Aug 17 13:58:49 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 17 Aug 2018 17:58:49 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1534528729.52.0.56676864532.issue34365@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +easy
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Fri Aug 17 14:42:10 2018
From: report at bugs.python.org (Koos Zevenhoven)
Date: Fri, 17 Aug 2018 18:42:10 +0000
Subject: [issue33939] Provide a robust O(1) mechanism to check for infinite
 iterators
In-Reply-To: <1529671694.59.0.56676864532.issue33939@psf.upfronthosting.co.za>
Message-ID: <1534531330.59.0.56676864532.issue33939@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

I'd say there are three different problems related to this:

(1) The inability of infinite iterators/iterables to say anything about their length

(2) The inability to interrupt C-level loops

(3) The horrible consequences of things like list(itertools.count()) that fill up the memory


The problems overlap only partially. Unfortunately, fixing any single one of these problems does not eliminate the two others. For example, (2) and (3) may happen just as well without the iterator protocol being involved. And (1) may just prevent you from checking if the iterable has enough elements for whatever you're doing.

----------
nosy: +koos.zevenhoven

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33939>
_______________________________________

From report at bugs.python.org  Fri Aug 17 16:35:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 20:35:40 +0000
Subject: [issue24012] Add error checks to PyInit_pyexpat()
In-Reply-To: <1429471995.2.0.707709004529.issue24012@psf.upfronthosting.co.za>
Message-ID: <1534538140.75.0.56676864532.issue24012@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Some parts of the patch have already been applied into master:

* PySys_GetObject(): https://github.com/python/cpython/commit/7a5457b6878db61910c81017d10579edb7c91512

* PyDict_SetItem(): https://github.com/python/cpython/commit/3f9eee6eb4b25fe1926eaa5f00e02344b126f54d#diff-cc8b737f9996c36521d5b9db5ea1a032

The only remaining part is about PyModule_AddObject(), but there are already many usages of PyModule_AddObject() without doing any error checking, so I suggest closing this as 'outdated'.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24012>
_______________________________________

From report at bugs.python.org  Fri Aug 17 16:40:47 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 17 Aug 2018 20:40:47 +0000
Subject: [issue34413] Porting section of 3.5 "What's New" doc does not mention
 bytecode changes.
In-Reply-To: <1534434373.24.0.56676864532.issue34413@psf.upfronthosting.co.za>
Message-ID: <1534538447.32.0.56676864532.issue34413@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Fair enough.  Having the note in the 3.5 docs should be fine. :)

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34413>
_______________________________________

From report at bugs.python.org  Fri Aug 17 16:42:31 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 20:42:31 +0000
Subject: [issue24011] Add error checks to PyInit_signal()
In-Reply-To: <1429471695.96.0.523863138973.issue24011@psf.upfronthosting.co.za>
Message-ID: <1534538551.43.0.56676864532.issue24011@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

All of the PyModule_AddIntMacro() changes have already been applied in https://github.com/python/cpython/commit/6782b14bcba612e4a39e41992c77306217b91e30.

The remaining parts are:

-    x = PyLong_FromLong((long)NSIG);
-    if (!x || PyDict_SetItemString(d, "NSIG", x) < 0)
+    if (PyModule_AddIntMacro(m, NSIG))
         goto finally;
-    Py_DECREF(x);

---

-     PyExc_IOError, NULL);
-    if (ItimerError != NULL)
-    PyDict_SetItemString(d, "ItimerError", ItimerError);
+                                     PyExc_IOError, NULL);
+    if (PyModule_AddObject(m, "ItimerError", ItimerError))
+        goto finally;

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24011>
_______________________________________

From report at bugs.python.org  Fri Aug 17 16:46:59 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 20:46:59 +0000
Subject: [issue24010] Add error checks to PyInit__locale()
In-Reply-To: <1429471599.85.0.679825670624.issue24010@psf.upfronthosting.co.za>
Message-ID: <1534538819.38.0.56676864532.issue24010@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

A variant of localemodule.patch without error checking for PyModule_AddIntMacro() has been applied in https://github.com/python/cpython/commit/ff4fddde57d5579dff3a83d99e20cd06366b10d6.

Christian, can this be closed or do we still need to add error checking to all PyModule_AddIntMacro() usages?

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24010>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:07:06 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 21:07:06 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534540025.99.0.56676864532.issue34381@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

An additional motivation for the change is that the instructions in the Testing section of the README are make based while the devguide section gives the OS- and version-specific 'python' based commands.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:07:37 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 21:07:37 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534540057.69.0.56676864532.issue34381@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +Documentation
versions: +Python 2.7, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:19:39 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 21:19:39 +0000
Subject: [issue34382] test_os.test_mode fails when directory base directory
 has g+s set
In-Reply-To: <1533990666.21.0.56676864532.issue34382@psf.upfronthosting.co.za>
Message-ID: <1534540779.13.0.56676864532.issue34382@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'Backport' might or might not mean 2.7. You should be able to explicitly select versions in the box above.  I have no idea who should review this.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34382>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:42:19 2018
From: report at bugs.python.org (Matthijs Kooijman)
Date: Fri, 17 Aug 2018 21:42:19 +0000
Subject: [issue34188] Allow dict choices to "transform" values in argpagse
In-Reply-To: <1532264030.24.0.56676864532.issue34188@psf.upfronthosting.co.za>
Message-ID: <1534542139.35.0.56676864532.issue34188@psf.upfronthosting.co.za>


Matthijs Kooijman <matthijskooijman at gmail.com> added the comment:

I was today trying to achieve something similar. I also considered the solution using `type` argument, but that does not seem to play well with the `choices` argument. I was going to report that as a bug, but this issue seems similar enough to comment here instead.

The solution proposed by Paul works, in the sense that if 'I' is passed on the commandline, the parsed value because `int` (the actual type, not a string, not sure if Paul really intended that). However, when running --help with his example, you get:

    usage: foo.py [-h] {<class 'float'>,<class 'int'>}

So:
  - Since the `choices` argument is used to display help text, `choices` should  contain the values that should be specified on the commandline (e.g. the *inputs* to the `type` converter.
 - Since the *type-converted* value is checked against the `choices` argument, `choices` should contain the *outputs* of the `type` converter.

AFAICS these two constraints cannot be fulfilled at the same time, except when no type conversion happens (or, when converted values can be stringified back to their unconverted value, which works in simple cases, I suppose).

IMHO this looks like a bug: `type` and `choices` do not play well together. Checking specified values against `choices` *before* type conversion happens seems more sensible to me and would fix this, as well  fullfil Victor's original usecase (though not with the syntax he suggests).

----------
nosy: +Matthijs Kooijman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34188>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:43:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 21:43:42 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534542222.74.0.56676864532.issue34381@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset cae8ff93a696aa7d74562a9eeaf27afac1f181b4 by Terry Jan Reedy (Michael Osipov) in branch 'master':
bpo-34381: refer to 'Running & Writing Tests' in README.rst (GH-8797)
https://github.com/python/cpython/commit/cae8ff93a696aa7d74562a9eeaf27afac1f181b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:43:53 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 21:43:53 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534542233.05.0.56676864532.issue34381@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8275

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:44:02 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 21:44:02 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534542242.24.0.56676864532.issue34381@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8276

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:51:51 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 21:51:51 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534542711.06.0.56676864532.issue34381@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4d4d23d8317fbc95eec789f349dd1db4c0b24fc3 by Miss Islington (bot) in branch '3.6':
bpo-34381: refer to 'Running & Writing Tests' in README.rst (GH-8797)
https://github.com/python/cpython/commit/4d4d23d8317fbc95eec789f349dd1db4c0b24fc3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:56:49 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Fri, 17 Aug 2018 21:56:49 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
Message-ID: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>


New submission from Micha? Radwa?ski <lisklusownik at gmail.com>:

Code triggering bug:

import time
time.sleep(2**63 / 10**9)

Result:

ValueError: sleep length must be non-negative

The problem is with the macro that checks the range of provided double:

Line 228 of Include/pymath.h:
#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v <= _Py_IntegralTypeMax(type))

The type here is _PyTime_t, which is a typedef to int64_t. 

Proposed solution is to change <= into <, since float(2**63-1) == float(2**63), and that means that none double can ever be equal to 2**63-1.

----------
components: Interpreter Core
messages: 323676
nosy: belopolsky, enedil, lemburg, vstinner
priority: normal
severity: normal
status: open
title: Overflow when casting from double to time_t, and_PyTime_t.
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Fri Aug 17 17:57:47 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 17 Aug 2018 21:57:47 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534543067.32.0.56676864532.issue34381@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset eeece3cd331a1f57fabd55e026f2ea26bc43333c by Miss Islington (bot) in branch '3.7':
bpo-34381: refer to 'Running & Writing Tests' in README.rst (GH-8797)
https://github.com/python/cpython/commit/eeece3cd331a1f57fabd55e026f2ea26bc43333c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:01:37 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:01:37 +0000
Subject: [issue34391] test_ftplib is failing with TLS 1.3
In-Reply-To: <1534153835.38.0.56676864532.issue34391@psf.upfronthosting.co.za>
Message-ID: <1534543297.09.0.56676864532.issue34391@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is there more to do on this?  Tests pass on Windows with 1 skip, but I don't know if the failure condition applies here.
test_check_hostname (test.test_ftplib.TestTLS_FTPClass) ... skipped 'FIXME: bpo-32706'

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34391>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:12:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:12:00 +0000
Subject: [issue34401] [SOLUTION] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534543920.44.0.56676864532.issue34401@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Why did you put '[SOLUTION]' in the title?  We do not use such conventions, and you provide no solution.

Why did you mark this as 'crash'?  What is the actual failure?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:12:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:12:47 +0000
Subject: [issue34402] [SOLUTION] strftime fails on HP-UX
In-Reply-To: <1534250217.83.0.56676864532.issue34402@psf.upfronthosting.co.za>
Message-ID: <1534543967.52.0.56676864532.issue34402@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Same comment as for #34401.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34402>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:13:52 2018
From: report at bugs.python.org (Matthijs Kooijman)
Date: Fri, 17 Aug 2018 22:13:52 +0000
Subject: [issue34188] Allow dict choices to "transform" values in argpagse
In-Reply-To: <1532264030.24.0.56676864532.issue34188@psf.upfronthosting.co.za>
Message-ID: <1534544032.53.0.56676864532.issue34188@psf.upfronthosting.co.za>


Matthijs Kooijman <matthijskooijman at gmail.com> added the comment:

One way to make the original example from Victor work, is to use the following action class:

  class ConvertChoices(argparse.Action):                                                                                                                     
      """                                                                                                                                                    
      Argparse action that interprets the `choices` argument as a dict                                                    
      mapping the user-specified choices values to the resulting option                                                   
      values.                                                                                                                                                
      """                                                                                                                                                    
      def __init__(self, *args, choices, **kwargs):                                                                       
          super().__init__(*args, choices=choices.keys(), **kwargs)                                                       
          self.mapping = choices                                                                                                                             
                                                                                                                                                             
      def __call__(self, parser, namespace, value, option_string=None):                                                   
          setattr(namespace, self.dest, self.mapping[value])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34188>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:16:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:16:57 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1534544217.98.0.56676864532.issue34403@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You might get more information asking questions on python-list.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:21:11 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:21:11 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534544471.78.0.56676864532.issue34381@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Closing this does not preclude the optional addition and merge of a PR for 2.7.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:30:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:30:09 +0000
Subject: [issue34407] datetime.time.isoformat function has inconsistent
 behavior with timezone
In-Reply-To: <1534270684.14.0.56676864532.issue34407@psf.upfronthosting.co.za>
Message-ID: <1534545009.04.0.56676864532.issue34407@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +belopolsky
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34407>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:36:31 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:36:31 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534545391.93.0.56676864532.issue34415@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:44:10 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 17 Aug 2018 22:44:10 +0000
Subject: [issue29386] select.epoll.poll may behave differently if timeout = -1
 vs timeout = None
In-Reply-To: <1485671321.44.0.0475790676768.issue29386@psf.upfronthosting.co.za>
Message-ID: <1534545850.76.0.56676864532.issue29386@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report.

Looking at the Kernel source code, there doesn't seem to be any difference between -1, -100, or -255: https://github.com/torvalds/linux/blob/9bd553929f68921be0f2014dd06561e0c8249a0d/fs/eventpoll.c#L1747-L1761

Do you know any other OS that implements or mimicks epoll() other than Illumos? Since https://github.com/joyent/illumos-joyent/commit/d21b3b2e1bbefbd2f6158ed5d329cd58f86677ab, Illumos follows Linux's behavior, so I'm not sure whether we should do something similar to https://github.com/python/cpython/commit/6cfa927ceb931ad968b5b03e4a2bffb64a8a0604 for epoll.poll().

----------
nosy: +berker.peksag
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29386>
_______________________________________

From report at bugs.python.org  Fri Aug 17 18:47:16 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Aug 2018 22:47:16 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534546036.56.0.56676864532.issue34415@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The default format depends on the style.  From 3.8:

class Formatter()
   <docstring>
    def __init__(self, fmt=None, datefmt=None, style='%'):
        ...
        self._fmt = self._style._fmt

It appears that the class docstring was not updated when the style parameter was added, in 3.2.  So I think more change is needed.  I will try to make a proposal later.

----------
nosy: +terry.reedy, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Fri Aug 17 19:02:02 2018
From: report at bugs.python.org (Jens Troeger)
Date: Fri, 17 Aug 2018 23:02:02 +0000
Subject: [issue34424] Unicode names break email header
Message-ID: <1534546922.5.0.56676864532.issue34424@psf.upfronthosting.co.za>


New submission from Jens Troeger <jens.troeger at gmail.com>:

See also this comment and ensuing conversation: https://bugs.python.org/issue24218?#msg322761

Consider an email message with the following:

message = EmailMessage()
message["From"] = Address(addr_spec="bar at foo.com", display_name="Jens Troeger")
message["To"] = Address(addr_spec="foo at bar.com", display_name="Mart?n C?rdoba")

It?s important here that the email itself is `ascii` encodable, but the names are not. Flattening the object (https://github.com/python/cpython/blob/master/Lib/smtplib.py#L964) incorrectly inserts multiple linefeeds, thus breaking the email header, thus mangling the entire email:

flatmsg: b'From: Jens Troeger <bar at foo.com>\r\nTo: Fernando =?utf-8?q?Mart=C3=ADn_C=C3=B3rdoba?= <foo at bar.com>\r\r\r\r\r\nSubject:\r\n Confirmation: ?\r\n?'

After an initial investigation into the BytesGenerator (used to flatten an EmailMessage object), here is what?s happening.

Flattening the body and attachments of the EmailMessage object works, and eventually _write_headers() is called to flatten the headers which happens entry by entry (https://github.com/python/cpython/blob/master/Lib/email/generator.py#L417-L418). Flattening a header entry is a recursive process over the parse tree of the entry, which builds the flattened and encoded final string by descending into the parse tree and encoding & concatenating the individual ?parts? (tokens of the header entry).

Given the parse tree for a header entry like "Mart?n C?rdoba <foo at bar.com>" eventually results in the correct flattened string:

    '=?utf-8?q?Mart=C3=ADn_C=C3=B3rdoba?= <foo at bar.com>\r\n'

at the bottom of the recursion for this ?Mailbox? part. The recursive callstack is then:

    _refold_parse_tree _header_value_parser.py:2687
    fold [Mailbox] _header_value_parser.py:144
    _refold_parse_tree _header_value_parser.py:2630
    fold [Address] _header_value_parser.py:144
    _refold_parse_tree _header_value_parser.py:2630
    fold [AddressList] _header_value_parser.py:144
    _refold_parse_tree _header_value_parser.py:2630
    fold [Header] _header_value_parser.py:144
    fold [_UniqueAddressHeader] headerregistry.py:258
    _fold [EmailPolicy] policy.py:205
    fold_binary [EmailPolicy] policy.py:199
    _write_headers [BytesGenerator] generator.py:418
    _write [BytesGenerator] generator.py:195

The problem now arises from the interplay of 

    # https://github.com/python/cpython/blob/master/Lib/email/_header_value_parser.py#L2629
    encoded_part = part.fold(policy=policy)[:-1] # strip nl

which strips the '\n' from the returned string, and

    # https://github.com/python/cpython/blob/master/Lib/email/_header_value_parser.py#L2686
    return policy.linesep.join(lines) + policy.linesep

which adds the policy?s line separation string linesep="\r\n" to the end of the flattened string upon unrolling the recursion.

I am not sure about a proper fix here, but considering that the linesep policy can be any string length (in this case len("\r\n") == 2) a fixed truncation of one character [:-1] seems wrong. Instead, using:

    encoded_part = part.fold(policy=policy)[:-len(policy.linesep)] # strip nl

seems to work for entries with and without Unicode characters in their display names.

----------
components: email
messages: 323686
nosy: _savage, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Unicode names break email header
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34424>
_______________________________________

From report at bugs.python.org  Fri Aug 17 19:03:08 2018
From: report at bugs.python.org (Jens Troeger)
Date: Fri, 17 Aug 2018 23:03:08 +0000
Subject: [issue24218] Also support SMTPUTF8 in smtplib's send_message method.
In-Reply-To: <1431879719.97.0.835565097524.issue24218@psf.upfronthosting.co.za>
Message-ID: <1534546988.46.0.56676864532.issue24218@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

New issue: https://bugs.python.org/issue34424

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24218>
_______________________________________

From report at bugs.python.org  Fri Aug 17 19:45:09 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Fri, 17 Aug 2018 23:45:09 +0000
Subject: [issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does
 not validate strings
In-Reply-To: <1513614543.15.0.213398074469.issue32367@psf.upfronthosting.co.za>
Message-ID: <1534549509.19.0.56676864532.issue32367@psf.upfronthosting.co.za>


Change by Micha? Radwa?ski <lisklusownik at gmail.com>:


----------
pull_requests: +8277

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32367>
_______________________________________

From report at bugs.python.org  Fri Aug 17 20:18:56 2018
From: report at bugs.python.org (Jason Spencer)
Date: Sat, 18 Aug 2018 00:18:56 +0000
Subject: [issue34425] :s formatting broken for objects without __format__
Message-ID: <1534551536.12.0.56676864532.issue34425@psf.upfronthosting.co.za>


New submission from Jason Spencer <jasonspencer at google.com>:

Objects with __str__ but WITHOUT __format__ are string-convertible and default-to-str formattable.  But the explicit use of '{:s}' as a format string fails to format these objects as expected.  Either it is no longer the case that '{}' and '{:s}' are equivalent format strings, or formatting for {:s} is broken.  Users would not expect the following to be true.

(Tested in 3.5.3 and 3.6.  Maybe be the same in later releases.)

Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Coord:
...   def __init__(self, a, b):
...     self.a=a
...     self.b=b
...   def __str__(self):
...     return '{:d}:{:d}'.format(self.a, self.b)
... 
>>> c = Coord(3,4)
>>> str(c)
'3:4'
>>> '{:s}'.format(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported format string passed to Coord.__format__
>>> '{}'.format(c)
'3:4'
>>> '{!s:s}'.format(c)
'3:4'
>>>

----------
components: Interpreter Core
messages: 323688
nosy: Jason Spencer
priority: normal
severity: normal
status: open
title: :s formatting broken for objects without __format__
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34425>
_______________________________________

From report at bugs.python.org  Fri Aug 17 20:35:07 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Sat, 18 Aug 2018 00:35:07 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>
Message-ID: <1534552507.05.0.56676864532.issue34423@psf.upfronthosting.co.za>


Change by Micha? Radwa?ski <lisklusownik at gmail.com>:


----------
keywords: +patch
pull_requests: +8278
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Sat Aug 18 00:56:44 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Aug 2018 04:56:44 +0000
Subject: [issue34424] Unicode names break email header
In-Reply-To: <1534546922.5.0.56676864532.issue34424@psf.upfronthosting.co.za>
Message-ID: <1534568204.92.0.56676864532.issue34424@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8279
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34424>
_______________________________________

From report at bugs.python.org  Sat Aug 18 00:59:44 2018
From: report at bugs.python.org (Martin Panter)
Date: Sat, 18 Aug 2018 04:59:44 +0000
Subject: [issue34425] :s formatting broken for objects without __format__
In-Reply-To: <1534551536.12.0.56676864532.issue34425@psf.upfronthosting.co.za>
Message-ID: <1534568384.08.0.56676864532.issue34425@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

It looks like you are describing the result of Issue 7994. Documentation:

https://docs.python.org/release/3.5.3/reference/datamodel.html#object.__format__
https://docs.python.org/release/3.5.3/whatsnew/3.4.html#api-and-feature-removals

----------
nosy: +martin.panter
resolution:  -> not a bug
status: open -> pending
superseder:  -> object.__format__ should reject format strings

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34425>
_______________________________________

From report at bugs.python.org  Sat Aug 18 01:06:24 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 18 Aug 2018 05:06:24 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1534568784.51.0.56676864532.issue14465@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> Serialization of ElementTree in the stdlib is much slower than in lxml (see issue25881). Perhaps it should be implemented in C. But it should be kept simple for this.

Should I say it? That's a first class use case for Cython.


> Pretty-printing can be implemented as an outher preprocessing operation

Agreed. And that would actually be much simpler to implement in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sat Aug 18 01:08:14 2018
From: report at bugs.python.org (Jens Troeger)
Date: Sat, 18 Aug 2018 05:08:14 +0000
Subject: [issue34424] Unicode names break email header
In-Reply-To: <1534546922.5.0.56676864532.issue34424@psf.upfronthosting.co.za>
Message-ID: <1534568894.26.0.56676864532.issue34424@psf.upfronthosting.co.za>


Jens Troeger <jens.troeger at gmail.com> added the comment:

Pull request https://github.com/python/cpython/pull/8803/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34424>
_______________________________________

From report at bugs.python.org  Sat Aug 18 01:35:11 2018
From: report at bugs.python.org (Nojima Takahide)
Date: Sat, 18 Aug 2018 05:35:11 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
Message-ID: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>


New submission from Nojima Takahide <nozzy123nozzy at gmail.com>:

In the Section "LLTRACE" of $(Python3.6-source)/Misc/SpecialBuilds.txt , it describes variable name is "__lltrace__",however it seems to be wrong, "__ltrace__" is correct. Would someone correct this document?

----------
assignee: docs at python
components: Documentation
messages: 323692
nosy: Nojima Takahide, docs at python
priority: normal
severity: normal
status: open
title: "__lltrace__"  seems to be wrong , "__ltrace__" is correct in Misc/SpecialBuilds.txt
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sat Aug 18 01:43:39 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 18 Aug 2018 05:43:39 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534571019.97.0.56676864532.issue34217@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I googled and checked what MSDN uses before I merged these PRs.
For example: https://msdn.microsoft.com/ja-jp/library/bb394814.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Sat Aug 18 04:09:28 2018
From: report at bugs.python.org (Bian Jiaping)
Date: Sat, 18 Aug 2018 08:09:28 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1534579768.19.0.56676864532.issue30717@psf.upfronthosting.co.za>


Change by Bian Jiaping <ssbianjp at gmail.com>:


----------
nosy: +bianjp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30717>
_______________________________________

From report at bugs.python.org  Sat Aug 18 04:09:56 2018
From: report at bugs.python.org (Bian Jiaping)
Date: Sat, 18 Aug 2018 08:09:56 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1534579796.32.0.56676864532.issue12568@psf.upfronthosting.co.za>


Change by Bian Jiaping <ssbianjp at gmail.com>:


----------
nosy: +bianjp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Sat Aug 18 04:13:19 2018
From: report at bugs.python.org (Ben McGinnes)
Date: Sat, 18 Aug 2018 08:13:19 +0000
Subject: [issue1016626] distutils support for swig is under par
Message-ID: <1534579999.21.0.56676864532.issue1016626@psf.upfronthosting.co.za>


Change by Ben McGinnes <ben at adversary.org>:


----------
versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1016626>
_______________________________________

From report at bugs.python.org  Sat Aug 18 04:13:23 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Aug 2018 08:13:23 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534580003.95.0.56676864532.issue34415@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

... the style-dependent default value, "%(message)s", "{message}", or "${message}", is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sat Aug 18 04:53:45 2018
From: report at bugs.python.org (Danish Prakash)
Date: Sat, 18 Aug 2018 08:53:45 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1534582425.75.0.56676864532.issue34365@psf.upfronthosting.co.za>


Danish Prakash <grafitykoncept at gmail.com> added the comment:

> But in 3.x, comparison no longer falls back to comparing object addresses.

What is the default fallback in 3.x?

----------
nosy: +prakashdanish

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Sat Aug 18 05:58:31 2018
From: report at bugs.python.org (Naris R)
Date: Sat, 18 Aug 2018 09:58:31 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
Message-ID: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>


New submission from Naris R <nariscatboy at gmail.com>:

Example:

```
from typing import MutableSequence, TypeVar

CliffordGate = TypeVar('CliffordGate')

class QCircuit(MutableSequence[CliffordGate]):
    def __init__(self, gates):
        self.gates = list(gates)

    def __repr__(self):
        return f'{self.__class__.__name__}({self.gates})'
   
    def __getitem__(self, key):
        return self.gates[key]

    def __setitem__(self, key, item):
        self.gates[key] = item

    def __delitem__(self, key):
        del self.gates[key]

    def insert(self, key, item):
        self.gates.insert(key, item)

a = QCircuit(['H0', 'S2'])
a += a
```

----------
components: Library (Lib)
messages: 323696
nosy: Naris R
priority: normal
severity: normal
status: open
title: calling MutableSequence.extend on self produces infinite loop
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Sat Aug 18 06:07:27 2018
From: report at bugs.python.org (Naris R)
Date: Sat, 18 Aug 2018 10:07:27 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1534586847.32.0.56676864532.issue34427@psf.upfronthosting.co.za>


Naris R <nariscatboy at gmail.com> added the comment:

I forgot to copy over __len__ in the example

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Sat Aug 18 06:08:26 2018
From: report at bugs.python.org (Naris R)
Date: Sat, 18 Aug 2018 10:08:26 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1534586906.93.0.56676864532.issue34427@psf.upfronthosting.co.za>


Change by Naris R <nariscatboy at gmail.com>:


----------
nosy: +rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Sat Aug 18 06:29:27 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 18 Aug 2018 10:29:27 +0000
Subject: [issue34428] tokenize
Message-ID: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

https://github.com/hhatto/autopep8/issues/414

the following two lines of code are not parseable by tokenize.py:

co = re.compile(
            "\(")

the combination of:
* being split on two lines
* having a backslash inside quotes
* having a bracket inside quotes

is an edge-case that _tokenize cannot cope with.

----------
components: Library (Lib)
messages: 323698
nosy: lkcl
priority: normal
severity: normal
status: open
title: tokenize
type: crash
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 06:32:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Aug 2018 10:32:21 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
Message-ID: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Please provide more details. How to reproduce your issue? What you got, and what you expect to get?

Seems the code just before lines modified by your PR are purposed to solve this issue. Why it doesn't work?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sat Aug 18 06:47:06 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 18 Aug 2018 10:47:06 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1534589226.59.0.56676864532.issue34428@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

these two line also pass (do not throw an exception):

co = re.compile(
            r"\(")

the code that fails may be further reduced to the following:

(
"\(")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 06:59:26 2018
From: report at bugs.python.org (Erik Janssens)
Date: Sat, 18 Aug 2018 10:59:26 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534589966.63.0.56676864532.issue34217@psf.upfronthosting.co.za>


Erik Janssens <erik.janssens at conceptive.be> added the comment:

I'll try to be more precise :

- I did an (imperfect) search : before these changes 98% of the windows headers were included in the .c files in lowercase

- These changes would bring it to 100%

- The advantage of these changes are consistency and the ability to cross compile those .c files on linux for a windows target, using the mingw-w64 sdk, where the sdk is on a case sensitive filesystem, as is the default when installing this sdk in most linux distributions.

- I did not consider, nor did I test other toolchains than mingw-w64/mingw-w64-sdk on linux and msvc/windows-sdk on windows.

I'm not enough of an expert on the different tools to come up with a comprehensive solution for this issue, but am willing to validate such solution for the use case of cross compiling on linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:00:17 2018
From: report at bugs.python.org (dwich)
Date: Sat, 18 Aug 2018 11:00:17 +0000
Subject: [issue34429] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
Message-ID: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>


New submission from dwich <michal.konvalinka at gmail.com>:

On Windows tempfile.TemporaryFile() accepts delete attribute. On Linux TemporaryFile() raises TypeError if delete attribute is used.

In tempfile.py source is the code below which means that on Windows TemporaryFile behaves like NamedTemporaryFile. I suppose the code should not be changed but the behaviour should be mentioned in documentation.

if _os.name != 'posix' or _os.sys.platform == 'cygwin':
    # On non-POSIX and Cygwin systems, assume that we cannot unlink a file
    # while it is open.
    TemporaryFile = NamedTemporaryFile

Steps to reproduce:
>>> import tempfile
>>> tf = tempfile.TemporaryFile(delete=False)

On Linux Python throws TypeError:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: TemporaryFile() got an unexpected keyword argument 'delete'

On Windows Python does not throw TypeError because on Windows TemporaryFile is in fact NamedTemporaryFile which accepts delete attribute.

Tested on all these versions: 3.7.0 64 bit, 3.6.5 32 bit, 3.5.4 32 bit, 3.4.4 32 bit, 2.7.15 32 bit 


Proposed text to tempfile.TemporaryFile documentation:

On non POSIX or Cygwin platforms TemporaryFile behaves exacly like NamedTemporaryFile including the fact that TemporaryFile accepts delete attribute and does not raise
TypeError: TemporaryFile() got an unexpected keyword argument 'delete'.

----------
assignee: docs at python
components: Documentation
messages: 323702
nosy: docs at python, dwich
priority: normal
severity: normal
status: open
title: On Windows tempfile.TemporaryFile behaves like NamedTemporaryFile
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:02:20 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 11:02:20 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
Message-ID: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>


New submission from Alfred Sawaya <alfred at huji.fr>:

asyncio.future.wrap_future is used to wrap a concurrent.future.Future in a asyncio.future.Future. 

The actual implementation as the following behaviours : 

 1) When the concurrent.future.Future gets a result, the asyncio.future.Future gets the same result,
 2) When the asyncio.future.Future is cancelled, the concurrent.future.Future is cancelled

I wonder why the futures synchronisation is not symmetrical ?
I propose to add the following behaviours : 

 3) When the asyncio.future.Future gets a result, the concurrent.future.Future gets the same result,
 4) When the concurrent.future.Future is cancelled, the asyncio.future.Future is cancelled

I have also posted a request pull that implements the proposed behaviours, in case of acceptation.

If there is good reasons to not implement the proposed behaviours, I would be glad to know.

Thank you !

----------
components: asyncio
messages: 323703
nosy: asvetlov, huji, yselivanov
priority: normal
pull_requests: 8280
severity: normal
status: open
title: Double chaining futures in asyncio.future.wrap_future
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:06:33 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 18 Aug 2018 11:06:33 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1534590393.03.0.56676864532.issue34428@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

python2.7 and 3.5 also has exact same issue.

----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:16:03 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 11:16:03 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534590963.93.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
pull_requests:  -8280

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:18:13 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 11:18:13 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534591093.43.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
keywords: +patch
pull_requests: +8281
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:21:53 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Aug 2018 11:21:53 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1534591313.88.0.56676864532.issue34428@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I can't reproduce.

>>> import tokenize
>>> list(tokenize.generate_tokens(iter(['(\n', r'"\(")']).__next__))
[TokenInfo(type=53 (OP), string='(', start=(1, 0), end=(1, 1), line='(\n'), TokenInfo(type=56 (NL), string='\n', start=(1, 1), end=(1, 2), line='(\n'), TokenInfo(type=3 (STRING), string='"\\("', start=(2, 0), end=(2, 4), line='"\\(")'), TokenInfo(type=53 (OP), string=')', start=(2, 4), end=(2, 5), line='"\\(")'), TokenInfo(type=4 (NEWLINE), string='', start=(2, 5), end=(2, 6), line=''), TokenInfo(type=0 (ENDMARKER), string='', start=(3, 0), end=(3, 0), line='')]

Could you please provide a minimal script that reproduces your issue?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:25:18 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 11:25:18 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534591518.39.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
pull_requests:  -8281

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:26:58 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 11:26:58 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534591618.06.0.56676864532.issue34430@psf.upfronthosting.co.za>


Alfred Sawaya <alfred at huji.fr> added the comment:

Actually the PR does not pass some tests, I will work on this. If the new behaviours are accepted, I will implement them soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:37:04 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 18 Aug 2018 11:37:04 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1534592224.77.0.56676864532.issue34428@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

regular expressions are not something i am familiar or comfortable
with (never have been: the patterns are too dense).  however REMOVING
"Bracket" from the regular expression(s) for PseudoToken "fixes"
the problem.

some debug print statements dropped in at around line 640 of
tokenize.py show that the match on the "working" code
with r"\(") as input gives a start/end/spos/epos that is DIFFERENT
from when the same code is given just "\("

line 'r"\\(")\n'
pos 0 7 r <_sre.SRE_Match object; span=(0, 5), match='r"\\("'>
pseudo start/end 0 5 (2, 0) (2, 5)

vs

line '"\\(")\n'
pos 0 6 " <_sre.SRE_Match object; span=(0, 4), match='"\\("'>
pseudo start/end 0 4 (5, 0) (5, 4)

there *may* be a way to "fix" this by taking out the pattern
matching on Bracket and prioritising everything else.


        while pos < max:
            pseudomatch = _compile(PseudoToken).match(line, pos)
            print ("pos", pos, max, line[pos], pseudomatch)
            if pseudomatch:                                # scan for tokens
                start, end = pseudomatch.span(1)
                spos, epos, pos = (lnum, start), (lnum, end), end
                print ("pseudo start/end", start, end, spos, epos)
                if start == end:
                    continue

 
Bracket = '[][(){}]'
Special = group(r'\r?\n', r'\.\.\.', r'[:;.,@]')
# REMOVE Bracket
Funny = group(Operator, Special)

PlainToken = group(Number, Funny, String, Name)
Token = Ignore + PlainToken

# First (or only) line of ' or " string.
ContStr = group(StringPrefix + r"'[^\n'\\]*(?:\\.[^\n'\\]*)*" +
                group("'", r'\\\r?\n'),
                StringPrefix + r'"[^\n"\\]*(?:\\.[^\n"\\]*)*' +
                group('"', r'\\\r?\n'))
PseudoExtras = group(r'\\\r?\n|\Z', Comment, Triple)
PseudoToken = Whitespace + group(PseudoExtras, Number, Funny, ContStr, Name)

----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:43:21 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 18 Aug 2018 11:43:21 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1534592601.14.0.56676864532.issue34428@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

wtf??? neither can i!!!!

import io
import tokenize

text = r'''\
(
r"\(")

(
"\(")
'''

string_io = io.StringIO(text)
tokens = list(
    tokenize.generate_tokens(string_io.readline)
)

print (tokens)

works perfectly.

ok ahhhh i bet you it's something to do with how
string_io.readline works, or something to do with
the format of the text.  give me a sec to triage it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 07:52:18 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 18 Aug 2018 11:52:18 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1534593138.47.0.56676864532.issue34428@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

ahh darn-it, autopep8 is passing in tokens line-by-line,
to be parsed one at a time.... oh and of course it's losing
state information that tokenizer critically relies on.

i *think* that's what's going on.... so it's highly unlikely
to be a python tokenize bug... can we wait to see what the
autopep8 developer says?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 18 08:42:04 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 18 Aug 2018 12:42:04 +0000
Subject: [issue31370] Remove support for threads-less builds
In-Reply-To: <1504732249.83.0.180664230366.issue31370@psf.upfronthosting.co.za>
Message-ID: <1534596124.35.0.56676864532.issue31370@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8282

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31370>
_______________________________________

From report at bugs.python.org  Sat Aug 18 09:15:30 2018
From: report at bugs.python.org (Kevin Norris)
Date: Sat, 18 Aug 2018 13:15:30 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1534598130.19.0.56676864532.issue34365@psf.upfronthosting.co.za>


Kevin Norris <nykevin.norris at gmail.com> added the comment:

There is none.  It raises a TypeError.  See https://docs.python.org/3/reference/expressions.html#value-comparisons

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Sat Aug 18 09:15:48 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Aug 2018 13:15:48 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1534598148.04.0.56676864532.issue34427@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It would be reasonable to add special handling for this case to match what is done in the concrete sequences like list, deque, bytes, ...

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Sat Aug 18 09:48:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Aug 2018 13:48:05 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1534600085.44.0.56676864532.issue34427@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

deque and bytearray make an in-memory copy of self if extended with self. deque creates a temporary list, bytearray creates a temporary bytearray. list just iterates itself as a linear array of known size and avoids infinite loop. It could be possible to avoid creaing a temporary copy in case of deque and bytearray too, but I don't think this special case is worth an additional code.

But a MutableSequence can represents a sequence that doesn't fit in memory. It can provide an interface to a linear on-disk store. In this case creating an on-memory copy is not possible.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Sat Aug 18 10:01:48 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 18 Aug 2018 14:01:48 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534600908.72.0.56676864532.issue34217@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

As someone who has written MSDN samples, I'll spoil the secret and let you know that there's no consistency there, so you can find examples to prove either direction ;)

I wasn't expecting expertise or research. I was only expecting a description of the change that clearly specifies who benefits and who loses, and leaves a chance for the affected experts to confirm impact before being merged. There can be a surprising amount of subtlety around cross-platform issues, which is why we have designated people who are responsible for tracking them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Sat Aug 18 10:36:05 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 14:36:05 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534602965.02.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
pull_requests: +8283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 10:44:15 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 14:44:15 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534603455.05.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
pull_requests: +8284

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 10:55:28 2018
From: report at bugs.python.org (Julien Malard)
Date: Sat, 18 Aug 2018 14:55:28 +0000
Subject: [issue34421] Cannot install package with unicode module names on
 Windows
In-Reply-To: <1534588341.31.0.56676864532.issue34421@psf.upfronthosting.co.za>
Message-ID: <YTOPR01MB0283699033A8845FD8A2C84AD93C0@YTOPR01MB0283.CANPRD01.PROD.OUTLOOK.COM>


Julien Malard <julien.malard at mail.mcgill.ca> added the comment:

Hello,

Yes, it does seem odd that that code does not work. On my Windows machine (WIndows 7, 64 bits, running 32-bit Python) I checked and it seems that the code in the if block immediately preceding my PR does not run at all, whereby the error.

For a reproducible example, my Taqdir package, mostly consisting of unicode packages and modules, runs into this issue (and installs successfully after my proposed fix here combined with a separate PR in pip). Perhaps the most easily accessible example would be the Appveyor build (https://ci.appveyor.com/project/julienmalard/Tinamit) for my TInamit project, which has Taqdir as a dependency.

Thanks!

-Julien Malard

________________________________
??????: Serhiy Storchaka <report at bugs.python.org>
????????: 18 ????? 2018 06:32
?????: Julien Malard
????: [issue34421] Cannot install package with unicode module names on Windows

New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Please provide more details. How to reproduce your issue? What you got, and what you expect to get?

Seems the code just before lines modified by your PR are purposed to solve this issue. Why it doesn't work?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34421>
_______________________________________

From report at bugs.python.org  Sat Aug 18 11:28:25 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 15:28:25 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534606105.51.0.56676864532.issue34430@psf.upfronthosting.co.za>


Alfred Sawaya <alfred at huji.fr> added the comment:

The proposed solution (PR) has passed all tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 11:28:42 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 15:28:42 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534606122.3.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 11:28:56 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 15:28:56 +0000
Subject: [issue34430] Double chaining futures in asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534606136.39.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
pull_requests:  -8283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 11:36:17 2018
From: report at bugs.python.org (Alfred Sawaya)
Date: Sat, 18 Aug 2018 15:36:17 +0000
Subject: [issue34430] Symmetrical chaining futures in
 asyncio.future.wrap_future
In-Reply-To: <1534590140.17.0.56676864532.issue34430@psf.upfronthosting.co.za>
Message-ID: <1534606577.69.0.56676864532.issue34430@psf.upfronthosting.co.za>


Change by Alfred Sawaya <alfred at huji.fr>:


----------
title: Double chaining futures in asyncio.future.wrap_future -> Symmetrical chaining futures in asyncio.future.wrap_future

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34430>
_______________________________________

From report at bugs.python.org  Sat Aug 18 12:03:19 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Sat, 18 Aug 2018 16:03:19 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
Message-ID: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

See https://docs.python.org/3.6/library/functions.html#eval
This says the following won't happen. But it does.

Python 3.6.2 (default, Jul 29 2017, 00:00:00) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def fn(): print(3); return 4
... 
>>> eval(fn.__code__)
3
4

Compare with https://docs.python.org/3.6/library/functions.html#exec

Search for eval in title of open issues bring up related

#22057 (The doc say all globals are copied on eval(), but only __builtins__ is copied)
#25810 (Python 3 documentation for eval is incorrect)

----------
assignee: docs at python
components: Documentation
messages: 323716
nosy: docs at python, jfine2358
priority: normal
severity: normal
status: open
title: Docs does not eval allows code object as argument
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34431>
_______________________________________

From report at bugs.python.org  Sat Aug 18 12:49:19 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 18 Aug 2018 16:49:19 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
In-Reply-To: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>
Message-ID: <1534610959.82.0.56676864532.issue34431@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for your report.

Quoting from https://docs.python.org/3.6/library/functions.html#eval

    This function can also be used to execute arbitrary code objects
    (such as those created by compile()). In this case pass a code
    object instead of a string.

So, your example is already documented as a legal way of using the eval() function.

I don't see anything wrong here.

----------
nosy: +berker.peksag
resolution:  -> not a bug
status: open -> pending
type:  -> behavior
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34431>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:05:23 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 18 Aug 2018 17:05:23 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
Message-ID: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

On str.format method, the note about how locales are dealt with reads:

"When formatting a number (int, float, float and subclasses)..."

PR removes the second float, and mentions complex and decimal.Decimal.

The bug which introduced this note is: #31900

----------
assignee: docs at python
components: Documentation
messages: 323718
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc Mention complex and decimal.Decimal on str.format note about locales
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:06:40 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 18 Aug 2018 17:06:40 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534612000.74.0.56676864532.issue34432@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
keywords: +patch
pull_requests: +8285
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:12:08 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 18 Aug 2018 17:12:08 +0000
Subject: [issue34425] :s formatting broken for objects without __format__
In-Reply-To: <1534551536.12.0.56676864532.issue34425@psf.upfronthosting.co.za>
Message-ID: <1534612328.33.0.56676864532.issue34425@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree this is the desired behavior, and not a bug.

Because you are not specifying a __format__ in your class, object.__format__ is being called. By design, it does not understand any formatting specifiers, instead reserving them for your class to implement. "!s" is the correct way to convert your type to a string. Either that, or add a __format__ that understands "s".

Note that not all types understand "s", for example, datetime.

----------
assignee:  -> eric.smith
nosy: +eric.smith
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34425>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:15:27 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Sat, 18 Aug 2018 17:15:27 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
In-Reply-To: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>
Message-ID: <1534612527.64.0.56676864532.issue34431@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

Summary: There's my problem, and others. I'm willing to provide a patch, if supported.

There's a gotcha here. I fell into it. The docs for eval state
===
eval(expression, globals=None, locals=None)
The arguments are a string and optional globals and locals.
===
I read this and concluded, fairly I think, that I'm not allowed to pass in a code object [1]. So I didn't read any further. I'd already got the answer to my question.

But I knew that exec would take a code object, so I had doubt, and did my little experiment.

I'd prefer something more like exec, which says
===
This function supports dynamic execution of Python code. object must be either a string or a code object.
===

There are other problems, such as not agreeing with the help(eval) etc messages (and the still open #22057, #25810):
===
eval(source, globals=None, locals=None, /)
    Evaluate the given source in the context of globals and locals.
    
    The source may be a string representing a Python expression
    or a code object as returned by compile().
    The globals must be a dictionary and locals can be any mapping,
    defaulting to the current globals and locals.
    If only globals is given, locals defaults to it.
===
exec(source, globals=None, locals=None, /)
    Execute the given source in the context of globals and locals.
    
    The source may be a string representing one or more Python statements
    or a code object as returned by compile().
    The globals must be a dictionary and locals can be any mapping,
    defaulting to the current globals and locals.
    If only globals is given, locals defaults to it.
===

Finally, I'm willing to provide a patch, if supported. (I've not contributed to Python before.)

[1] I'd just read the docs for exec, which is up-front about 'string or code'.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34431>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:36:27 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 18 Aug 2018 17:36:27 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534613787.29.0.56676864532.issue34432@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 93b5655c040a33f9ba4cdbd303afc8398c8413c7 by Eric V. Smith (Andr?s Delfino) in branch 'master':
bpo-34432: doc Mention complex and decimal.Decimal on str.format not about locales (GH-8808)
https://github.com/python/cpython/commit/93b5655c040a33f9ba4cdbd303afc8398c8413c7


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:36:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Aug 2018 17:36:40 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534613800.78.0.56676864532.issue34432@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8286

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:36:57 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 18 Aug 2018 17:36:57 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534613817.08.0.56676864532.issue34432@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8287

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:41:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 18 Aug 2018 17:41:11 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
In-Reply-To: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>
Message-ID: <1534614071.43.0.56676864532.issue34431@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Ok, I think it would be a good idea to mention that the function accepts a code object in the first sentence. I'd be happy to review such PR. The eval() documentation is located at https://github.com/python/cpython/blob/master/Doc/library/functions.rst

See https://devguide.python.org/ for more details about the contribution process.

Note that you need to sign the CLA in order to contribute to Python: https://www.python.org/psf/contrib/contrib-form/

#22057 and #25810 are out of scope for this issue, so let's not discuss them here.

----------
resolution: not a bug -> 
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34431>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:43:41 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 18 Aug 2018 17:43:41 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534614221.72.0.56676864532.issue34432@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 13:52:27 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Sat, 18 Aug 2018 17:52:27 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
In-Reply-To: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>
Message-ID: <1534614747.47.0.56676864532.issue34431@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

OK. I'll do as you say. I've just signed the CLA.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34431>
_______________________________________

From report at bugs.python.org  Sat Aug 18 14:16:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 18 Aug 2018 18:16:05 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534616165.95.0.56676864532.issue34432@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset fbd0a14cc941e340df0979d94ac55191dd31ad00 by Eric V. Smith (Miss Islington (bot)) in branch '3.6':
bpo-34432: doc Mention complex and decimal.Decimal on str.format not about locales (GH-8808) (GH-8810)
https://github.com/python/cpython/commit/fbd0a14cc941e340df0979d94ac55191dd31ad00


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 14:16:39 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 18 Aug 2018 18:16:39 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534616199.12.0.56676864532.issue34432@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 0fd6f832a9c30404bf595a4af36e171d11fab024 by Eric V. Smith (Miss Islington (bot)) in branch '3.7':
bpo-34432: doc Mention complex and decimal.Decimal on str.format note about locales (GH-8808) (GH-8809)
https://github.com/python/cpython/commit/0fd6f832a9c30404bf595a4af36e171d11fab024


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 14:51:46 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 18 Aug 2018 18:51:46 +0000
Subject: [issue34382] test_os.test_mode fails when directory base directory
 has g+s set
In-Reply-To: <1534540779.13.0.56676864532.issue34382@psf.upfronthosting.co.za>
Message-ID: <AF96EB28-E3A2-43DC-B6B5-9FFFE10B0A05@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Likewise, I have no idea who should review, or whether python2 should be included or not. 

The issue is not a bug in python, rather a shortcoming in the test suite. 

In short, since I do my builds in an environment where the mode includes SGID  on the directory i see this ?false? fail. 

Sent from my iPhone

> On 17 Aug 2018, at 23:19, Terry J. Reedy <report at bugs.python.org> wrote:
> 
> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> 'Backport' might or might not mean 2.7. You should be able to explicitly select versions in the box above.  I have no idea who should review this.
> 
> ----------
> nosy: +terry.reedy
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34382>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34382>
_______________________________________

From report at bugs.python.org  Sat Aug 18 14:51:53 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 18 Aug 2018 18:51:53 +0000
Subject: [issue34401] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534618313.76.0.56676864532.issue34401@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

My bad, I initially had attached a patch as you can see, but will turn that into a PR on GitHub on Monday. That's why I had that label, but removed the patch.

It doesn't crash, it is rather a behavior/regex issue in the test.

Thanks for pointing out. Will get to you with a solution on Monday.

----------
title: [SOLUTION] Make test_gdb work on HP-UX -> Make test_gdb work on HP-UX
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Sat Aug 18 14:55:23 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 18 Aug 2018 18:55:23 +0000
Subject: [issue34402] strftime fails on HP-UX
In-Reply-To: <1534250217.83.0.56676864532.issue34402@psf.upfronthosting.co.za>
Message-ID: <1534618523.57.0.56676864532.issue34402@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Thanks changed appropriately. I here also have a PR idea I will try on Monday. It won't be idiotproof, but someone will likely comment on it and provide more input.

I am willing to provide even more patches, but am currently stuck with https://github.com/python/cpython/pull/8786 and juggle with "git stash" to make Python actually compile on HP-UX. This is cumbersome.

----------
title: [SOLUTION] strftime fails on HP-UX -> strftime fails on HP-UX
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34402>
_______________________________________

From report at bugs.python.org  Sat Aug 18 14:58:14 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 18 Aug 2018 18:58:14 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1534618694.43.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Thanks, I'll do that. Hopefully I can provide a patch for. Though, I am convinced that I have to write a custom codec for roman8 to make all at stuff work flawlessly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Sat Aug 18 15:09:52 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 18 Aug 2018 19:09:52 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534619392.11.0.56676864532.issue34415@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
pull_requests: +8288
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sat Aug 18 15:09:54 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 18 Aug 2018 19:09:54 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534619394.26.0.56676864532.issue34415@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch, patch
pull_requests: +8288, 8289
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sat Aug 18 16:09:47 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 18 Aug 2018 20:09:47 +0000
Subject: [issue34432] doc Mention complex and decimal.Decimal on str.format
 note about locales
In-Reply-To: <1534611923.59.0.56676864532.issue34432@psf.upfronthosting.co.za>
Message-ID: <1534622987.47.0.56676864532.issue34432@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, Andr?s!

----------
assignee: docs at python -> eric.smith
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34432>
_______________________________________

From report at bugs.python.org  Sat Aug 18 16:46:02 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Aug 2018 20:46:02 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1534625162.59.0.56676864532.issue12568@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I suggest reclosing this issue, for the same reason I suggested closure of #24665 in msg321291: abstract unicode 'characters' (graphemes) do not, in general, have fixed physical widths of 0, 1, or 2 n-pixel columns (or spaces).  I based that fairly long message on IDLE's multiscript font sample as displayed on Windows 10.  In that context, for instance, the width of (fixed-pitch) East Asian characters is about 1.6, not 2.0, times the width of fixed-pitch Ascii characters.  Variable-width Tamil characters average about the same.  The exact ratio depends on the Latin font used.

I did more experiments with Python started from Command Prompt with code page 437 or 65001 and characters 20 pixels high.  The Windows console only allows 'fixed pitch' fonts.  East Asian characters, if displayed, are expanded to double width.

However, European characters are not reliably displayed in one column. The width depends on the both the font selected when a character is entered and the current font. The 20 latin1 characters in '????????????????????' usually display in 20 columns.  But if they are entered with the font set to MSGothic, the '?' and '?' are each displayed in the middle of 2 columns, for 22 total.  If the font is changed to MSGothic after entry, the '?' and '?' are shifted 1/2 column right to overlap the following '?' or '?' without changing the total width.  Greek and Cyrillic characters also sometimes take two columns.

I did not test whether the font size (pixel height) affects horizontal column spacing.

----------
stage:  -> test needed
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Sat Aug 18 16:55:45 2018
From: report at bugs.python.org (paul j3)
Date: Sat, 18 Aug 2018 20:55:45 +0000
Subject: [issue34188] Allow dict choices to "transform" values in argpagse
In-Reply-To: <1532264030.24.0.56676864532.issue34188@psf.upfronthosting.co.za>
Message-ID: <1534625745.17.0.56676864532.issue34188@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

The 'choices' mechanism is quite simple.  As noted for testing it simply uses an 'in' test.  

For help formating it uses

     choice_strs = [str(choice) for choice in action.choices]
     result = '{%s}' % ','.join(choice_strs)

In other words, it's treated as a iterable. 

But it is easy to produce unmanageable displays, such as with 'range(100)'.  This has been raised in other bug/issues.  The best way around that is with the 'metavar', which lets you customize the 'usage' and 'help'.  One thing that 'metavar' does not help with is the error display.

I'm not privy to the original author's thinking, but I don't think 'choices' was ever meant to be a high power tool.  

With a custom Action you can do almost anything that you could do after parsing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34188>
_______________________________________

From report at bugs.python.org  Sat Aug 18 16:59:18 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Aug 2018 20:59:18 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1534625958.34.0.56676864532.issue24665@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My msg323731 for #12568 refers to my msg321291 above.  I did some new experiments with column spacing for European characters in Windows console (as opposed to tk Text) and discovered that some, including some Latin1 characters used in English text, may also become double-width in certain fonts.  The problem of calculating physical line lengths is even harder than I thought before, and does not require non-English text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24665>
_______________________________________

From report at bugs.python.org  Sat Aug 18 17:23:35 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Aug 2018 21:23:35 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
 is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1534627415.5.0.56676864532.issue2382@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE avoids the problem of calculating a location for a '^' below the bad line by instead asking tk to give the marked character (and maybe more) a 'ERROR' tag, which shows as a red background.  So it marks the '$' of 'A_I_U_E_O$' and the 'alid' slice of 'inv\u200balid' (from duplicate #10384).  When the marked character is '\n', the space following the line is tagged.  Is it possible to do something similar with any of the major system consoles?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Sat Aug 18 17:30:39 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Aug 2018 21:30:39 +0000
Subject: [issue10384] SyntaxError should contain exact location of the invalid
 character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1534627839.8.0.56676864532.issue10384@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When testing how IDLE handles the examples (which it does well, see #2382 msg323734), I discovered that while the single invisible char for msg120936 *is* present in the posted text, the multiple invisible chars for msg228023 are not.  The following has them before and after the 'a':
  inv?a?lid

----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10384>
_______________________________________

From report at bugs.python.org  Sat Aug 18 17:33:43 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Aug 2018 21:33:43 +0000
Subject: [issue34381] Make tests with outbound connection optional
In-Reply-To: <1533980593.8.0.56676864532.issue34381@psf.upfronthosting.co.za>
Message-ID: <1534628023.45.0.56676864532.issue34381@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34381>
_______________________________________

From report at bugs.python.org  Sat Aug 18 18:18:08 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 18 Aug 2018 22:18:08 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534630688.37.0.56676864532.issue22057@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +8290

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sat Aug 18 18:19:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 18 Aug 2018 22:19:40 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534630780.73.0.56676864532.issue22057@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I like Martin's suggestion in msg282262 and I've just created PR 8812 to implement it.

----------
nosy: +berker.peksag
type:  -> behavior
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sat Aug 18 18:25:04 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 18 Aug 2018 22:25:04 +0000
Subject: [issue1648923] HP-UX: -lcurses missing for readline.so
Message-ID: <1534631104.67.0.56676864532.issue1648923@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

I cannot reproduce this with master and 3.7 on HP-UX.

readline is linked and works with interactive python(1). curses module isn't buld because I don't have curses installed.

I opt to close this one.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1648923>
_______________________________________

From report at bugs.python.org  Sat Aug 18 18:28:07 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 18 Aug 2018 22:28:07 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
 used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1534631287.91.0.56676864532.issue5999@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

I cannot reproduce this with HP-UX 11.31 and master + 3.7.

I opt to close this one.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Sat Aug 18 19:52:35 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Aug 2018 23:52:35 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
 used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1534636355.17.0.56676864532.issue5999@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Sat Aug 18 20:07:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 00:07:47 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1534637267.76.0.56676864532.issue26363@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the report, Xavier.

This is a duplicate of issue 22057.

PR 8812 clarifies the behavior when a dictionary without a "__builtins__" key is passed as *globals* to eval(). I think that makes the opposite case much easier to understand.

>>> eval("print(spam)", {'__builtins__': {'spam': 'eggs'}})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'print' is not defined

>>> eval("print(spam)", {'__builtins__': {'spam': 'eggs', 'print': print}})
eggs

Also, I never needed to pass a dictionary with a "__builtins__" key to eval() before, so I don't think it's an important detail to document.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> The doc say all globals are copied on eval(), but only __builtins__ is copied
type:  -> behavior
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26363>
_______________________________________

From report at bugs.python.org  Sat Aug 18 20:34:16 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 00:34:16 +0000
Subject: [issue1648923] HP-UX: -lcurses missing for readline.so
Message-ID: <1534638856.56.0.56676864532.issue1648923@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1648923>
_______________________________________

From report at bugs.python.org  Sat Aug 18 22:04:01 2018
From: report at bugs.python.org (Naris R)
Date: Sun, 19 Aug 2018 02:04:01 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1534644241.48.0.56676864532.issue34427@psf.upfronthosting.co.za>


Change by Naris R <nariscatboy at gmail.com>:


----------
keywords: +patch
pull_requests: +8291
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Sat Aug 18 22:38:36 2018
From: report at bugs.python.org (Danish Prakash)
Date: Sun, 19 Aug 2018 02:38:36 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1534646316.24.0.56676864532.issue34365@psf.upfronthosting.co.za>


Change by Danish Prakash <grafitykoncept at gmail.com>:


----------
keywords: +patch
pull_requests: +8292
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Sat Aug 18 22:46:39 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Aug 2018 02:46:39 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1534646799.38.0.56676864532.issue34062@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8293
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Sat Aug 18 22:52:43 2018
From: report at bugs.python.org (Danish Prakash)
Date: Sun, 19 Aug 2018 02:52:43 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1534647163.77.0.56676864532.issue34426@psf.upfronthosting.co.za>


Danish Prakash <grafitykoncept at gmail.com> added the comment:

> however it seems to be wrong, "__ltrace__" is correct

just curious how did you figure it out?

----------
nosy: +prakashdanish

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sun Aug 19 00:14:24 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Aug 2018 04:14:24 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534652064.59.0.56676864532.issue34415@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset d3d3171da895d8cb880f23fae6be778f0ac23be7 by Vinay Sajip in branch 'master':
bpo-34415: Updated logging.Formatter docstring. (GH-8811)
https://github.com/python/cpython/commit/d3d3171da895d8cb880f23fae6be778f0ac23be7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sun Aug 19 00:15:27 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 04:15:27 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534652127.92.0.56676864532.issue34415@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8294

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sun Aug 19 00:15:34 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 04:15:34 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534652134.57.0.56676864532.issue34415@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8295

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sun Aug 19 00:43:41 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 04:43:41 +0000
Subject: [issue22602] UTF-7 codec decodes ill-formed sequences starting with
 "+"
In-Reply-To: <1412945083.94.0.341902119278.issue22602@psf.upfronthosting.co.za>
Message-ID: <1534653821.56.0.56676864532.issue22602@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e349bf23584eef20e0d1e1b2989d9b1430f15507 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-22602: Raise an exception in the UTF-7 decoder for ill-formed sequences starting with "+". (GH-8741)
https://github.com/python/cpython/commit/e349bf23584eef20e0d1e1b2989d9b1430f15507


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22602>
_______________________________________

From report at bugs.python.org  Sun Aug 19 00:44:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 04:44:28 +0000
Subject: [issue22602] UTF-7 codec decodes ill-formed sequences starting with
 "+"
In-Reply-To: <1412945083.94.0.341902119278.issue22602@psf.upfronthosting.co.za>
Message-ID: <1534653868.31.0.56676864532.issue22602@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your PR Zackery.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22602>
_______________________________________

From report at bugs.python.org  Sun Aug 19 02:55:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 06:55:15 +0000
Subject: [issue34392] Add sys.isinterned()
In-Reply-To: <1534155873.32.0.56676864532.issue34392@psf.upfronthosting.co.za>
Message-ID: <1534661715.29.0.56676864532.issue34392@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you all for the feedback. The function is renamed to sys._is_interned() and documented as optional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34392>
_______________________________________

From report at bugs.python.org  Sun Aug 19 03:00:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 07:00:15 +0000
Subject: [issue34318] Convert deprecated behavior of assertRaises() etc into
 errors
In-Reply-To: <1533209994.63.0.56676864532.issue34318@psf.upfronthosting.co.za>
Message-ID: <1534662015.45.0.56676864532.issue34318@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 77d5781835b6e0a132694ebadc22b1cbdb9913f8 by Serhiy Storchaka in branch 'master':
bpo-34318: Convert deprecation warnings to errors in assertRaises() etc. (GH-8623)
https://github.com/python/cpython/commit/77d5781835b6e0a132694ebadc22b1cbdb9913f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34318>
_______________________________________

From report at bugs.python.org  Sun Aug 19 03:19:35 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Aug 2018 07:19:35 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534663175.35.0.56676864532.issue34415@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset fed871835ee54f50cabcec6239271739ed4839f5 by Vinay Sajip (Miss Islington (bot)) in branch '3.6':
bpo-34415: Updated logging.Formatter docstring. (GH-8811) (GH-8816)
https://github.com/python/cpython/commit/fed871835ee54f50cabcec6239271739ed4839f5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sun Aug 19 03:20:16 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Aug 2018 07:20:16 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534663216.36.0.56676864532.issue34415@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 2e4ae8f1b3147d7f0a461b4ffdde9bcc9e6a2083 by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-34415: Updated logging.Formatter docstring. (GH-8811) (GH-8817)
https://github.com/python/cpython/commit/2e4ae8f1b3147d7f0a461b4ffdde9bcc9e6a2083


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sun Aug 19 03:27:41 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 19 Aug 2018 07:27:41 +0000
Subject: [issue34415] Typo in logging.Formatter docstring
In-Reply-To: <1534449146.03.0.56676864532.issue34415@psf.upfronthosting.co.za>
Message-ID: <1534663661.14.0.56676864532.issue34415@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34415>
_______________________________________

From report at bugs.python.org  Sun Aug 19 03:49:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 07:49:21 +0000
Subject: [issue34318] Convert deprecated behavior of assertRaises() etc into
 errors
In-Reply-To: <1533209994.63.0.56676864532.issue34318@psf.upfronthosting.co.za>
Message-ID: <1534664961.72.0.56676864532.issue34318@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34318>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:25:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 10:25:40 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534674340.49.0.56676864532.issue22057@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 225b05548027d55aafb11b65f6a4a2bef2f5196f by Berker Peksag in branch 'master':
bpo-22057: Clarify eval() documentation (GH-8812)
https://github.com/python/cpython/commit/225b05548027d55aafb11b65f6a4a2bef2f5196f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:25:45 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 10:25:45 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534674345.96.0.56676864532.issue22057@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:25:54 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 10:25:54 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534674354.18.0.56676864532.issue22057@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8297

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:29:53 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 10:29:53 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534674593.11.0.56676864532.issue22057@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0e1e8dbb0b99ec78f4567382428fdd46e2244d40 by Miss Islington (bot) in branch '3.7':
bpo-22057: Clarify eval() documentation (GH-8812)
https://github.com/python/cpython/commit/0e1e8dbb0b99ec78f4567382428fdd46e2244d40


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:30:44 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 10:30:44 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1534674644.23.0.56676864532.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Fixed issues on Windows.

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:32:15 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 10:32:15 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534674735.59.0.56676864532.issue22057@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f19579b8f1fcd2dd8ffaf3e443b09930057c01d1 by Miss Islington (bot) in branch '3.6':
bpo-22057: Clarify eval() documentation (GH-8812)
https://github.com/python/cpython/commit/f19579b8f1fcd2dd8ffaf3e443b09930057c01d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sun Aug 19 06:53:32 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 10:53:32 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1534676012.06.0.56676864532.issue22057@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the review, Martin, and thanks for the report, Alon!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22057>
_______________________________________

From report at bugs.python.org  Sun Aug 19 07:20:42 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 11:20:42 +0000
Subject: [issue25810] Python 3 documentation for eval is incorrect
In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za>
Message-ID: <1534677642.12.0.56676864532.issue25810@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25810>
_______________________________________

From report at bugs.python.org  Sun Aug 19 08:08:26 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 12:08:26 +0000
Subject: [issue27088] doc: select: epoll.poll: incorrect timeout units,
 missing maxevents
In-Reply-To: <1463960371.93.0.0941923922389.issue27088@psf.upfronthosting.co.za>
Message-ID: <1534680506.29.0.56676864532.issue27088@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report. In the title, you mentioned epoll.poll(), but you gave the link to the poll.poll() documentation. Also, the part you quoted

    If timeout is given, it specifies the length of time in milliseconds
    which the system will wait for events before returning.

is from the poll.poll() documentation.

Currently, the documentation for epoll.poll() is pretty minimal:

    epoll.poll(timeout=-1, maxevents=-1)
    
    Wait for events. timeout in seconds (float)

There is an open issue to improve epoll.poll() documentation: Issue 29247. Also, there is a review comment about explaining the *maxevent* parameter (https://github.com/python/cpython/pull/4798/files#r174309761), so I'm going to address the issues you've mentioned in msg266118 as part of issue 29247.

In the meantime, I'm closing this as a duplicate of issue 29247.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Document return value of epoll.poll
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27088>
_______________________________________

From report at bugs.python.org  Sun Aug 19 08:16:23 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Aug 2018 12:16:23 +0000
Subject: [issue18925] select.poll.modify is not documented
In-Reply-To: <1378328037.99.0.424927131422.issue18925@psf.upfronthosting.co.za>
Message-ID: <1534680983.21.0.56676864532.issue18925@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

poll.modify() is documented in both Python 2 and Python 3 docs:

* https://docs.python.org/2/library/select.html#select.poll.modify

* https://docs.python.org/3/library/select.html#select.poll.modify

> I believe that should be "Modify a registered file descriptor"...

This has already been fixed in https://github.com/python/cpython/commit/632c812942d662b764ade56ef492850e00d92877.

Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18925>
_______________________________________

From report at bugs.python.org  Sun Aug 19 09:13:40 2018
From: report at bugs.python.org (tzongw)
Date: Sun, 19 Aug 2018 13:13:40 +0000
Subject: [issue34433] cancel all other pending child futures
Message-ID: <1534684420.56.0.56676864532.issue34433@psf.upfronthosting.co.za>


New submission from tzongw <tzongw at 163.com>:

In `tasks.gather`, when a child future throws an exception and `return_exceptions` is False, outer future will call `set_exception` while other child futures is still running. In this case, outer future call `_GatheringFuture.cancel' first to cancel all other pending child futures for efficiency.

----------
components: asyncio
messages: 323755
nosy: asvetlov, tzongw, yselivanov
priority: normal
severity: normal
status: open
title: cancel all other pending child futures
type: performance
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34433>
_______________________________________

From report at bugs.python.org  Sun Aug 19 09:26:25 2018
From: report at bugs.python.org (tzongw)
Date: Sun, 19 Aug 2018 13:26:25 +0000
Subject: [issue34433] cancel all other pending child futures
In-Reply-To: <1534684420.56.0.56676864532.issue34433@psf.upfronthosting.co.za>
Message-ID: <1534685184.99.0.56676864532.issue34433@psf.upfronthosting.co.za>


Change by tzongw <tzongw at 163.com>:


----------
keywords: +patch
pull_requests: +8298
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34433>
_______________________________________

From report at bugs.python.org  Sun Aug 19 09:37:10 2018
From: report at bugs.python.org (Andy Maier)
Date: Sun, 19 Aug 2018 13:37:10 +0000
Subject: [issue34434] Removal of kwargs for int() etc not described as change
Message-ID: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>


New submission from Andy Maier <andreas.r.maier at gmx.de>:

Python 3.7 removed support for passing the argument to the built-in functions int(), bool(), float(), list() and tuple() as a keyword argument.

This change is described in the "What's New" for 3.7 (https://docs.python.org/3/whatsnew/3.7.html) in section "API and Feature Removals":

    Functions bool(), float(), list() and tuple() no longer take
    keyword arguments. The first argument of int() can now be passed
    only as positional argument.

The issue is that this change is not described in the documentation of these built-in functions.

----------
messages: 323756
nosy: andymaier
priority: normal
severity: normal
status: open
title: Removal of kwargs for int() etc not described as change
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Sun Aug 19 11:15:32 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 19 Aug 2018 15:15:32 +0000
Subject: [issue18049] Re-enable threading test on OSX
In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za>
Message-ID: <1534691732.79.0.56676864532.issue18049@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I have a patch for making the stack sizes the same in Issue34264.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18049>
_______________________________________

From report at bugs.python.org  Sun Aug 19 12:12:22 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Aug 2018 16:12:22 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1534695142.05.0.56676864532.issue34426@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hi @Nojima and thank you for the report. Do you mind doing a PR?

If not, I can do it myself.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sun Aug 19 12:12:44 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Aug 2018 16:12:44 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1534695164.1.0.56676864532.issue34426@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg323758

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sun Aug 19 12:12:49 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Aug 2018 16:12:49 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1534695169.94.0.56676864532.issue34426@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Content	
 
Hi @Nojima and thank you for the report. Do you mind doing a PR?

If not, I can do it myself if you prefer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sun Aug 19 12:29:44 2018
From: report at bugs.python.org (Mark Harfouche)
Date: Sun, 19 Aug 2018 16:29:44 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1534696184.78.0.56676864532.issue13501@psf.upfronthosting.co.za>


Mark Harfouche <mark.harfouche at gmail.com> added the comment:

Is there still interest in this?

----------
nosy: +Mark Harfouche

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Sun Aug 19 12:35:50 2018
From: report at bugs.python.org (Danish Prakash)
Date: Sun, 19 Aug 2018 16:35:50 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1534696550.76.0.56676864532.issue34426@psf.upfronthosting.co.za>


Danish Prakash <grafitykoncept at gmail.com> added the comment:

@pablogsal I would love to fix this up

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sun Aug 19 12:52:20 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Aug 2018 16:52:20 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1534697540.36.0.56676864532.issue26901@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8300
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26901>
_______________________________________

From report at bugs.python.org  Sun Aug 19 13:08:21 2018
From: report at bugs.python.org (Danish Prakash)
Date: Sun, 19 Aug 2018 17:08:21 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1534698501.56.0.56676864532.issue34426@psf.upfronthosting.co.za>


Change by Danish Prakash <grafitykoncept at gmail.com>:


----------
keywords: +patch
pull_requests: +8301
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Sun Aug 19 13:42:35 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 19 Aug 2018 17:42:35 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
Message-ID: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

A possible NULL return on out-of-memory condition at Objects/unicodeobject.c:6835 is not handled.

Reported by Svace static analyzer.

----------
components: Interpreter Core
messages: 323762
nosy: inada.naoki, izbyshev, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Missing NULL check in unicode_encode_ucs1()
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 13:47:36 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 19 Aug 2018 17:47:36 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534700856.28.0.56676864532.issue34435@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8302
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:51:43 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 19 Aug 2018 18:51:43 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
Message-ID: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The condition for disabling overallocation at 225b055/Objects/bytesobject.c:822 is always false.

Reported by Svace static analyzer.

----------
components: Interpreter Core
messages: 323763
nosy: inada.naoki, izbyshev, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Overallocation is never disabled in _PyBytes_FormatEx()
type: performance
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:52:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 18:52:06 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534704726.6.0.56676864532.issue34435@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 74a307d48ef8b278c4629ca0ef2139be1c9a34e6 by Serhiy Storchaka (Alexey Izbyshev) in branch 'master':
bpo-34435: Add missing NULL check to unicode_encode_ucs1(). (GH-8823)
https://github.com/python/cpython/commit/74a307d48ef8b278c4629ca0ef2139be1c9a34e6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:52:21 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 18:52:21 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534704741.6.0.56676864532.issue34435@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:52:32 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 18:52:32 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534704752.02.0.56676864532.issue34435@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8304

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:53:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 18:53:08 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534704788.71.0.56676864532.issue34435@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your PR Alexey.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:53:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 18:53:20 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534704800.18.0.56676864532.issue34435@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 14:58:51 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 19 Aug 2018 18:58:51 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1534705131.13.0.56676864532.issue34436@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8305
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Sun Aug 19 15:09:12 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Aug 2018 19:09:12 +0000
Subject: [issue34422] __name__ not available for classes in typing module
In-Reply-To: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>
Message-ID: <1534705752.72.0.56676864532.issue34422@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Bisecting this issue revealed that this happened on commit 

d911e40e788fb679723d78b6ea11cabf46caed5a is the first bad commit
commit d911e40e788fb679723d78b6ea11cabf46caed5a
Author: Ivan Levkivskyi <levkivskyi at gmail.com>
Date:   Sat Jan 20 11:23:59 2018 +0000

    bpo-32226: PEP 560: improve typing module (#4906)

    This PR re-designs the internal typing API using the new PEP 560 features.
    However, there are only few minor changes in the public API.


The reason seems that now all of the types are created using `_GenericAlias` that does not copy the `__name__` attribute.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:17:57 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 20:17:57 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534709877.28.0.56676864532.issue34435@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1e596d3a20a1a9d1ef15218ef33795bc9e651b7a by Miss Islington (bot) in branch '3.7':
bpo-34435: Add missing NULL check to unicode_encode_ucs1(). (GH-8823)
https://github.com/python/cpython/commit/1e596d3a20a1a9d1ef15218ef33795bc9e651b7a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:19:21 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Aug 2018 20:19:21 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534709961.19.0.56676864532.issue34435@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e77cdae0f84fc390fed5555ea1f53bbc8746d634 by Miss Islington (bot) in branch '3.6':
bpo-34435: Add missing NULL check to unicode_encode_ucs1(). (GH-8823)
https://github.com/python/cpython/commit/e77cdae0f84fc390fed5555ea1f53bbc8746d634


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:26:22 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 20:26:22 +0000
Subject: [issue34422] __name__ not available for classes in typing module
In-Reply-To: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>
Message-ID: <1534710382.23.0.56676864532.issue34422@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib) -Interpreter Core
nosy: +gvanrossum, levkivskyi
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:26:31 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 19 Aug 2018 20:26:31 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534710391.38.0.56676864532.issue34435@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you for merging!

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:28:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Aug 2018 20:28:13 +0000
Subject: [issue34435] Missing NULL check in unicode_encode_ucs1()
In-Reply-To: <1534700555.39.0.56676864532.issue34435@psf.upfronthosting.co.za>
Message-ID: <1534710493.31.0.56676864532.issue34435@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34435>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:45:24 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 19 Aug 2018 20:45:24 +0000
Subject: [issue34422] __name__ not available for classes in typing module
In-Reply-To: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>
Message-ID: <1534711524.84.0.56676864532.issue34422@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This is an intentional change. It would be a bad idea to use `_name` instead of `__name__`, because semantics is subtly different. Also the fact that type in typing object used to be actual class object was an implementation detail (also typing is still provisional).

The problematic part here is that special types and generic type aliases are still documented as _classes_ in https://docs.python.org/3.7/library/typing.html, I think this needs to be updated. (Plus we should add an explicit note somewhere in the docs that static types and runtime classes should not be confused.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:48:04 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 19 Aug 2018 20:48:04 +0000
Subject: [issue34422] __name__ not available for classes in typing module
In-Reply-To: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>
Message-ID: <1534711684.76.0.56676864532.issue34422@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Oh I just re-read my comment and there are so many typos that I will write a new one, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:49:34 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 19 Aug 2018 20:49:34 +0000
Subject: [issue34422] __name__ not available for classes in typing module
In-Reply-To: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>
Message-ID: <1534711774.73.0.56676864532.issue34422@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This is an intentional change. It would be a bad idea to use `__name__` instead of what is currently `_name`, because semantics is subtly different. Also the fact that types in typing module used to be actual class objects was an implementation detail (also typing module is still provisional).

The problematic part here is that special types and generic type aliases are still documented as _classes_ in https://docs.python.org/3.7/library/typing.html, I think this needs to be updated. (Plus we should add an explicit note somewhere in the docs that static types and runtime classes should not be confused.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Sun Aug 19 16:49:45 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 19 Aug 2018 20:49:45 +0000
Subject: [issue34422] __name__ not available for classes in typing module
In-Reply-To: <1534526466.89.0.56676864532.issue34422@psf.upfronthosting.co.za>
Message-ID: <1534711785.42.0.56676864532.issue34422@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg323770

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34422>
_______________________________________

From report at bugs.python.org  Sun Aug 19 18:20:39 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Sun, 19 Aug 2018 22:20:39 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1534717239.77.0.56676864532.issue34062@psf.upfronthosting.co.za>


Change by Brendan Gerrity <bgerrity at ucdavis.edu>:


----------
pull_requests: +8306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Sun Aug 19 19:24:40 2018
From: report at bugs.python.org (Nathan Benson)
Date: Sun, 19 Aug 2018 23:24:40 +0000
Subject: [issue34437] print statement using \x results in improper and extra
 bytes
Message-ID: <1534721080.82.0.56676864532.issue34437@psf.upfronthosting.co.za>


New submission from Nathan Benson <jfa at packetdamage.com>:

While writing some shellcode I uncovered an unusual bug where Python 3 seems to print out incorrect (and extra) hex bytes using the print statement with \x. Needless to say I was pulling my hair out trying to figure out why my shellcode wasn?t working.  Python 2 behaves as expected.

I haven't tested the latest version of Python 3, but all the versions prior to that seem to have the bug.  I?ve been able to reproduce the bug in Ubuntu Linux and on my Mac.

An example printing "\xfd\x84\x04\x08" I expect to get back "fd 84 04 08", but Python 3 seems to add bytes beginning with c2 and c3 and tosses in random bytes.

For the purpose of these demonstrations:

  Akame:~ jfa$ python2 --version
  Python 2.7.15

  Akame:~ jfa$ python3 --version
  Python 3.7.0


Here is Python 2 operating as expected:

Akame:~ jfa$ python2 -c 'print("\xfd\x84\x04\x08")' | hexdump -C
00000000  fd 84 04 08 0a                                    |.....|
00000005


Here is Python 3 with the exact same print statement:

Akame:~ jfa$ python3 -c 'print("\xfd\x84\x04\x08")' | hexdump -C
00000000  c3 bd c2 84 04 08 0a                              |.......|
00000007

There are 6 bytes not 4 and where did the c3, bd, and c2 come from?

Playing around with it a little bit more it seems like the problem arises when you are printing bytes that start with a-f or 8 or 9:

Here is a-f:

Akame:~ jfa$ for b in {a..f}; do echo "\x${b}0"; python3 -c "print(\"\x${b}0\")" | hexdump -C; done
\xa0
00000000  c2 a0 0a                                          |...|
00000003
\xb0
00000000  c2 b0 0a                                          |...|
00000003
\xc0
00000000  c3 80 0a                                          |...|
00000003
\xd0
00000000  c3 90 0a                                          |...|
00000003
\xe0
00000000  c3 a0 0a                                          |...|
00000003
\xf0
00000000  c3 b0 0a                                          |...|
00000003


Here is 0-9 (notice everything is fine until 8):

Akame:~ jfa$ for b in {0..9}; do echo "\x${b}0"; python3 -c "print(\"\x${b}0\")" | hexdump -C; done
\x00
00000000  00 0a                                             |..|
00000002
\x10
00000000  10 0a                                             |..|
00000002
\x20
00000000  20 0a                                             | .|
00000002
\x30
00000000  30 0a                                             |0.|
00000002
\x40
00000000  40 0a                                             |@.|
00000002
\x50
00000000  50 0a                                             |P.|
00000002
\x60
00000000  60 0a                                             |`.|
00000002
\x70
00000000  70 0a                                             |p.|
00000002
\x80
00000000  c2 80 0a                                          |...|
00000003
\x90
00000000  c2 90 0a                                          |...|
00000003



Here are the same tests with Python 2:

Akame:~ jfa$ for b in {a..f}; do echo "\x${b}0"; python2 -c "print(\"\x${b}0\")" | hexdump -C; done
\xa0
00000000  a0 0a                                             |..|
00000002
\xb0
00000000  b0 0a                                             |..|
00000002
\xc0
00000000  c0 0a                                             |..|
00000002
\xd0
00000000  d0 0a                                             |..|
00000002
\xe0
00000000  e0 0a                                             |..|
00000002
\xf0
00000000  f0 0a                                             |..|
00000002


Akame:~ jfa$ for b in {0..9}; do echo "\x${b}0"; python2 -c "print(\"\x${b}0\")" | hexdump -C; done
\x00
00000000  00 0a                                             |..|
00000002
\x10
00000000  10 0a                                             |..|
00000002
\x20
00000000  20 0a                                             | .|
00000002
\x30
00000000  30 0a                                             |0.|
00000002
\x40
00000000  40 0a                                             |@.|
00000002
\x50
00000000  50 0a                                             |P.|
00000002
\x60
00000000  60 0a                                             |`.|
00000002
\x70
00000000  70 0a                                             |p.|
00000002
\x80
00000000  80 0a                                             |..|
00000002
\x90
00000000  90 0a                                             |..|
00000002


As you can see Python 2 works as expected and Python 3, when printing using \x[a-f08], seem to cause the byte to be replaced with a c2 or c3 and another byte of data.

----------
messages: 323773
nosy: Nathan Benson
priority: normal
severity: normal
status: open
title: print statement using \x results in improper and extra bytes
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34437>
_______________________________________

From report at bugs.python.org  Sun Aug 19 20:20:07 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 20 Aug 2018 00:20:07 +0000
Subject: [issue34437] print statement using \x results in improper and extra
 bytes
In-Reply-To: <1534721080.82.0.56676864532.issue34437@psf.upfronthosting.co.za>
Message-ID: <1534724407.27.0.56676864532.issue34437@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You wrote:

> There are 6 bytes not 4 and where did the c3, bd, and c2 come from?

In Python 2, strings are byte strings, in Python 3, strings by default are Unicode text strings. You are seeing the UTF-8 representation of the text string.

py> "\xfd\x84\x04\x08".encode('utf-8')
b'\xc3\xbd\xc2\x84\x04\x08'

So the behaviour in Python 3 is correct and not a bug, it has just changed (intentionally) from Python 2.

Googling may help you find more about this:

https://duckduckgo.com/?q=python3+write+bytes+to+stdout

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34437>
_______________________________________

From report at bugs.python.org  Sun Aug 19 23:25:35 2018
From: report at bugs.python.org (David)
Date: Mon, 20 Aug 2018 03:25:35 +0000
Subject: [issue34438] do_handshake stuck in ssl.py
Message-ID: <1534735535.4.0.56676864532.issue34438@psf.upfronthosting.co.za>


New submission from David <davidwho at gmail.com>:

Sometimes, rarely, API calls will get stuck indefinitely on ssl.py. Stack trace:

  response = json.loads(urllib.request.urlopen(req).read())
  File "/usr/lib/python3.6/urllib/request.py", line 223, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.6/urllib/request.py", line 526, in open
    response = self._open(req, data)
  File "/usr/lib/python3.6/urllib/request.py", line 544, in _open
    '_open', req)
  File "/usr/lib/python3.6/urllib/request.py", line 504, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.6/urllib/request.py", line 1361, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/usr/lib/python3.6/urllib/request.py", line 1318, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/lib/python3.6/http/client.py", line 1239, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1285, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1234, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/lib/python3.6/http/client.py", line 1026, in _send_output
    self.send(msg)
  File "/usr/lib/python3.6/http/client.py", line 964, in send
    self.connect()
  File "/usr/lib/python3.6/http/client.py", line 1400, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python3.6/ssl.py", line 407, in wrap_socket
    _context=self, _session=session)
  File "/usr/lib/python3.6/ssl.py", line 814, in __init__
    self.do_handshake()
  File "/usr/lib/python3.6/ssl.py", line 1068, in do_handshake
    self._sslobj.do_handshake()
  File "/usr/lib/python3.6/ssl.py", line 689, in do_handshake
    self._sslobj.do_handshake()


Almost identical issue as https://stackoverflow.com/questions/19938593/web-app-hangs-for-several-hours-in-ssl-py-at-self-sslobj-do-handshake
But using python 3.6

----------
assignee: christian.heimes
components: SSL
messages: 323775
nosy: christian.heimes, david987
priority: normal
severity: normal
status: open
title: do_handshake stuck in ssl.py
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34438>
_______________________________________

From report at bugs.python.org  Sun Aug 19 23:51:21 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 20 Aug 2018 03:51:21 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1534737081.67.0.56676864532.issue30717@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30717>
_______________________________________

From report at bugs.python.org  Mon Aug 20 01:51:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 05:51:58 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>
Message-ID: <1534744318.85.0.56676864532.issue34423@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Mon Aug 20 02:08:53 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 20 Aug 2018 06:08:53 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534745333.24.0.56676864532.issue34410@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Mon Aug 20 03:40:35 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 20 Aug 2018 07:40:35 +0000
Subject: [issue34401] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534750835.56.0.56676864532.issue34401@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
pull_requests: +8307
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Mon Aug 20 04:00:09 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 20 Aug 2018 08:00:09 +0000
Subject: [issue12991] Python 64-bit build on HP Itanium - Executable built
 successfully but modules failed with HP Compiler
In-Reply-To: <1316173380.25.0.744886006815.issue12991@psf.upfronthosting.co.za>
Message-ID: <1534752009.91.0.56676864532.issue12991@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Cannot reproduced on master:
export LDFLAGS="-L/usr/local/lib/hpux64 +DD64"
export CFLAGS=+DD64

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_bz2                  _curses_panel         _gdbm
_lzma                 _sqlite3              _tkinter
_uuid                 ossaudiodev           readline
spwd                  zlib
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd
time


Failed to build these modules:
_ctypes               _dbm                  _elementtree
cmath                 math                  pyexpat


Following modules built successfully but were removed because they could not be imported:
_asyncio

running build_scripts
copying and adjusting /var/osipovmi/cpython/Tools/scripts/pydoc3 -> build/scripts-3.8
copying and adjusting /var/osipovmi/cpython/Tools/scripts/idle3 -> build/scripts-3.8
copying and adjusting /var/osipovmi/cpython/Tools/scripts/2to3 -> build/scripts-3.8
changing mode of build/scripts-3.8/pydoc3 from 640 to 755
changing mode of build/scripts-3.8/idle3 from 640 to 755
changing mode of build/scripts-3.8/2to3 from 640 to 755
renaming build/scripts-3.8/pydoc3 to build/scripts-3.8/pydoc3.8
renaming build/scripts-3.8/idle3 to build/scripts-3.8/idle3.8
renaming build/scripts-3.8/2to3 to build/scripts-3.8/2to3-3.8

$ file ./python
./python:       ELF-64 executable object file - IA64
$ ./python
Python 3.8.0a0 (heads/bpo-34412:f1331c0e83, Aug 20 2018, 09:53:38) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>>

The necessary bits are libraries in 64 bit which I have only in 32 bit.
This issue can be closed.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12991>
_______________________________________

From report at bugs.python.org  Mon Aug 20 04:12:37 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 20 Aug 2018 08:12:37 +0000
Subject: [issue1648957] HP-UX:
 _ctypes/libffi/src/ia64/ffi/__attribute__/native cc
Message-ID: <1534752757.88.0.56676864532.issue1648957@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Cannot verify:
$ file ./build/lib.hp-ux-B.11.31-ia64-3.8-pydebug/_ctypes.so
./build/lib.hp-ux-B.11.31-ia64-3.8-pydebug/_ctypes.so:  ELF-32 shared object file - IA64
$ ldd ./build/lib.hp-ux-B.11.31-ia64-3.8-pydebug/_ctypes.so

./build/lib.hp-ux-B.11.31-ia64-3.8-pydebug/_ctypes.so:
        libffi.so =>    /usr/local/lib/hpux32/libffi.so
        libdl.so.1 =>   /usr/lib/hpux32/libdl.so.1
        libc.so.1 =>    /usr/lib/hpux32/libc.so.1


This issue can be closed.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1648957>
_______________________________________

From report at bugs.python.org  Mon Aug 20 04:15:27 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 20 Aug 2018 08:15:27 +0000
Subject: [issue16533] HPUX: Unable to fork() in thread
In-Reply-To: <1353622712.14.0.676507060266.issue16533@psf.upfronthosting.co.za>
Message-ID: <1534752927.27.0.56676864532.issue16533@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Runs perfectly:
== CPython 3.8.0a0 (heads/bpo-34412:f1331c0e83, Aug 20 2018, 10:14:16) [C]
== HP-UX-B.11.31-ia64-32bit-ELF big-endian
== cwd: /var/osipovmi/cpython/build/test_python_22868
== CPU count: 4
== encodings: locale=utf8, FS=utf-8
Using random seed 4813536
Run tests in parallel using 6 child processes
0:00:02 [1/1] test_thread passed
test_barrier (test.test_thread.BarrierTest) ... waiting for tasks to end
task 0 will run for 0us
task 0 entering 0
task 1 will run for 12us
task 2 will run for 61us
task 3 will run for 31us
task 4 will run for 17us
task 7 will run for 9us
task 6 will run for 77us
task 8 will run for 95us
task 9 will run for 43us
task 5 will run for 48us
task 1 entering 0
task 2 entering 0
task 3 entering 0
task 4 entering 0
task 5 entering 0
task 7 entering 0
task 6 entering 0
task 8 entering 0
task 9 entering 0
task 9 leaving barrier
task 9 will run for 86us
task 0 leaving barrier
task 0 will run for 0us
task 0 entering 1
task 1 leaving barrier
task 1 will run for 25us
task 2 leaving barrier
task 2 will run for 59us
task 3 leaving barrier
task 3 will run for 67us
task 4 leaving barrier
task 4 will run for 91us
task 5 leaving barrier
task 5 will run for 84us
task 7 leaving barrier
task 7 will run for 22us
task 6 leaving barrier
task 6 will run for 31us
task 8 leaving barrier
task 8 will run for 12us
task 9 entering 1
task 1 entering 1
task 2 entering 1
task 3 entering 1
task 4 entering 1
task 5 entering 1
task 7 entering 1
task 6 entering 1
task 8 entering 1
task 8 leaving barrier
task 8 will run for 28us
task 0 leaving barrier
task 0 will run for 0us
task 0 entering 2
task 9 leaving barrier
task 9 will run for 87us
task 1 leaving barrier
task 1 will run for 59us
task 2 leaving barrier
task 2 will run for 82us
task 3 leaving barrier
task 3 will run for 73us
task 4 leaving barrier
task 4 will run for 11us
task 5 leaving barrier
task 5 will run for 17us
task 7 leaving barrier
task 7 will run for 98us
task 6 leaving barrier
task 6 will run for 63us
task 8 entering 2
task 9 entering 2
task 1 entering 2
task 2 entering 2
task 3 entering 2
task 4 entering 2
task 5 entering 2
task 7 entering 2
task 6 entering 2
task 6 leaving barrier
task 0 leaving barrier
task 8 leaving barrier
task 9 leaving barrier
task 1 leaving barrier
task 2 leaving barrier
task 3 leaving barrier
task 4 leaving barrier
task 5 leaving barrier
task 7 leaving barrier
tasks done
ok
test_acquire_contended (test.test_thread.LockTests) ... ok
test_acquire_destroy (test.test_thread.LockTests) ... ok
test_acquire_release (test.test_thread.LockTests) ... ok
test_constructor (test.test_thread.LockTests) ... ok
test_different_thread (test.test_thread.LockTests) ... ok
test_locked_repr (test.test_thread.LockTests) ... ok
test_reacquire (test.test_thread.LockTests) ... ok
test_repr (test.test_thread.LockTests) ... ok
test_state_after_timeout (test.test_thread.LockTests) ... ok
test_thread_leak (test.test_thread.LockTests) ... ok
test_timeout (test.test_thread.LockTests) ... ok
test_try_acquire (test.test_thread.LockTests) ... ok
test_try_acquire_contended (test.test_thread.LockTests) ... ok
test_weakref_deleted (test.test_thread.LockTests) ... ok
test_weakref_exists (test.test_thread.LockTests) ... ok
test_with (test.test_thread.LockTests) ... ok
test_forkinthread (test.test_thread.TestForkInThread) ... ok
test__count (test.test_thread.ThreadRunningTests) ... ok
test_nt_and_posix_stack_size (test.test_thread.ThreadRunningTests) ... caught expected ValueError setting stack_size(4096)
successfully set stack_size(262144)
successfully set stack_size(1048576)
successfully set stack_size(0)
trying stack_size = (262144)
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 86us
task 2 will run for 62us
task 3 will run for 67us
task 4 will run for 61us
task 5 will run for 52us
task 6 will run for 2us
task 7 will run for 1us
task 8 will run for 31us
task 9 will run for 12us
task 10 will run for 22us
task 1 done
task 2 done
task 3 done
task 4 done
task 5 done
task 6 done
task 7 done
task 8 done
task 9 done
task 10 done
all tasks done
trying stack_size = (1048576)
creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for all tasks to complete
task 1 will run for 15us
task 2 will run for 37us
task 3 will run for 12us
task 4 will run for 93us
task 5 will run for 15us
task 6 will run for 45us
task 7 will run for 67us
task 8 will run for 19us
task 9 will run for 89us
task 10 will run for 58us
task 1 done
task 2 done
task 3 done
task 4 done
task 5 done
task 6 done
task 7 done
task 8 done
task 9 done
task 10 done
all tasks done
ok
test_save_exception_state_on_error (test.test_thread.ThreadRunningTests) ... ok
test_stack_size (test.test_thread.ThreadRunningTests) ... ok
test_starting_threads (test.test_thread.ThreadRunningTests) ... creating task 1
creating task 2
creating task 3
creating task 4
creating task 5
creating task 6
creating task 7
creating task 8
creating task 9
creating task 10
waiting for tasks to complete...
task 1 will run for 32us
task 2 will run for 56us
task 3 will run for 63us
task 4 will run for 27us
task 5 will run for 64us
task 6 will run for 41us
task 7 will run for 93us
task 8 will run for 34us
task 9 will run for 63us
task 10 will run for 83us
task 3 done
task 4 done
task 8 done
task 6 done
task 7 done
task 9 done
task 10 done
task 5 done
task 2 done
task 1 done
all tasks done
ok

----------------------------------------------------------------------
Ran 23 tests in 0.949s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2 sec 94 ms
Tests result: SUCCESS


This issue can be closed.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16533>
_______________________________________

From report at bugs.python.org  Mon Aug 20 04:26:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 08:26:51 +0000
Subject: [issue32657] Mutable Objects in SMTP send_message Signature
In-Reply-To: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>
Message-ID: <1534753611.05.0.56676864532.issue32657@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue34246.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Mon Aug 20 04:27:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 08:27:10 +0000
Subject: [issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads
In-Reply-To: <1532685733.19.0.56676864532.issue34246@psf.upfronthosting.co.za>
Message-ID: <1534753630.46.0.56676864532.issue34246@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue32657.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34246>
_______________________________________

From report at bugs.python.org  Mon Aug 20 05:01:03 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 20 Aug 2018 09:01:03 +0000
Subject: [issue34217] windows: cross compilation fails due to headers with
 uppercase
In-Reply-To: <1532475729.27.0.56676864532.issue34217@psf.upfronthosting.co.za>
Message-ID: <1534755663.67.0.56676864532.issue34217@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I'm sorry about that.  I won't merge PR like that next time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34217>
_______________________________________

From report at bugs.python.org  Mon Aug 20 05:25:03 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 20 Aug 2018 09:25:03 +0000
Subject: [issue14568] HP-UX local libraries not included
In-Reply-To: <1334265845.44.0.154291439069.issue14568@psf.upfronthosting.co.za>
Message-ID: <1534757103.53.0.56676864532.issue14568@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
pull_requests: +8308
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14568>
_______________________________________

From report at bugs.python.org  Mon Aug 20 06:20:50 2018
From: report at bugs.python.org (Tomer Keren)
Date: Mon, 20 Aug 2018 10:20:50 +0000
Subject: [issue34439] Expose venv --prompt value to an environment value
Message-ID: <1534760450.03.0.56676864532.issue34439@psf.upfronthosting.co.za>


New submission from Tomer Keren <tomer.keren.dev at gmail.com>:

In the same way the $VIRTUAL_ENV variable tells the virtual environment directory, A variable such as $VENV_NAME or $VENV_PROMPT should tell the value given to the venv `--prompt` option (Introduced in Issue22829).

An individual could override the EnvBuilder class like the docs say, but that wouldn't insure any user will have the variable set. This is crucial for usage in custom libraries that want to display the given prompt.

----------
components: Library (Lib)
messages: 323782
nosy: Tomer
priority: normal
severity: normal
status: open
title: Expose venv --prompt value to an environment value
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34439>
_______________________________________

From report at bugs.python.org  Mon Aug 20 07:22:01 2018
From: report at bugs.python.org (Lennart Grahl)
Date: Mon, 20 Aug 2018 11:22:01 +0000
Subject: [issue34440] Certificate verify failed (works fine in 3.6)
Message-ID: <1534764121.45.0.56676864532.issue34440@psf.upfronthosting.co.za>


New submission from Lennart Grahl <lennart.grahl at gmail.com>:

When running the attached script with the attached cert, Python 3.7 raises an exception (see https://paste.pound-python.org/show/VLr84Yn2Fnz6RSKEq3ui/). In Python 3.6, the certificate is being accepted.

I don't see anything wrong with the self-signed certificate.

You can (hopefully) reproduce this by running minimal_server.py

----------
assignee: christian.heimes
components: SSL
files: minimal_server.zip
messages: 323783
nosy: Lennart Grahl, christian.heimes
priority: normal
severity: normal
status: open
title: Certificate verify failed (works fine in 3.6)
versions: Python 3.7
Added file: https://bugs.python.org/file47754/minimal_server.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34440>
_______________________________________

From report at bugs.python.org  Mon Aug 20 07:43:12 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 20 Aug 2018 11:43:12 +0000
Subject: [issue34440] Certificate verify failed (works fine in 3.6)
In-Reply-To: <1534764121.45.0.56676864532.issue34440@psf.upfronthosting.co.za>
Message-ID: <1534765392.59.0.56676864532.issue34440@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The exception message is:

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: IP address mismatch, certificate is not valid for '127.0.0.1'. (_ssl.c:1045)

The certificate is not valid for the URL. You are connection to a server by IP address, but the certificate is not valid for that IP address.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34440>
_______________________________________

From report at bugs.python.org  Mon Aug 20 08:00:29 2018
From: report at bugs.python.org (Lennart Grahl)
Date: Mon, 20 Aug 2018 12:00:29 +0000
Subject: [issue34440] Certificate verify failed (works fine in 3.6)
In-Reply-To: <1534764121.45.0.56676864532.issue34440@psf.upfronthosting.co.za>
Message-ID: <1534766429.25.0.56676864532.issue34440@psf.upfronthosting.co.za>


Lennart Grahl <lennart.grahl at gmail.com> added the comment:

Hi.

I don't see why the certificate would not be valid for that address. Python 3.6 also accepts it without any modifications to the script. 

Output of openssl x509 -in cert.pem -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            bc:28:67:9a:b0:fe:d6:b8
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = 127.0.0.1
        Validity
            Not Before: Mar 23 16:52:01 2017 GMT
            Not After : Mar 21 16:52:01 2027 GMT
        Subject: CN = 127.0.0.1
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:9d:e3:f2:f6:e2:8c:f3:25:82:3e:9e:bc:c5:69:
                    27:34:be:45:89:4a:51:ce:67:4e:b8:a0:b1:a2:bd:
                    fa:39:f9:38:85:a3:9c:a6:c4:c9:78:24:c7:17:5c:
                    2b:00:af:7f:73:e2:49:68:9c:37:29:ae:69:bf:b5:
                    49:06:a8:b8:1d
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                17:66:86:40:B1:C4:BF:77:09:C7:DC:9F:4D:78:4A:BF:07:19:AD:8C
            X509v3 Authority Key Identifier: 
                keyid:17:66:86:40:B1:C4:BF:77:09:C7:DC:9F:4D:78:4A:BF:07:19:AD:8C

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:09:d2:c1:85:f9:c5:7f:78:3e:cc:90:78:25:dc:
         9e:76:ef:62:7a:e5:38:0a:a1:6c:c6:27:af:ed:ec:1d:12:06:
         02:20:5d:d0:de:8e:46:ee:e3:67:35:66:fe:11:6e:56:b5:70:
         72:16:33:92:66:0f:6c:da:51:0c:74:d8:c1:b8:8f:b5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34440>
_______________________________________

From report at bugs.python.org  Mon Aug 20 08:07:23 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 20 Aug 2018 12:07:23 +0000
Subject: [issue34440] Certificate verify failed (works fine in 3.6)
In-Reply-To: <1534764121.45.0.56676864532.issue34440@psf.upfronthosting.co.za>
Message-ID: <1534766843.43.0.56676864532.issue34440@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Python 3.6 is a little more forgiving than Python 3.7. Python 3.7 uses OpenSSL's hostname verification algorithms, which interpret the RFCs more strictly. You have to include a SAN field of type IP address. Matching against CN has been deprecated for more than 15 years, see https://bugs.chromium.org/p/chromium/issues/detail?id=308330

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34440>
_______________________________________

From report at bugs.python.org  Mon Aug 20 08:10:54 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 20 Aug 2018 12:10:54 +0000
Subject: [issue34438] do_handshake stuck in ssl.py
In-Reply-To: <1534735535.4.0.56676864532.issue34438@psf.upfronthosting.co.za>
Message-ID: <1534767054.41.0.56676864532.issue34438@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It's hard to say what the culprit is. A blocked handshake often indicates a network or a server problem. Either something went wrong between the client and the server or the server refuses to finalize the handshake.

I suggest that you add a timeout and handle the timeout from our application. There is nothing I can do from Python's ssl module.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34438>
_______________________________________

From report at bugs.python.org  Mon Aug 20 08:17:00 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 20 Aug 2018 12:17:00 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534767420.34.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8309

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Mon Aug 20 09:11:09 2018
From: report at bugs.python.org (Lennart Grahl)
Date: Mon, 20 Aug 2018 13:11:09 +0000
Subject: [issue34440] Certificate verify failed (works fine in 3.6)
In-Reply-To: <1534764121.45.0.56676864532.issue34440@psf.upfronthosting.co.za>
Message-ID: <1534770669.18.0.56676864532.issue34440@psf.upfronthosting.co.za>


Lennart Grahl <lennart.grahl at gmail.com> added the comment:

Cheers!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34440>
_______________________________________

From report at bugs.python.org  Mon Aug 20 09:41:11 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 20 Aug 2018 13:41:11 +0000
Subject: [issue34441] NULL dereference when issubclass() is called on a class
 with bogus __subclasses__
Message-ID: <1534772471.92.0.56676864532.issue34441@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

>>> from abc import ABCMeta
>>> class S(metaclass=ABCMeta):
...   __subclasses__ = None
... 
>>> issubclass(int, S)
Segmentation fault (core dumped)

This is the result of missing NULL check for 'subclasses' in _abc__abc_subclasscheck_impl (Modules/_abc.c):

    /* 6. Check if it's a subclass of a subclass (recursive). */
    subclasses = PyObject_CallMethod(self, "__subclasses__", NULL);
    if (!PyList_Check(subclasses)) {
        PyErr_SetString(PyExc_TypeError, "__subclasses__() must return a list");
        goto end;
    }

Reported by Svace static analyzer.

----------
components: Extension Modules
messages: 323789
nosy: inada.naoki, izbyshev, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: NULL dereference when issubclass() is called on a class with bogus __subclasses__
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34441>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:05:21 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 20 Aug 2018 14:05:21 +0000
Subject: [issue34441] NULL dereference when issubclass() is called on a class
 with bogus __subclasses__
In-Reply-To: <1534772471.92.0.56676864532.issue34441@psf.upfronthosting.co.za>
Message-ID: <1534773921.62.0.56676864532.issue34441@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8310
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34441>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:36:25 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 20 Aug 2018 14:36:25 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534775785.41.0.56676864532.issue30411@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 4c8555773a801f957297132a92c0acb382d640e4 by Xiang Zhang in branch 'master':
bpo-30411: Use --git-dir instead of -C to make git work under version below 1.8.5. (GH-8744)
https://github.com/python/cpython/commit/4c8555773a801f957297132a92c0acb382d640e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:36:40 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Aug 2018 14:36:40 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534775800.41.0.56676864532.issue30411@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8311

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:36:50 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Aug 2018 14:36:50 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534775810.13.0.56676864532.issue30411@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8312

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:40:14 2018
From: report at bugs.python.org (Stephen Kelly)
Date: Mon, 20 Aug 2018 14:40:14 +0000
Subject: [issue34442] zlib module not built on windows
Message-ID: <1534776014.27.0.56676864532.issue34442@psf.upfronthosting.co.za>


New submission from Stephen Kelly <steveire at gmail.com>:

I tried to build python 3.7.0 from source.

I ran the PCBuild/build.bat script. That downloaded zlib to the external/ directory.

However, it does not seem to be built. When running I get:

python\3.7.0\lib\zipfile.py", line 646, in _check_compression                                                                                                                       "Compression requires the (missing) zlib module")                                                                                                                                                                RuntimeError: Compression requires the (missing) zlib module  

I examined PCBuild/pcbuild.proj. It makes no mention of zlib, though it mentions other externals.

I notice that Python 3.6.1 contained zlib in Modules/zlib instead of coming from external/.

Presumably that source was moved, but the Windows-related scripts were not updated.

----------
components: Extension Modules
messages: 323791
nosy: steveire
priority: normal
severity: normal
status: open
title: zlib module not built on windows
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34442>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:47:57 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 20 Aug 2018 14:47:57 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534776477.95.0.56676864532.issue30411@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
pull_requests: +8313

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 10:48:34 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Aug 2018 14:48:34 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534776514.97.0.56676864532.issue30411@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2011dd77b6bd6f02f54ceef9a80a22bd373b66e2 by Miss Islington (bot) in branch '3.7':
bpo-30411: Use --git-dir instead of -C to make git work under version below 1.8.5. (GH-8744)
https://github.com/python/cpython/commit/2011dd77b6bd6f02f54ceef9a80a22bd373b66e2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 11:08:57 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 20 Aug 2018 15:08:57 +0000
Subject: [issue34442] zlib module not built on windows
In-Reply-To: <1534776014.27.0.56676864532.issue34442@psf.upfronthosting.co.za>
Message-ID: <1534777736.99.0.56676864532.issue34442@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Stephen,

zlib is built into the core binary (pythonXY.dll) when you build with `IncludeExternals`; see PCbuild/pythoncore.vcxproj.  Using PCbuild/build.bat should do that automatically (unless you tell it not to), but if it's not we may need to fix something.

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34442>
_______________________________________

From report at bugs.python.org  Mon Aug 20 11:15:18 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 20 Aug 2018 15:15:18 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534778118.44.0.56676864532.issue30411@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 95f9e14e33b713f35f5368acf7be56750bbdb5a8 by Xiang Zhang in branch '2.7':
[2.7] bpo-30411: Use --git-dir instead of -C to make git work under version below 1.8.5. (GH-8744) (GH-8838)
https://github.com/python/cpython/commit/95f9e14e33b713f35f5368acf7be56750bbdb5a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 11:19:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 20 Aug 2018 15:19:30 +0000
Subject: [issue30411] git doesn't support "-C" args under 1.8.5 occurs in
 configure.ac
In-Reply-To: <1495272562.29.0.0547762381804.issue30411@psf.upfronthosting.co.za>
Message-ID: <1534778370.55.0.56676864532.issue30411@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30411>
_______________________________________

From report at bugs.python.org  Mon Aug 20 11:33:06 2018
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 20 Aug 2018 15:33:06 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534779186.88.0.56676864532.issue26544@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

no, it's not fixed at all. Setting as a release blocker for 3.6 and 3.7.

----------
keywords: +3.6regression, 3.7regression
nosy: +benjamin.peterson, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:00:30 2018
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 20 Aug 2018 16:00:30 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534780830.84.0.56676864532.issue26544@psf.upfronthosting.co.za>


Change by Matthias Klose <doko at debian.org>:


Added file: https://bugs.python.org/file47755/platform-no-distutils.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:00:56 2018
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 20 Aug 2018 16:00:56 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534780856.54.0.56676864532.issue26544@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

proposed patch attached

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:11:07 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 20 Aug 2018 16:11:07 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1534781467.35.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Although the default is different (i.e., roman8 versus latin1 (iso8859-1)) both HP-UX and AIX (like Windows, cp1252) this issue and issue 33347 are related.

As I mentioned in https://bugs.python.org/issue34347#msg323319 the string seen by self.get_output() is not the same string as "expected".

If I recall, there may be a way to almost get the two be the same - excect "expected" is a bytes object and the value returned as CLI output is a regular string.

I am thinking, maybe the "easy" way will be to add AIX, HP-UX, and others to skip this test. Rather than hard-code, do a query to see what the default is, and it it is not UTF-8 - skip the test.

In any case, it seems to be broken for any system that does not have UTF-8 as default.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:26:18 2018
From: report at bugs.python.org (Jason Spencer)
Date: Mon, 20 Aug 2018 16:26:18 +0000
Subject: [issue34425] :s formatting broken for objects without __format__
In-Reply-To: <1534612328.33.0.56676864532.issue34425@psf.upfronthosting.co.za>
Message-ID: <CANoX0mHN3M-TRGBZPEKUmybBCZ4d7D+WDmgTKxA3k47XMqj8vw@mail.gmail.com>


Jason Spencer <jasonspencer at google.com> added the comment:

Then I would argue that it is at least a documentation bug.  The 3.6 format
spec mini language still claims that {} is equivalent to {:s}, which now is
only conditionally true.

I would also argue that having different behavior for {} and {:s}, which
are semantically the same in the client's eye, forces the client code to
understand more about the object they are stringifying than should be
necessary.  If one works, so should the other by all descriptions of the
format spec.  If the format spec is *just* ':s', the library should call
the target's __str__ if __format__ is not defined.  The library seems
willing to do this for the empty format string, but not when the client
code specifically asks for a string....

On Sat, Aug 18, 2018 at 10:12 AM Eric V. Smith <report at bugs.python.org>
wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> I agree this is the desired behavior, and not a bug.
>
> Because you are not specifying a __format__ in your class,
> object.__format__ is being called. By design, it does not understand any
> formatting specifiers, instead reserving them for your class to implement.
> "!s" is the correct way to convert your type to a string. Either that, or
> add a __format__ that understands "s".
>
> Note that not all types understand "s", for example, datetime.
>
> ----------
> assignee:  -> eric.smith
> nosy: +eric.smith
> stage:  -> resolved
> status: pending -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34425>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34425>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:34:28 2018
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 20 Aug 2018 16:34:28 +0000
Subject: [issue34443] enum repr should use __qualname__
Message-ID: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

The __repr__ output of an enum class should use __qualname__ instead of __name__. The following example shows the problem:

import enum

class X:
   class I:
      pass

class Y:
   class I(enum.Enum):
      pass

print(X.I)
print(Y.I)

This prints:

<class '__main__.X.I'>
<enum 'I'>

I would have expected it to print

<class '__main__.X.I'>
<enum 'Y.I'>

or even for maximum consistency

<class '__main__.X.I'>
<enum '__main__.Y.I'>

----------
components: Library (Lib)
messages: 323799
nosy: doerwalter
priority: normal
severity: normal
status: open
title: enum repr should use __qualname__
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:35:45 2018
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 20 Aug 2018 16:35:45 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1534782945.59.0.56676864532.issue34443@psf.upfronthosting.co.za>


Change by Walter D?rwald <walter at livinglogic.de>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:55:24 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 20 Aug 2018 16:55:24 +0000
Subject: [issue31715] Add mimetype for extension .mjs
In-Reply-To: <1507302393.84.0.213398074469.issue31715@psf.upfronthosting.co.za>
Message-ID: <1534784124.9.0.56676864532.issue31715@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31715>
_______________________________________

From report at bugs.python.org  Mon Aug 20 12:57:16 2018
From: report at bugs.python.org (daniel hahler)
Date: Mon, 20 Aug 2018 16:57:16 +0000
Subject: [issue34444] Module's __file__ should be absolute always ("." in
 sys.path)
Message-ID: <1534784236.56.0.56676864532.issue34444@psf.upfronthosting.co.za>


New submission from daniel hahler <python-bugs at thequod.de>:

With "." in sys.path the "__file__" attribute will be a relative path, and therefore cannot be used after "chdir".

This likely affects relative paths in general, but have not tested it.

```
import os
import sys

sys.path.insert(0, '.')

# Importing it before chdir already causes failure.
import imported

os.chdir('/')
print(imported.__file__)  # ./imported.py
assert imported.__file__ == os.path.abspath(imported.__file__)
```

It works for "" in sys.path (https://bugs.python.org/issue18416).

----------
components: Interpreter Core
messages: 323800
nosy: blueyed
priority: normal
severity: normal
status: open
title: Module's __file__ should be absolute always ("." in sys.path)
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34444>
_______________________________________

From report at bugs.python.org  Mon Aug 20 13:15:59 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 17:15:59 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1534785359.48.0.56676864532.issue34443@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

__qualname__ should be used only together with __module__.

I agree that the repr of enum should be more consistent with the repr of class.

----------
nosy: +barry, eli.bendersky, ethan.furman, serhiy.storchaka
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Mon Aug 20 13:22:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 17:22:27 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534785747.66.0.56676864532.issue26544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

platform-no-distutils.diff restores the original bug: "2.9" > "2.10".

PR 8356 removes the dependency from distutils and use a sophisticated function for parsing versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 20 13:30:39 2018
From: report at bugs.python.org (Stefan Tjarks)
Date: Mon, 20 Aug 2018 17:30:39 +0000
Subject: [issue34445] asyncio support in doctests
Message-ID: <1534786239.59.0.56676864532.issue34445@psf.upfronthosting.co.za>


New submission from Stefan Tjarks <stefan.tjarks at eventbase.com>:

When writing a docstring for an async function I wrote a doctest for it.

```
async def hello_world():
    """
    Will great the world with a friendly hello.

    >>> await hello_world()
    "hello world"
    """
    return "hello world"
```

I kind of expected an error that no event loop is running but actually get a SyntaxError.

```
**********************************************************************
File "asyncdoctest.py", line 5, in __main__.hello_world
Failed example:
    await hello_world()
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib/python3.6/doctest.py", line 1330, in __run
        compileflags, 1), test.globs)
      File "<doctest __main__.hello_world[0]>", line 1
        await hello_world()
                        ^
    SyntaxError: invalid syntax
**********************************************************************
1 items had failures:
   1 of   1 in __main__.hello_world
***Test Failed*** 1 failures.
```

Is the SyntaxError intentional or does doctest simply not support asyncio syntax?

----------
components: Library (Lib), asyncio
files: asyncdoctest.py
messages: 323803
nosy: Stefan Tjarks, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio support in doctests
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47756/asyncdoctest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34445>
_______________________________________

From report at bugs.python.org  Mon Aug 20 13:39:51 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 20 Aug 2018 17:39:51 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1534786791.02.0.56676864532.issue34443@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Mon Aug 20 13:54:47 2018
From: report at bugs.python.org (Augusto Hack)
Date: Mon, 20 Aug 2018 17:54:47 +0000
Subject: [issue33569] dataclasses InitVar does not maintain any type info
In-Reply-To: <1526647195.4.0.682650639539.issue33569@psf.upfronthosting.co.za>
Message-ID: <1534787687.18.0.56676864532.issue33569@psf.upfronthosting.co.za>


Augusto Hack <me at hak.cx> added the comment:

I have made some changes to expose the InitVar type, they are available here:

https://github.com/hackaugusto/dataclasses/tree/initvar_type

Are these changes sufficient?

----------
nosy: +hack.augusto

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33569>
_______________________________________

From report at bugs.python.org  Mon Aug 20 13:57:12 2018
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 20 Aug 2018 17:57:12 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534787832.29.0.56676864532.issue26544@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

fine! what prevents merging and backporting this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:29:12 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Aug 2018 19:29:12 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534793352.36.0.56676864532.issue34434@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Any interest in submitting a pull request to update the documentation?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +brett.cannon, docs at python
title: Removal of kwargs for int() etc not described as change -> Removal of kwargs for built-in types not covered with "changed in Python" note in documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:35:53 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 20 Aug 2018 19:35:53 +0000
Subject: [issue34407] datetime.time.isoformat function has inconsistent
 behavior with timezone
In-Reply-To: <1534270684.14.0.56676864532.issue34407@psf.upfronthosting.co.za>
Message-ID: <1534793753.71.0.56676864532.issue34407@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

For one thing, this is not how pytz is supposed to be used. You have fallen prey to one of the most common errors when using pytz. See my blog post: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

The issue at hand is also more about what `pytz`'s time zones do than anything to do with `datetime.time`. If you use the correct `pytz` interface, you get:

>>> pytz.timezone('Asia/Seoul').localize(time(**t))
pytz/tzinfo.py in localize(self, dt, is_dst)
    321         possible_loc_dt = set()
    322         for delta in [timedelta(days=-1), timedelta(days=1)]:
--> 323             loc_dt = dt + delta
    324             idx = max(0, bisect_right(
    325                 self._utc_transition_times, loc_dt) - 1)

TypeError: unsupported operand type(s) for +: 'datetime.time' and 'datetime.timedelta'

Though this could rightly be called a bug in `pytz`. However, even using `dateutil`, you will find that this doesn't work:

>time(**t, tzinfo=tz.gettz('Asia/Seoul')).isoformat()
'12:31:21.213456'

The reason is that attaching a `tzinfo` to `datetime.time` barely makes sense, and doesn't work if the time zone depends on the day (e.g. anything with DST), because you don't *know* what day it is, so you can't get an offset. As a result, when `isoformat` attempts to query the datetime for `utcoffset()` it gets `None`, and thus has nothing to print.

It works for some of the ones you mentioned because those ones are fixed offsets that never change, and so there *is* a valid value for it, even if no date component is present. See:

>>> time(**t, tzinfo=tz.tzoffset("EST", -18000))
datetime.time(12, 31, 21, 213456, tzinfo=tzoffset('EST', -18000))

>>> time(**t, tzinfo=tz.tzoffset("EST", -18000)).isoformat()
'12:31:21.213456-05:00'

I believe this issue can be closed.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34407>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:43:36 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 20 Aug 2018 19:43:36 +0000
Subject: [issue34365] datetime's documentation refers to "comparison [...]
 falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1534794216.66.0.56676864532.issue34365@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34365>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:46:06 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 20 Aug 2018 19:46:06 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1534794366.28.0.56676864532.issue1100942@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:46:20 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 20 Aug 2018 19:46:20 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1534794380.15.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This failure seems related to the issue:

https://buildbot.python.org/all/#/builders/139/builds/74

=====================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/test_gdb.py", line 808, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
test test_gdb failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/test/test_gdb.py", line 808, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 (PyObject_Print) pending.\n.....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:46:27 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 20 Aug 2018 19:46:27 +0000
Subject: [issue34404] test_time incorrectly defined
In-Reply-To: <1534253809.16.0.56676864532.issue34404@psf.upfronthosting.co.za>
Message-ID: <1534794387.16.0.56676864532.issue34404@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34404>
_______________________________________

From report at bugs.python.org  Mon Aug 20 15:47:35 2018
From: report at bugs.python.org (jcc2220)
Date: Mon, 20 Aug 2018 19:47:35 +0000
Subject: [issue34446] ambiguous _max_size parameter in SpooledTemporaryFile
Message-ID: <1534794455.51.0.56676864532.issue34446@psf.upfronthosting.co.za>


New submission from jcc2220 <jcc2220 at columbia.edu>:

When _max_size is set to 0, the _check method will never call rollover, as the conditional for a rollover is never satisfied.  However, in the truncate method, the _max_size is not checked against 0, and so a rollover could be called when it is 0.  This is more of an issue of consistency - should 0 mean that it will never rollover?  If so, truncate should be modified.  Should 0 be interpreted as 'always rollover'?  If so, the _check should be modified.  Personally, I'd rather have something like -1 mean never, 0 mean always, and >0 mean only when greater than specified size.


John

----------
components: Library (Lib)
messages: 323809
nosy: jcc2220
priority: normal
severity: normal
status: open
title: ambiguous _max_size parameter in SpooledTemporaryFile
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34446>
_______________________________________

From report at bugs.python.org  Mon Aug 20 16:04:23 2018
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 20 Aug 2018 20:04:23 +0000
Subject: [issue34441] NULL dereference when issubclass() is called on a class
 with bogus __subclasses__
In-Reply-To: <1534772471.92.0.56676864532.issue34441@psf.upfronthosting.co.za>
Message-ID: <1534795463.88.0.56676864532.issue34441@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset cdbf50cba1664f72ae6621a89c324a32fea70377 by Berker Peksag (Alexey Izbyshev) in branch 'master':
bpo-34441: Fix ABC.__subclasscheck__ crash on classes with invalid __subclasses__ (GH-8835)
https://github.com/python/cpython/commit/cdbf50cba1664f72ae6621a89c324a32fea70377


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34441>
_______________________________________

From report at bugs.python.org  Mon Aug 20 16:04:40 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Aug 2018 20:04:40 +0000
Subject: [issue34441] NULL dereference when issubclass() is called on a class
 with bogus __subclasses__
In-Reply-To: <1534772471.92.0.56676864532.issue34441@psf.upfronthosting.co.za>
Message-ID: <1534795480.21.0.56676864532.issue34441@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8314

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34441>
_______________________________________

From report at bugs.python.org  Mon Aug 20 16:42:23 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Aug 2018 20:42:23 +0000
Subject: [issue34441] NULL dereference when issubclass() is called on a class
 with bogus __subclasses__
In-Reply-To: <1534772471.92.0.56676864532.issue34441@psf.upfronthosting.co.za>
Message-ID: <1534797743.73.0.56676864532.issue34441@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d1f0ccc7e65ef7abeab779f5d0aca2f18eb9b2a4 by Miss Islington (bot) in branch '3.7':
bpo-34441: Fix ABC.__subclasscheck__ crash on classes with invalid __subclasses__ (GH-8835)
https://github.com/python/cpython/commit/d1f0ccc7e65ef7abeab779f5d0aca2f18eb9b2a4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34441>
_______________________________________

From report at bugs.python.org  Mon Aug 20 16:47:06 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 20 Aug 2018 20:47:06 +0000
Subject: [issue34441] NULL dereference when issubclass() is called on a class
 with bogus __subclasses__
In-Reply-To: <1534772471.92.0.56676864532.issue34441@psf.upfronthosting.co.za>
Message-ID: <1534798026.96.0.56676864532.issue34441@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34441>
_______________________________________

From report at bugs.python.org  Mon Aug 20 17:46:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 21:46:00 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1534801560.6.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8315

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Mon Aug 20 17:48:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 21:48:27 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1534801707.9.0.56676864532.issue34171@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 8841 prevents creating Lib/trace.cover when run the trace module.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Mon Aug 20 17:48:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Aug 2018 21:48:51 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1534801731.02.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:11:45 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 21 Aug 2018 03:11:45 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534821105.13.0.56676864532.issue34400@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 3e26e42c905852394fa136f1cc564dac98b56166 by Benjamin Peterson (Zackery Spytz) in branch 'master':
bpo-34400: Fix more undefined behavior in parsetok.c (GH-8833)
https://github.com/python/cpython/commit/3e26e42c905852394fa136f1cc564dac98b56166


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:12:07 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Aug 2018 03:12:07 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534821127.31.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8316

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:12:17 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Aug 2018 03:12:17 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534821137.67.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8317

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:23:19 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Aug 2018 03:23:19 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534821799.34.0.56676864532.issue34400@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 985dcd49cab44bba63ffebe413a9ef17b3da5fa7 by Miss Islington (bot) in branch '3.7':
bpo-34400: Fix more undefined behavior in parsetok.c (GH-8833)
https://github.com/python/cpython/commit/985dcd49cab44bba63ffebe413a9ef17b3da5fa7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:35:50 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Aug 2018 03:35:50 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534822549.99.0.56676864532.issue34400@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e496b2b57a7b6e2633b741b1d5a934a7004ea3da by Miss Islington (bot) in branch '3.6':
bpo-34400: Fix more undefined behavior in parsetok.c (GH-8833)
https://github.com/python/cpython/commit/e496b2b57a7b6e2633b741b1d5a934a7004ea3da


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:38:31 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Aug 2018 03:38:31 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534822711.14.0.56676864532.issue26544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'll merge it if it looks good to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 20 23:48:35 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 21 Aug 2018 03:48:35 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534823315.85.0.56676864532.issue34410@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

It seems to me the problem is tee objects might encounter race conditions while  `PyIter_Next` in `teedataobject_getitem` releases GIL. Other threads then might get into the same branch since `tdo->numread` haven't been updated yet. NULL slots are generated then, 2 objects are read from the underlying iterator and `tdo->numread` is updated twice while only one slot is set.

As for multiprocessing.pool, there is a background task handling thread consuming one tee object and main thread consuming another one. The underlying iterator is `IMapIterator` which `next` method would block on a condition.

While trying, I find the following snippet would also crash:

import threading
import itertools

class C:
    def __iter__(self):
        return self
    def __next__(self):
        return 1

def test(i):
    print(list(i))

i1, i2 = itertools.tee(C())
threading.Thread(target=test, args=(i1,)).start()
print(list(i2))

GDB shows it crashs in `teedataobject_dealloc` -> `teedataobject_clear`. I haven't understood what happened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Tue Aug 21 00:42:32 2018
From: report at bugs.python.org (underscore_asterisk)
Date: Tue, 21 Aug 2018 04:42:32 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
In-Reply-To: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>
Message-ID: <1534826552.69.0.56676864532.issue33187@psf.upfronthosting.co.za>


underscore_asterisk <ap.goel98 at gmail.com> added the comment:

Hello,

Can I take this up? I will create a PR either later today or tomorrow.

----------
nosy: +underscore_asterisk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Tue Aug 21 00:49:03 2018
From: report at bugs.python.org (Andrew Barnert)
Date: Tue, 21 Aug 2018 04:49:03 +0000
Subject: [issue34447] ttk.TreeView (and maybe other functions) is overzealous
 in converting item values to ints
Message-ID: <1534826943.57.0.56676864532.issue34447@psf.upfronthosting.co.za>


New submission from Andrew Barnert <abarnert at yahoo.com>:

See this StackOverflow question for a repro case: https://stackoverflow.com/questions/51941260/

If you store a string that looks like an int in a TreeView's values, then call widget.item(row), the dict's 'values' value has that string converted to an int.

This seems reasonable, because it's legal to store an int in a TreeView, and if tkinter didn't convert the values, you'd store 123 and get back '123'.

However, I think it should only be converting strings that could be a valid Tcl int. If you store the int 123_456, Tcl of course gives you back '123456', not '123_456', so there's no reason for tkinter to convert '123_456' to an int. But it does, because ttk._tclobj_to_py just does a try: return int(s).

---

Maeanwhile, if you instead call widget.item(row, options='values'), the string is left alone. 

At first glance, that made sense. But looking into what tkinter is getting back from Tcl, there's really no difference here. The tuple ('180518-23', '23/06/18') is no more or less conversion-worthy than the same tuple inside the list (<option object: '-text'>, '', <option object: '-image'>, '', <option object: '-values'>, ('180518-23', '23/06/18'), <option object: '-open'>, 0, <option object: '-tags'>, ''). It's just that ttk._val_or_dict doesn't call _tclobj_to_py on the value when it gets back a key-value pair, and I don't see why it shouldn't.

However, that turns out to be a handy workaround for the Stack Overflow user who ran into this problem, so maybe it's better not to change that.

----------
components: Tkinter
messages: 323819
nosy: abarnert
priority: normal
severity: normal
status: open
title: ttk.TreeView (and maybe other functions) is overzealous in converting item values to ints
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34447>
_______________________________________

From report at bugs.python.org  Tue Aug 21 00:51:38 2018
From: report at bugs.python.org (Phillip M. Feldman)
Date: Tue, 21 Aug 2018 04:51:38 +0000
Subject: [issue34417] imp.find_module reacts badly to iterator
In-Reply-To: <1534521936.01.0.56676864532.issue34417@psf.upfronthosting.co.za>
Message-ID: <CAB2ViTaZGyzeOM53RfrBHCL3Nh0uvn=Ztd3gGJvta+hb7zP2vQ@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

It appears that the `importlib` package has the same issue: One can't
provide an iterator for the path.  When searching a large folder tree for
an item that is likely to be found early in the search process (i.e., at a
high level in the folder tree), the available functionality is massively
inefficient.  So, I wrote my own wrapper for `imp.find_module` to do this
job, and will eventually modify this code to use `importlib` instead of
`imp`.

On Fri, Aug 17, 2018 at 9:05 AM Eric Snow <report at bugs.python.org> wrote:

>
> Eric Snow <ericsnowcurrently at gmail.com> added the comment:
>
> There are several issues at hand here, Phillip.  I'll enumerate them below.
>
> Thanks for taking the time to let us know about this.  However, I'm
> closing this issue since realistically the behavior of imp.find_module()
> isn't going to change, particularly in Python 2.7.  Even though the issue
> is closed, feel free to reply, particularly about how you are using
> imp.find_module() (we may be able to point you toward how to use importlib
> instead).
>
> Also, I've changed this issue's type to "enhancement".  imp.find_module()
> is working as designed, so what you are looking for is a feature request.
> Consequently there's a much higher bar for justifying a change.  Here are
> reasons why the requested change doesn't reach that bar:
>
> 1. Python 2.7 is closed to new features.
>
> So imp.find_module() is not going to change.
>
> 2. Python 2.7 is nearing EOL.
>
> We highly recommend that everyone move to Python 3 as soon as possible.
> Hopefully you are in a position to do so.  If you're stuck on Python 2.7
> then you miss the advantages of importlib, along with a ton of other
> benefits.
>
> If you are not going to be able to migrate before 2020 then send an email
> to python-list at python.org asking for recommendations on what to do.
>
> 3. Starting in Python 3.4, using the imp module is discouraged/deprecated.
>
>   "Deprecated since version 3.4: The imp package is pending deprecation in
> favor of importlib." [1]
>
> The importlib package should have everything you need.  What are you using
> imp.find_module() for?  We should be able to demonstrate the equivalent
> using importlib.
>
> 4. The import machinery is designed around using a list (the builtin type,
> not the concept) for the "module search path".
>
> * imp.find_module(): "the list of directory names given by sys.path is
> searched" [2]
> * imp.find_module(): "Otherwise, path must be a list of directory names"
> [2]
> * importlib.find_loader() (deprecated): "optionally within the specified
> path" (which defaults to sys.path) [3]
> * importlib.util.find_spec(): doesn't even have a "path" parameter [4]
> * ModuleSpec.submodule_search_locations: "List of strings for where to
> find submodules" [5]
> * sys.path: "A list of strings that specifies the search path for modules.
> ... Only strings and bytes should be added to sys.path; all other data
> types are ignored during import." [6]
>
>
> [1] https://docs.python.org/3/library/imp.html#module-imp
> [2] https://docs.python.org/3/library/imp.html#imp.find_module
> [3] https://docs.python.org/3/library/importlib.html#importlib.find_loader
> [4]
> https://docs.python.org/3/library/importlib.html#importlib.util.find_spec
> [5]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations
> [6] https://docs.python.org/3/library/sys.html#sys.path
>
> ----------
> nosy: +brett.cannon, eric.snow
> resolution:  -> wont fix
> stage:  -> resolved
> status: open -> closed
> type: behavior -> enhancement
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34417>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34417>
_______________________________________

From report at bugs.python.org  Tue Aug 21 01:12:11 2018
From: report at bugs.python.org (William Schwartz)
Date: Tue, 21 Aug 2018 05:12:11 +0000
Subject: [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if
 sys.modules changes size
In-Reply-To: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za>
Message-ID: <1534828331.29.0.56676864532.issue29620@psf.upfronthosting.co.za>


William Schwartz <wkschwartz at gmail.com> added the comment:

I am also running into this problem. I'm not 100%, but I'm pretty sure that looping over sys.modules and accessing __warningregistry__ on each module triggers one of my module's __getattr__ functions (PEP 562), which in turn uses setuptools entry points to import an arbitrary set of other modules.

Bizarrely, however, I cannot reproduce on macOS, only Linux. Presumably there's something platform dependent about how the default unittest test runner orders my tests, and hence which modules have already been loaded by the time I call assertWarnsRegex.

----------
nosy: +William.Schwartz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29620>
_______________________________________

From report at bugs.python.org  Tue Aug 21 01:40:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Aug 2018 05:40:04 +0000
Subject: [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if
 sys.modules changes size
In-Reply-To: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za>
Message-ID: <1534830004.75.0.56676864532.issue29620@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 2.7, Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29620>
_______________________________________

From report at bugs.python.org  Tue Aug 21 01:53:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Aug 2018 05:53:15 +0000
Subject: [issue34447] ttk.TreeView (and maybe other functions) is overzealous
 in converting item values to ints
In-Reply-To: <1534826943.57.0.56676864532.issue34447@psf.upfronthosting.co.za>
Message-ID: <1534830795.11.0.56676864532.issue34447@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34447>
_______________________________________

From report at bugs.python.org  Tue Aug 21 02:27:59 2018
From: report at bugs.python.org (underscore_asterisk)
Date: Tue, 21 Aug 2018 06:27:59 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1534832879.23.0.56676864532.issue34443@psf.upfronthosting.co.za>


underscore_asterisk <ap.goel98 at gmail.com> added the comment:

Hi,
I would like to work on this issue. I can submit a PR by tomorrow (or maybe even later today).

----------
nosy: +underscore_asterisk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Tue Aug 21 03:26:53 2018
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Aug 2018 07:26:53 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534836413.76.0.56676864532.issue26544@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I added a comment to the PR, but other than that I think it's good to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Tue Aug 21 03:47:02 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 21 Aug 2018 07:47:02 +0000
Subject: [issue34194] test_ssl, AIX, and defaults for _ssl connections
In-Reply-To: <1533393423.72.0.56676864532.issue34194@psf.upfronthosting.co.za>
Message-ID: <15fa7bc4-2c86-686f-263a-9267f0b20fb1@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 04/08/2018 16:37, Michael Felt wrote:
> Some help would really be appreciated!

Gotten a bit further :)

While it does not affect the 'failures', this change decreases 'errors'
by 8 (skipped +1).

I do not expect this to be 'acceptable' - however, I hope this helps an
expert come with some advice.

I played around with defining either OPENSSL_NO_SSL2 or
OPENSSL_VERSION_1_1. However, I do not think the latter is correct (AIX
still goes it - externally, openssl.1.0.2.XXXX, not openssl.1.1.Y.XXXX)
and I felt
the configure process was attempting to use a dynamic process to
establish OPENSSL_NO_SSL2
rather than a definition being added to CFLAGS.

Again - help appreciated!

Before:
FAILED (failures=13, errors=11, skipped=10)
test test_ssl failed

After:
FAILED (failures=13, errors=2, skipped=11)
test test_ssl failed

diff --git a/Modules/_ssl.c b/Modules/_ssl.c
index 2bce4816d2..5fa442cedf 100644
--- a/Modules/_ssl.c
+++ b/Modules/_ssl.c
@@ -5790,9 +5790,11 @@ PyInit__ssl(void)

???? /* protocol versions */
?#ifndef OPENSSL_NO_SSL2
+#ifndef _AIX
???? PyModule_AddIntConstant(m, "PROTOCOL_SSLv2",
???????????????????????????? PY_SSL_VERSION_SSL2);
?#endif
+#endif
?#ifndef OPENSSL_NO_SSL3
???? PyModule_AddIntConstant(m, "PROTOCOL_SSLv3",
???????????????????????????? PY_SSL_VERSION_SSL3);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34194>
_______________________________________

From report at bugs.python.org  Tue Aug 21 03:48:33 2018
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 21 Aug 2018 07:48:33 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1534837713.72.0.56676864532.issue26544@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Tue Aug 21 04:50:26 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 08:50:26 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
Message-ID: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

If the wchar_t is usable on a system we get the following:

> checking for UCS-4 tcl... no
> checking whether wchar_t is signed... no
> yes
> checking whether byte ordering is bigendian... yes
> checking ABIFLAGS... dm
> checking SOABI... cpython-38dm

Yes -- that is a simple 'yes'. Dangling.

A PR is in preparation.

----------
components: Build
messages: 323826
nosy: michael-o
priority: normal
severity: normal
status: open
title: incomplete/missing message from configure.ac for usable wchar_t
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Tue Aug 21 04:58:01 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 08:58:01 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1534841881.54.0.56676864532.issue34448@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8318
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:02:59 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 09:02:59 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1534842179.7.0.56676864532.issue34403@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:03:20 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 09:03:20 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1534842200.2.0.56676864532.issue34448@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:03:49 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 09:03:49 +0000
Subject: [issue34401] Make test_gdb work on HP-UX
In-Reply-To: <1534247656.08.0.56676864532.issue34401@psf.upfronthosting.co.za>
Message-ID: <1534842229.03.0.56676864532.issue34401@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34401>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:04:00 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 09:04:00 +0000
Subject: [issue34404] test_time incorrectly defined
In-Reply-To: <1534253809.16.0.56676864532.issue34404@psf.upfronthosting.co.za>
Message-ID: <1534842240.2.0.56676864532.issue34404@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34404>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:06:55 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 09:06:55 +0000
Subject: [issue34449] HP aCC complains about invalid -fPIC on HP-UX
Message-ID: <1534842415.32.0.56676864532.issue34449@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

The compiler (HP aCC) says:

> /opt/aCC/bin/cc -Ae -b -L/usr/local/lib/hpux32 build/temp.hp-ux-B.11.31-ia64-3.8-pydebug/var/osipovmi/cpython/Modules/_ctypes/_ctypes.o build/temp.hp-ux-B.11.31-ia64-3.8-pydebug/var/osipovmi/cpython/Modules/_ctypes/callbacks.o build/temp.hp-ux-B.11.31-ia64-3.8-pydebug/var/osipovmi/cpython/Modules/_ctypes/callproc.o build/temp.hp-ux-B.11.31-ia64-3.8-pydebug/var/osipovmi/cpython/Modules/_ctypes/stgdict.o build/temp.hp-ux-B.11.31-ia64-3.8-pydebug/var/osipovmi/cpython/Modules/_ctypes/cfield.o -L/usr/local/lib/hpux64 -L/usr/lib/hpux32 -L/usr/lib/hpux64 -L/usr/lib -L/lib -L/usr/local/lib/hpux32 -L/usr/local/lib -lffi -ldl -o build/lib.hp-ux-B.11.31-ia64-3.8-pydebug/_ctypes.so -fPIC
> cc: warning 901: unknown option: `-fPIC': use +help for online documentation.

On clang or GCC this is a compile time option, never a link option. For HP aCC objects must be compiled with +z -- which actually happens -- and linked with +b to a shared library -- which also happens here --. One can safely drop this switch from setup.py.

----------
components: Build
messages: 323827
nosy: michael-o
priority: normal
severity: normal
status: open
title: HP aCC complains about invalid -fPIC on HP-UX
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34449>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:13:41 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 21 Aug 2018 09:13:41 +0000
Subject: [issue34449] HP aCC complains about invalid -fPIC on HP-UX
In-Reply-To: <1534842415.32.0.56676864532.issue34449@psf.upfronthosting.co.za>
Message-ID: <1534842821.97.0.56676864532.issue34449@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8319
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34449>
_______________________________________

From report at bugs.python.org  Tue Aug 21 05:18:07 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 21 Aug 2018 09:18:07 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534843087.7.0.56676864532.issue34410@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Ahh, the infinite iterator could also releases GIL in `PyIter_Next`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Tue Aug 21 06:45:08 2018
From: report at bugs.python.org (Louis Sautier)
Date: Tue, 21 Aug 2018 10:45:08 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534848308.11.0.56676864532.issue34434@psf.upfronthosting.co.za>


Change by Louis Sautier <sautier.louis at gmail.com>:


----------
keywords: +patch
pull_requests: +8320
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Tue Aug 21 06:58:56 2018
From: report at bugs.python.org (iMath)
Date: Tue, 21 Aug 2018 10:58:56 +0000
Subject: [issue34450] improve  shutil.make_archive
Message-ID: <1534849136.61.0.56676864532.issue34450@psf.upfronthosting.co.za>


New submission from iMath <redstone-cold at 163.com>:

The current behavior of shutil.make_archive caused many issues , the problem is mainly on the extracted archive directory hierarchy. These are the proofs:
https://stackoverflow.com/questions/51914467/directory-hierarchy-issue-when-using-shutil-make-archive

https://stackoverflow.com/questions/32640053/compressing-directory-using-shutil-make-archive-while-preserving-directory-str

https://stackoverflow.com/questions/41624800/shutil-make-archive-issue-dont-want-directories-included-in-zip-file

https://stackoverflow.com/questions/50156657/unexpected-file-using-shutil-make-archive-to-compress-file
For example , if I want to create a zip archive of the pip package (path specified by pip.__path__[0])), and need a directory named pip to hold the  files and folders which originally reside in the pip package when unpacking the archive, then I need give root_dirparameter of shutil.make_archive the parent directory of the pippackage path (root_dir=Path(pip.__path__[0]).parent), and then the base_dir parameter the final path component of the pip package path(base_dir=Path(pip.__path__[0]).name) , so it is os.path.join(root_dir, base_dir) that specified the directory to archive , so weird !!!
I suggest to change shutil.make_archive(base_name, format[, root_dir[, base_dir]]) to shutil.make_archive(base_name, format[, archived_dir[, archive_prfix]]) where archived_dirdenotes the path to be archived and archive_prfix denotes the common prefix of all files and directories in the archive (it is just a path component and we shouldn?t assume the existence of it on the file system).

If the current behavior of shutil.make_archive won?t be changed , I?d suggest improve its doc, because  so many people couldn?t grasp the use of shutil.make_archive even consulting the doc , these are the proofs:
https://stackoverflow.com/questions/45245079/python-how-to-use-shutil-make-archive
https://stackoverflow.com/questions/30049201/how-to-compress-a-file-with-shutil-make-archive-in-python

----------
messages: 323829
nosy: redstone-cold
priority: normal
severity: normal
status: open
title: improve  shutil.make_archive

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34450>
_______________________________________

From report at bugs.python.org  Tue Aug 21 08:12:48 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 21 Aug 2018 12:12:48 +0000
Subject: [issue34194] test_ssl, AIX, and defaults for _ssl connections
In-Reply-To: <15fa7bc4-2c86-686f-263a-9267f0b20fb1@felt.demon.nl>
Message-ID: <3cb8b699-4ca9-c3fb-c9cd-837dbc4a903e@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 21/08/2018 09:46, Michael wrote:
> On 04/08/2018 16:37, Michael Felt wrote:
>> Some help would really be appreciated!
> Gotten a bit further :)

A little bit more:

Modules/_ssl.c

?+3707? fprintf(stderr,"load_cert_chain():certfile:%s\n", (char *)
PyBytes_AS_STRING(certfile_bytes));
?+3708????? PySSL_BEGIN_ALLOW_THREADS_S(pw_info.thread_state);
?+3709????? r = SSL_CTX_use_certificate_chain_file(self->ctx,
?+3710????????? PyBytes_AS_STRING(certfile_bytes));
?+3711????? PySSL_END_ALLOW_THREADS_S(pw_info.thread_state);
?+3712????? if (r != 1) {
?+3713? fprintf(stderr,"load_cert_chain():r:%d: errno:%d
ERR_peek_last_error():%d\n", r, errno, ERR_peek_last_error());

load_cert_chain():certfile:/data/prj/python/git/python3-3.8/Lib/test/XXXnonexisting.pem
load_cert_chain():r:0: errno:2 ERR_peek_last_error():0
load_cert_chain():certfile:/data/prj/python/git/python3-3.8/Lib/test/nullcert.pem
load_cert_chain():r:0: errno:0 ERR_peek_last_error():0

Note: I swapped BADCERT and NULLCERT, so now above shows with NULLCERT,
while below

* Below: the first failure - is an OSError (file does not exist, and
passes the test). The second test is "badcert" and AIX is not reporting
the error via ERR_peek_last_error(), but is does seem there is an error
that 'openssl' does return. The third is just to show a connection where
CAfile provides the needed data (for comparison)

FIRST: works as expected

root at x066:[/data/prj/python/python3-3.8]openssl s_client -quiet -connect
www.mindrot.org:443 -CAfile
/data/prj/python/git/python3-3.8/Lib/test/XXXnonex>
804401144:error:02001002:system library:fopen:No such file or
directory:bss_file.c:175:fopen('/data/prj/python/git/python3-3.8/Lib/test/XXXnonexisting.pem','r')
804401144:error:2006D080:BIO routines:BIO_new_file:no such
file:bss_file.c:182:
804401144:error:0B084002:x509 certificate
routines:X509_load_cert_crl_file:system lib:by_file.c:253:
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate

SECOND: there are errors, but not one reported by ERR_peek_last_error()?

BADCERT
root at x066:[/data/prj/python/python3-3.8]openssl s_client -quiet -connect
www.mindrot.org:443 -CAfile
/data/prj/python/git/python3-3.8/Lib/test/badcert.>
804401144:error:0906D064:PEM routines:PEM_read_bio:bad base64
decode:pem_lib.c:830:
804401144:error:0B084009:x509 certificate
routines:X509_load_cert_crl_file:PEM lib:by_file.c:259:
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate

NULLCERT
root at x066:[/data/prj/python/python3-3.8]openssl s_client -quiet -connect
www.mindrot.org:443 -CAfile
/data/prj/python/git/python3-3.8/Lib/test/nullcert>
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate

THIRD: working as expected, for comparison

root at x066:[/data/prj/python/python3-3.8]openssl s_client -quiet -connect
www.mindrot.org:443 -CAfile /var/ssl/cacert.pem
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mindrot.org
verify return:1

Again - help requested!!!

Michael

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34194>
_______________________________________

From report at bugs.python.org  Tue Aug 21 10:55:43 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 14:55:43 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1534863343.36.0.56676864532.issue34347@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I have no idea what's going on here yet but just wanted to report that we are seeing this issue on one FreeBSD buildbot, too:

https://buildbot.python.org/all/#/builders/124/builds/508/steps/4/logs/stdio

I can also reproduce on CentOS 7.

Could this be related to LC_ALL= or related environment variables?

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Tue Aug 21 10:56:17 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 14:56:17 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1534863377.5.0.56676864532.issue34347@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
dependencies: +test_cmd_line test_utf8_mode test_warnings fail in all FreeBSD 3.x (3.8) buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Tue Aug 21 10:56:22 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 14:56:22 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1534863382.33.0.56676864532.issue34403@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
dependencies: +test_cmd_line test_utf8_mode test_warnings fail in all FreeBSD 3.x (3.8) buildbots

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 21 10:56:45 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 14:56:45 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1534863405.11.0.56676864532.issue34207@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
keywords: +3.7regression
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Tue Aug 21 10:56:55 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 14:56:55 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1534863414.99.0.56676864532.issue34347@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
keywords: +3.7regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Tue Aug 21 10:57:09 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 14:57:09 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1534863429.84.0.56676864532.issue34403@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
keywords: +3.7regression
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 21 11:00:28 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 15:00:28 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1534863628.94.0.56676864532.issue34207@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This is definitely dependent on the environment. I can reproduce exactly the same failures on a CentOS 7 box at work, too.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Tue Aug 21 11:18:06 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 15:18:06 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1534864686.38.0.56676864532.issue34207@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I think the root cause is this: the mentioned tests are invalid when no LC_* or LANG environment variables are present. Michael's sleuthing in issue34347 might provide a way for us to fix those.

As a workaround in the mean time, if this is an option on your system, set LC_ALL=en_US.UTF8, the three failing tests pass now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Tue Aug 21 11:20:05 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 15:20:05 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1534864805.83.0.56676864532.issue34207@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Looking at what's going on here, this is quite possibly a PEP 538 side-effect (I see surrogate escapes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Tue Aug 21 11:20:18 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 21 Aug 2018 15:20:18 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1534864818.44.0.56676864532.issue34207@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Tue Aug 21 11:54:17 2018
From: report at bugs.python.org (Emily Morehouse)
Date: Tue, 21 Aug 2018 15:54:17 +0000
Subject: [issue34450] improve  shutil.make_archive
In-Reply-To: <1534849136.61.0.56676864532.issue34450@psf.upfronthosting.co.za>
Message-ID: <1534866857.9.0.56676864532.issue34450@psf.upfronthosting.co.za>


Emily Morehouse <emilyemorehouse at gmail.com> added the comment:

I'll have to think through this a bit more, but my gut is that it would be much more favorable for backwards-compatibility to clarify the documentation instead of changing the functionality.

In any case, the change would only take effect in 3.8+, so it sounds like a backported documentation update is surely needed.

Thanks for the thorough report! :)

----------
components: +Library (Lib)
nosy: +emilyemorehouse
type:  -> behavior
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34450>
_______________________________________

From report at bugs.python.org  Tue Aug 21 13:09:05 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 21 Aug 2018 17:09:05 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534871345.68.0.56676864532.issue34400@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8321

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Tue Aug 21 13:19:30 2018
From: report at bugs.python.org (Grant Jenks)
Date: Tue, 21 Aug 2018 17:19:30 +0000
Subject: [issue14841] os.get_terminal_size() should check stdin as a fallback
In-Reply-To: <1337275274.3.0.172049776796.issue14841@psf.upfronthosting.co.za>
Message-ID: <1534871970.26.0.56676864532.issue14841@psf.upfronthosting.co.za>


Grant Jenks <grant.jenks at gmail.com> added the comment:

I asked on the ncurses maintainers email list about their logic and was pointed to tty_settings.c which checks:

1. stderr
2. stdout
3. stdin
4. open('/dev/tty', 'r+')

I don't know a cross-platform way to check #4 but I think #1-3 are a reasonable change to shutil.get_terminal_size().

The current logic checks only stdout. I'd like to amend that to try stderr, stdout, and stdin after checking the COLUMNS and LINES env vars. So the new logic would be:

1. Check COLUMNS and LINES env vars (for overrides)
2. Check os.get_terminal_size(stderr)
3. Check os.get_terminal_size(stdout)
4. Check os.get_terminal_size(stdin)

----------
nosy: +grantjenks
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14841>
_______________________________________

From report at bugs.python.org  Tue Aug 21 13:32:32 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Aug 2018 17:32:32 +0000
Subject: [issue34417] imp.find_module reacts badly to iterator
In-Reply-To: <1534456304.96.0.56676864532.issue34417@psf.upfronthosting.co.za>
Message-ID: <1534872752.35.0.56676864532.issue34417@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Saying "the available functionality is massively inefficient" is unnecessarily hostile towards those of us who actually wrote and maintain that code. Without diving into the code, chances are that requirement is there so that the C code can use macros to access the list as efficiently as possible.

Now if you want to propose specific changes to importlib's code for it to work with iterables instead of just lists then we would be happy to review the pull request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34417>
_______________________________________

From report at bugs.python.org  Tue Aug 21 14:37:08 2018
From: report at bugs.python.org (Phillip M. Feldman)
Date: Tue, 21 Aug 2018 18:37:08 +0000
Subject: [issue34417] imp.find_module reacts badly to iterator
In-Reply-To: <1534872752.35.0.56676864532.issue34417@psf.upfronthosting.co.za>
Message-ID: <CAB2ViTZRObwYWR+8rhm5Ld5bcQSb7XLBUP-sFLgQug9fjRE5Hg@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

My apologies for the tone of my remark.  I am grateful to you and others
who donate their time to develop the code.

I'm attaching the wrapper code that I created to work around the problem.

Phillip

def expander(paths='./*'):
   """
   OVERVIEW

   This function is a generator, i.e., creates an iterator that recursively
   searches a list of folders in an incremental fashion.  This approach is
   advantageous when the folder tree(s) to be searched are large and the
item of
   interest is likely to be found early in the process.

   INPUTS

   `paths` must be either (a) a list of folder paths (each of which is a
string)
   or (b) a single string containing one or more folder paths separated by
the
   OS-specific path delimiter.

   Each path in `paths` must be either (a) an existing folder or (b) an
existing
   folder followed by '/*' or '\*'.  In case (a), the folder string is
copied
   from the input (`paths`) to the output result verbatim.  In case (b), the
   folder string is replaced by an expanded list that includes not only the
   base (the portion of the path that remains after the '/*' or '\*' has
been
   removed), but all subfolders as well.

   RETURN VALUES

   The returned value is an iterator.

   Invoking the `next` method of the iterator produces one folder path at a
   time.
   """

   if isinstance(paths, basestring):
      paths= paths.split(os.pathsep)

   elif not isinstance(paths, list):
      raise TypeError("`paths` must be either a string or a list of
strings.")

   found= set()

   for path in paths:
      if path.endswith('/*') or path.endswith('\*'):

         # A recursive search of subfolders is required:
         for item in os.walk(path[:-2]):
            base= os.path.abspath(item[0])
            new= [os.path.join(base, nested) for nested in item[1]]

            for item in new:
               if not item in found:
                  found.add(item)
                  yield item

      else:

         # No recursive search is required:
         if not item in found:
            found.add(item)
            yield item

   # end for path in paths

def find_module(module_name, in_folders=[]):
   """
   This function finds a module and return the fully-qualified file name.
   Folders from `in_folders`, if specified, are search first, followed by
   folders in the global `import_path` list.

   If any folder name in `in_folders` or `import_path` ends with an
asterisk,
   indicating that a recursive search is required, `files.expander` is
   invoked to create iterators that return one folder at a time, and
   `imp.find_module` is invoked separately for each of these folders.

   EXPLICIT INPUTS

   `module_name` is the unqualified name of the module to be found.

   `in_folders` is an optional list of additional folders to be searched
before
   the folders in `import_path` are searched.

   IMPLICIT INPUTS

   `import_path` is obtained from the global namespace.

   RETURN VALUES

   If `find_module` is able to find the requested module, it returns the
same
   three return values (`f`, `filename`, and `description`) that
   `imp.find_module` would return.
   """

   if isinstance(in_folders, basestring):
      in_folders= [in_folders]
   elif not isinstance(in_folders, list):
      raise TypeError("If specified, `in_folders` must be either a string
or a "
        "list of strings.  (A string is wrapped to produce a length-1
list).")

   if any([item.endswith('*') for item in in_folders ]) or \
      any([item.endswith('*') for item in import_path]):

      ex= None

      for folder in itertools.chain(
        expander(in_folders), expander(import_path)):
         try:
            return imp.find_module(module_name, in_folders + import_path)
         except Exception as ex:
            pass

      if ex:
         raise ex

   else:
      return imp.find_module(module_name, in_folders + import_path)

On Tue, Aug 21, 2018 at 10:32 AM Brett Cannon <report at bugs.python.org>
wrote:

>
> Brett Cannon <brett at python.org> added the comment:
>
> Saying "the available functionality is massively inefficient" is
> unnecessarily hostile towards those of us who actually wrote and maintain
> that code. Without diving into the code, chances are that requirement is
> there so that the C code can use macros to access the list as efficiently
> as possible.
>
> Now if you want to propose specific changes to importlib's code for it to
> work with iterables instead of just lists then we would be happy to review
> the pull request.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34417>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34417>
_______________________________________

From report at bugs.python.org  Tue Aug 21 14:50:18 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Tue, 21 Aug 2018 18:50:18 +0000
Subject: [issue34451] docs: tutorial/introduction doesn't mention toggle of
 prompts
Message-ID: <1534877418.64.0.56676864532.issue34451@psf.upfronthosting.co.za>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

Interactive code examples need the prompt to be stripped, before copy-and-paste. This is explained in https://docs.python.org/3/tutorial/introduction.html

But this page does not tell us about the [>>>] prompt-toggle at top of each interactive code example. This caused a user error, reported in  https://mail.python.org/pipermail/python-ideas/2018-August/052869.html.

The [>>>] toggle isn't in the Python 2.7 docs, so nothing to fix there!

----------
assignee: docs at python
components: Documentation
messages: 323839
nosy: docs at python, jfine2358
priority: normal
severity: normal
status: open
title: docs: tutorial/introduction doesn't mention toggle of prompts
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34451>
_______________________________________

From report at bugs.python.org  Tue Aug 21 15:01:13 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Tue, 21 Aug 2018 19:01:13 +0000
Subject: [issue34452] docs: help text for [>>>] toggle always in English
Message-ID: <1534878073.37.0.56676864532.issue34452@psf.upfronthosting.co.za>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

As subject. Background information in #34451.

See https://docs.python.org/fr/3/tutorial/introduction.html

The hover help text for the [>>>] is in English, not French. Korean and Japanese documentation has the same problem.

----------
assignee: docs at python
components: Documentation
messages: 323840
nosy: docs at python, jfine2358
priority: normal
severity: normal
status: open
title: docs: help text for [>>>] toggle always in English
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34452>
_______________________________________

From report at bugs.python.org  Tue Aug 21 15:23:02 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 21 Aug 2018 19:23:02 +0000
Subject: [issue34452] docs: help text for [>>>] toggle always in English
In-Reply-To: <1534878073.37.0.56676864532.issue34452@psf.upfronthosting.co.za>
Message-ID: <1534879382.78.0.56676864532.issue34452@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

The help text that says "Show the prompts and output" comes from python-docs-theme, and it is tracked in a separate repo: https://github.com/python/python-docs-theme/

Not sure if there's any customization that we can do here. I suggest raising the issue in python-docs-theme first.

----------
nosy: +Mariatta
resolution:  -> third party
stage:  -> resolved
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34452>
_______________________________________

From report at bugs.python.org  Tue Aug 21 15:23:11 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 21 Aug 2018 19:23:11 +0000
Subject: [issue34452] docs: help text for [>>>] toggle always in English
In-Reply-To: <1534878073.37.0.56676864532.issue34452@psf.upfronthosting.co.za>
Message-ID: <1534879391.81.0.56676864532.issue34452@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34452>
_______________________________________

From report at bugs.python.org  Tue Aug 21 15:51:39 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Tue, 21 Aug 2018 19:51:39 +0000
Subject: [issue34452] docs: help text for [>>>] toggle always in English
In-Reply-To: <1534878073.37.0.56676864532.issue34452@psf.upfronthosting.co.za>
Message-ID: <1534881099.74.0.56676864532.issue34452@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

Thank you. I've raised
"The help text for [>>>] toggle always in English"
https://github.com/python/python-docs-theme/issues/23

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34452>
_______________________________________

From report at bugs.python.org  Tue Aug 21 16:01:01 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 21 Aug 2018 20:01:01 +0000
Subject: [issue14841] os.get_terminal_size() should check stdin as a fallback
In-Reply-To: <1337275274.3.0.172049776796.issue14841@psf.upfronthosting.co.za>
Message-ID: <1534881661.17.0.56676864532.issue14841@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14841>
_______________________________________

From report at bugs.python.org  Tue Aug 21 16:22:58 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Tue, 21 Aug 2018 20:22:58 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
Message-ID: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>


New submission from Luke Kenneth Casson Leighton <lkcl at lkcl.net>:

adding some unit tests to some code being written,
searched randomly on the internet for an IPv6 test
suite and found one in php *shudder*
# https://github.com/gws/ipv6-address-test/blob/master/Tests/Ipv6TestCase.php

converted it to python, and was surprised to find that
there are two cases which the ipaddress.IPv6Address
module accepts, that it should not!

attached is a quick-and-dirty hacked together unit test
which shows the issue.  the full suite may be found
here (over 400 ipv6 addresses to test):

https://github.com/threefoldtech/jumpscale_core/blob/development_dynamic/tests/jumpscale_test/test10_j_data_types.py

----------
components: Tests
files: ipv6test.py
messages: 323843
nosy: lkcl
priority: normal
severity: normal
status: open
title: ipaddress module accepts some strange IPv6 addresses that it shouldn't
type: behavior
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47757/ipv6test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Tue Aug 21 17:38:29 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 21:38:29 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
Message-ID: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

A failure of PyUnicode_AsUTF8AndSize() in various fromisoformat() functions in Modules/_datetimemodule.c leads to NULL dereference due to the missing check, e.g.:

>>> from datetime import date
>>> date.fromisoformat('\ud800')
Segmentation fault (core dumped)

This is similar to msg123474. The missing NULL check was reported by Svace static analyzer.

While preparing tests for this issue, I've discovered a deeper problem. The C datetime implementation uses PyUnicode_AsUTF8AndSize() in several places, making some functions reject strings containing surrogate code points (0xD800 - 0xDFFF) since they can't be encoded in UTF-8. On the other hand, the pure-Python datetime implementation doesn't have this restriction. For example:

>>> import sys
>>> sys.modules['_datetime'] = None # block C implementation
>>> from datetime import time
>>> time().strftime('\ud800')
'\ud800'
>>> del sys.modules['datetime']
>>> del sys.modules['_datetime']
>>> from datetime import time
>>> time().strftime('\ud800')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 0: surrogates not allowed

My PR (coming soon) doesn't address this difference but focuses on fixing the immediate problem instead. Suggestions are appreciated.

----------
components: Extension Modules
messages: 323844
nosy: belopolsky, izbyshev, p-ganssle, serhiy.storchaka
priority: normal
severity: normal
status: open
title: datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Tue Aug 21 17:42:24 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 21:42:24 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534887744.05.0.56676864532.issue34454@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8322
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Tue Aug 21 17:57:59 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Aug 2018 21:57:59 +0000
Subject: [issue34446] ambiguous _max_size parameter in SpooledTemporaryFile
In-Reply-To: <1534794455.51.0.56676864532.issue34446@psf.upfronthosting.co.za>
Message-ID: <1534888679.66.0.56676864532.issue34446@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Do realize that anything which starts with an underscore, like _check, is considered a private API.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34446>
_______________________________________

From report at bugs.python.org  Tue Aug 21 18:05:29 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 21 Aug 2018 22:05:29 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534889129.36.0.56676864532.issue34454@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

So this is related to something I was actually meaning to fix. When I wrote this code I didn't understand the way PyUnicode works, there's actually no need to call `PyUnicode_AsUTF8AndSize()` on the entire unicode string.

My understanding is that each glyph in a given PyUnicode object is the same size, which means that this section of the code can go: https://github.com/python/cpython/blob/master/Modules/_datetimemodule.c#L4862

Instead we can just break the string up as glyphs 0-10 and 11+ and pass them on. Since by the contract of the function glyphs 0-10 and 11+ *must* be ASCII, we no longer need to worry about *valid* use cases where a character un-representable by UTF-8 will lead to anything except an error.

Obviously the null pointer error needs to be fixed since it should raise an error and not segfault.

I'd be happy to do the part where the string is broken up *before* being passed to PyUnicode_AsUTF8AndSize() if it would make it easier to implement your PR (which seems to touch a lot of other parts of the code as well).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Tue Aug 21 18:16:21 2018
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Aug 2018 22:16:21 +0000
Subject: [issue14841] os.get_terminal_size() should check stdin as a fallback
In-Reply-To: <1337275274.3.0.172049776796.issue14841@psf.upfronthosting.co.za>
Message-ID: <1534889781.27.0.56676864532.issue14841@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

The Windows implementation shouldn't map file-descriptor values 0, 1, and 2 to the process standard handles. fileno(stdout) may not even be 1 in some cases. It should use `handle = _get_osfhandle(fd)`, which is more generally correct and not limited to hard-coded defaults. 

Regarding this issue, the docs should clarify that the Windows console's input buffer cannot be used to get the screen buffer size. Typically the input buffer is STDIN_FILENO (0) or opened via  "CONIN$" or "CON" (read mode). Thus there is no point to checking stdin in Windows since it will always fail.

I agree that the default behavior should be extended to check a platform-dependent tty/console device. In Windows this is `fd = _open("CONOUT$", _O_RDWR)`.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14841>
_______________________________________

From report at bugs.python.org  Tue Aug 21 18:20:12 2018
From: report at bugs.python.org (iPodClassic)
Date: Tue, 21 Aug 2018 22:20:12 +0000
Subject: [issue34455] IDLE crashing when pressing Command + ^  (OSX)
Message-ID: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>


New submission from iPodClassic <marianogedisman at gmail.com>:

IDLE crashes when pressing Command (?) + ^ 

I have attached the crash report just in case.

----------
assignee: terry.reedy
components: IDLE
files: crash report idle.txt
messages: 323848
nosy: iPodClassic, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE crashing when pressing Command + ^  (OSX)
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file47758/crash report idle.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Tue Aug 21 18:34:32 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 22:34:32 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534890872.31.0.56676864532.issue34454@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I will be glad to rebase my PR and remove the try/except from the test if you remove the dependency of separator searching code on PyUnicode_AsUTF8AndSize() as you suggest. Or we can go the other way and merge mine first -- whatever you prefer.

Note that technically a difference between C and Python implementation of fromisoformat() will still remain: if a part of the input string before or after the separator contains surrogates, the C code will throw a UnicodeEncodeError while the Python code -- ValueError. But since the former error is a subclass of the latter, I guess it's OK, what do you think?

Also, note that the other discovered C/Python impl difference (for strftime, handled by another try/catch in tests) won't go away, of course, unless someone is ready to fix that as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Tue Aug 21 18:53:04 2018
From: report at bugs.python.org (jcc2220)
Date: Tue, 21 Aug 2018 22:53:04 +0000
Subject: [issue34446] ambiguous _max_size parameter in SpooledTemporaryFile
In-Reply-To: <1534794455.51.0.56676864532.issue34446@psf.upfronthosting.co.za>
Message-ID: <1534891984.44.0.56676864532.issue34446@psf.upfronthosting.co.za>


jcc2220 <jcc2220 at columbia.edu> added the comment:

Here's an example of the inconsistency - if SpooledTemporaryFile is instantiated with max_size set to 0, it will not rollover, EXCEPT when truncate method is called.  Both write and writelines (public methods) call _check, which deals with rollover, but _check will never rollover if max_size is set to 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34446>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:02:26 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Aug 2018 23:02:26 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1534892546.03.0.56676864532.issue34455@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe NSException crashes are due to interaction between tcl/tk and the Mac graphics subsystem, in this case for 10.11.6.

Did you install 3.7 with the python.org installer or something else?
How did you start IDLE and what state was it in when you hit command-^?

Neither of the default Mac key sets use Command-Key-^.  Did you create a custom keyset and bind it to something?

----------
assignee: terry.reedy -> 
components: +Tkinter, macOS -IDLE
nosy: +ned.deily, ronaldoussoren
title: IDLE crashing when pressing Command + ^  (OSX) -> Tkinter crashing when pressing Command + ^  (OSX)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:08:35 2018
From: report at bugs.python.org (iPodClassic)
Date: Tue, 21 Aug 2018 23:08:35 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534892546.03.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <593CC46D-2A07-4C86-A55B-B66271765CBE@gmail.com>


iPodClassic <marianogedisman at gmail.com> added the comment:

Hello Terry. I installed 3.7 from Python.org
First time it crashed,  I was playing around with some basic code (I?m learning), whilst trying to enter [ character (which is option + ^key in spanish keyboard), by mistake I pressed command (key next to option) and crashed IDLE.
Since I saw the crash report, I tried reproducing in in order to report the supposed bug.

Then I restarted IDLE from OSX Spotlight, and successfully crashed it using the same key combo several times.

I did not create any custom keyset, just happened by mistake.

Regards,

> El 21 ago 2018, a las 20:02 , Terry J. Reedy <report at bugs.python.org> escribi?:
> 
> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> I believe NSException crashes are due to interaction between tcl/tk and the Mac graphics subsystem, in this case for 10.11.6.
> 
> Did you install 3.7 with the python.org installer or something else?
> How did you start IDLE and what state was it in when you hit command-^?
> 
> Neither of the default Mac key sets use Command-Key-^.  Did you create a custom keyset and bind it to something?
> 
> ----------
> assignee: terry.reedy ->
> components: +Tkinter, macOS -IDLE
> nosy: +ned.deily, ronaldoussoren
> title: IDLE crashing when pressing Command + ^  (OSX) -> Tkinter crashing when pressing Command + ^  (OSX)
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34455>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:15:26 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 23:15:26 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
Message-ID: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of Py_BuildValue() is dereferenced without checking at https://github.com/python/cpython/blob/ef8861c112ed1dac9351958c121bc24ca4ecdb08/Modules/_pickle.c#L3457

Reported by Svace static analyzer.

----------
components: Extension Modules
messages: 323853
nosy: izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pickle: Missing NULL check in save_global()
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:17:10 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 23:17:10 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534893430.38.0.56676864532.issue34456@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8323
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:37:32 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 23:37:32 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
Message-ID: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyUnicode_InternFromString() is dereferenced without checking at https://github.com/python/cpython/blob/ef8861c112ed1dac9351958c121bc24ca4ecdb08/Python/ast.c#L3256

Reported by Svace static analyzer.

----------
components: Interpreter Core
messages: 323854
nosy: izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Missing NULL check in alias_for_import_name() from Python/ast.c
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:43:07 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 23:43:07 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534894987.49.0.56676864532.issue34457@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

The NULL dereference seems to be hard to trigger due to caching for one-character Latin-1 strings, but being safe probably won't hurt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Tue Aug 21 19:45:06 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 21 Aug 2018 23:45:06 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534895106.04.0.56676864532.issue34457@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8324
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Tue Aug 21 20:00:12 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 22 Aug 2018 00:00:12 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534896012.78.0.56676864532.issue34454@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Note that technically a difference between C and Python implementation of fromisoformat() will still remain: if a part of the input string before or after the separator contains surrogates, the C code will throw a UnicodeEncodeError while the Python code -- ValueError. But since the former error is a subclass of the latter, I guess it's OK, what do you think?

I think the fact that the unicode string is decoded is an implementation detail. I would suggest swallowing the decode error and raising a standard ValueError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Tue Aug 21 20:13:51 2018
From: report at bugs.python.org (Victor Porton)
Date: Wed, 22 Aug 2018 00:13:51 +0000
Subject: [issue34458] No way to alternate options
Message-ID: <1534896831.7.0.56676864532.issue34458@psf.upfronthosting.co.za>


New submission from Victor Porton <porton at narod.ru>:

I have:

parser.add_argument('-p', '--preload', help='preload asset', action='append', metavar='NAMESPACE')

I want also add:

parser.add_argument('-f', '--file', help='preload file', action='append', metavar='FILE', dest='preload')

This way I could specify -p and/or -f options in any order (like: first -p then -f then -p again) and store then in 'preload' field in the order which the user specified the options.

But I have no way to know if an option is -p or -f :-(

Please add something to argparse to solve this problem.

----------
components: Library (Lib)
messages: 323857
nosy: porton
priority: normal
severity: normal
status: open
title: No way to alternate options
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34458>
_______________________________________

From report at bugs.python.org  Tue Aug 21 21:35:46 2018
From: report at bugs.python.org (Carlo Rosati)
Date: Wed, 22 Aug 2018 01:35:46 +0000
Subject: [issue34410] Segfault/TimeoutError: itertools.tee of
 multiprocessing.pool.imap_unordered
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534901746.61.0.56676864532.issue34410@psf.upfronthosting.co.za>


Carlo Rosati <crosati777 at icloud.com> added the comment:

If what you've said is correct, would it make the most sense to create a Manager method which returns a Proxy to a tee'd iterator?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Tue Aug 21 23:21:19 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Aug 2018 03:21:19 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1534908079.55.0.56676864532.issue34455@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please download and run https://bugs.python.org/file47676/tk_scroll.py.  It is a very stripped-down version of an IDLE editor window.  After making a couple of edits, to make sure it is working, hit the fatal key combination.  Does it still crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Tue Aug 21 23:22:09 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Aug 2018 03:22:09 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1534908129.64.0.56676864532.issue34455@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PS, When replaying by email, please delete the quoted message, as it is redundant in the web page display.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Aug 22 00:51:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 04:51:30 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534913490.21.0.56676864532.issue34456@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f8c06b028036e50596e75d4c9f6b27ba05133efe by Serhiy Storchaka (Alexey Izbyshev) in branch 'master':
bpo-34456: pickle: Add missing NULL check to save_global(). (GH-8851)
https://github.com/python/cpython/commit/f8c06b028036e50596e75d4c9f6b27ba05133efe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 00:51:46 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 04:51:46 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534913506.38.0.56676864532.issue34456@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8325

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 00:51:54 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 04:51:54 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534913514.31.0.56676864532.issue34456@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8326

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 00:55:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 04:55:19 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534913719.41.0.56676864532.issue34457@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 28853a249b1d0c890b7e9ca345290bb8c1756446 by Serhiy Storchaka (Alexey Izbyshev) in branch 'master':
bpo-34457: Python/ast.c: Add missing NULL check to alias_for_import_name(). (GH-8852)
https://github.com/python/cpython/commit/28853a249b1d0c890b7e9ca345290bb8c1756446


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 00:55:26 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 04:55:26 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534913726.54.0.56676864532.issue34457@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8327

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 00:55:32 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 04:55:32 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534913732.55.0.56676864532.issue34457@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8328

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 01:54:21 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 05:54:21 +0000
Subject: [issue34400] Undefined behavior in Parser/parsetok.c
In-Reply-To: <1534240015.53.0.56676864532.issue34400@psf.upfronthosting.co.za>
Message-ID: <1534917261.79.0.56676864532.issue34400@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset eb9a1c01d07309006ef5544da62ba813685bd098 by Serhiy Storchaka (Zackery Spytz) in branch '2.7':
[2.7] bpo-34400: Fix more undefined behavior in parsetok.c (GH-8833). (GH-8849)
https://github.com/python/cpython/commit/eb9a1c01d07309006ef5544da62ba813685bd098


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34400>
_______________________________________

From report at bugs.python.org  Wed Aug 22 01:54:36 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 05:54:36 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534917276.29.0.56676864532.issue34456@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3152bc36fd1a8ab349d6802e9b48dd88a35b3620 by Miss Islington (bot) in branch '3.7':
bpo-34456: pickle: Add missing NULL check to save_global(). (GH-8851)
https://github.com/python/cpython/commit/3152bc36fd1a8ab349d6802e9b48dd88a35b3620


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 01:54:41 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 05:54:41 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534917281.91.0.56676864532.issue34456@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b14a68fd7d8f02bd133b59709f969c1c564f5978 by Miss Islington (bot) in branch '3.6':
bpo-34456: pickle: Add missing NULL check to save_global(). (GH-8851)
https://github.com/python/cpython/commit/b14a68fd7d8f02bd133b59709f969c1c564f5978


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 01:54:48 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 05:54:48 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534917288.99.0.56676864532.issue34457@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b8e7319d39bf44355bf60f9bbec07cfbbe56739d by Miss Islington (bot) in branch '3.7':
bpo-34457: Python/ast.c: Add missing NULL check to alias_for_import_name(). (GH-8852)
https://github.com/python/cpython/commit/b8e7319d39bf44355bf60f9bbec07cfbbe56739d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 01:54:57 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Aug 2018 05:54:57 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534917297.71.0.56676864532.issue34457@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0ef61ee7b194a1c15747d6bca3cf30a5c581e7e3 by Miss Islington (bot) in branch '3.6':
bpo-34457: Python/ast.c: Add missing NULL check to alias_for_import_name(). (GH-8852)
https://github.com/python/cpython/commit/0ef61ee7b194a1c15747d6bca3cf30a5c581e7e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 03:34:57 2018
From: report at bugs.python.org (iMath)
Date: Wed, 22 Aug 2018 07:34:57 +0000
Subject: [issue34450] improve  shutil.make_archive
In-Reply-To: <1534849136.61.0.56676864532.issue34450@psf.upfronthosting.co.za>
Message-ID: <1534923297.0.0.56676864532.issue34450@psf.upfronthosting.co.za>


iMath <redstone-cold at 163.com> added the comment:

one workaround is :
if os.path.join(root_dir, base_dir) exists, use the current implementation , this is set for backwards-compatibility, if not exist, please consider the feature in my last post(maybe we should recommend Python  users to follow this approach in the doc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34450>
_______________________________________

From report at bugs.python.org  Wed Aug 22 05:00:20 2018
From: report at bugs.python.org (era)
Date: Wed, 22 Aug 2018 09:00:20 +0000
Subject: [issue34459] email.contentmanager should use IANA encoding
Message-ID: <1534928420.28.0.56676864532.issue34459@psf.upfronthosting.co.za>


New submission from era <era+python at iki.fi>:

https://github.com/python/cpython/blob/3.7/Lib/email/contentmanager.py#L64 currently contains the following code:

    def get_text_content(msg, errors='replace'):
        content = msg.get_payload(decode=True)
        charset = msg.get_param('charset', 'ASCII')
        return content.decode(charset, errors=errors)

This breaks when the IANA character set is not identical to the Python encoding name. For example, pass it a message with

    Content-type: text/plain; charset=cp-850

This breaks for two separate reasons (and I will report two separate bugs); the IANA character-set label should be looked up and converted to a Python codec name (that's this bug) and the character-set alias 'cp-850' is not defined in the lookup table in the place.

There are probably other places in contentmanager.py where a similar mapping should take place. 

I do not have a proper patch, but in general outline, the fix would look like

+    import email.charset
+
     def get_text_content(msg, errors='replace'):
        content = msg.get_payload(decode=True)
        charset = msg.get_param('charset', 'ASCII')
-       return content.decode(charset, errors=errors)
+       encoding = Charset(charset).output_charset()
+       return content.decode(encoding, errors=errors)

This was discovered in this Stack Overflow post: https://stackoverflow.com/a/51961225/874188

----------
components: email
messages: 323869
nosy: barry, era, r.david.murray
priority: normal
severity: normal
status: open
title: email.contentmanager should use IANA encoding
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34459>
_______________________________________

From report at bugs.python.org  Wed Aug 22 05:17:06 2018
From: report at bugs.python.org (era)
Date: Wed, 22 Aug 2018 09:17:06 +0000
Subject: [issue34460] email.charset: common IANA labels missing
Message-ID: <1534929426.63.0.56676864532.issue34460@psf.upfronthosting.co.za>


New submission from era <era+python at iki.fi>:

The email.charset module should contain common informal character-set identifiers even if they are not formally specified in a IANA RFC.

>From a quick grep of a pile of recent email, I find the following:

   46 "cp-850"
    6 "windows-874"

For scale, the same collection contained around 10,000 messages with "utf-8" and 2,000 with "iso-8859-1".  Still, the fact that there are multiple occurrences in a spool of recent messages indicates that they are fairly common.

Currently, the email module throws a traceback if you attempt to parse a message whose character set is not known to Python. This is not possible to prevent in the general case, but making it more robust with encodings which are reasonably prevalent in the wild would definitely be desirable.  

For what it's worth, "cp-850" is apparently an alias for IBM code page 850 which is defined with the name "cp850" in RFC1345.  "windows-874" is an official designation which is detailed in https://www.iana.org/assignments/charset-reg/windows-874 which is apparently equivalent to the Python codec "cp784".

----------
components: email
messages: 323870
nosy: barry, era, r.david.murray
priority: normal
severity: normal
status: open
title: email.charset: common IANA labels missing
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34460>
_______________________________________

From report at bugs.python.org  Wed Aug 22 05:18:02 2018
From: report at bugs.python.org (era)
Date: Wed, 22 Aug 2018 09:18:02 +0000
Subject: [issue34459] email.contentmanager should use IANA encoding
In-Reply-To: <1534928420.28.0.56676864532.issue34459@psf.upfronthosting.co.za>
Message-ID: <1534929482.05.0.56676864532.issue34459@psf.upfronthosting.co.za>


era <era+python at iki.fi> added the comment:

https://bugs.python.org/issue34460 now requests the addition of "cp-850" and "windows-784" as charset aliases in the email.charset module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34459>
_______________________________________

From report at bugs.python.org  Wed Aug 22 05:42:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Aug 2018 09:42:38 +0000
Subject: [issue5999] compile error on HP-UX 11.22 ia64 - 'mbstate_t' is
 used	as a type, but has not been defined as a type
In-Reply-To: <1242077074.29.0.376465629361.issue5999@psf.upfronthosting.co.za>
Message-ID: <1534930958.15.0.56676864532.issue5999@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5999>
_______________________________________

From report at bugs.python.org  Wed Aug 22 06:41:28 2018
From: report at bugs.python.org (nilanjan roy)
Date: Wed, 22 Aug 2018 10:41:28 +0000
Subject: [issue34461] Availability of parsers in etree initializer
Message-ID: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>


New submission from nilanjan roy <roy.nilanjan at gmail.com>:

As xml package make the availability of separate global name-space by *__all__* so considerably *etree* should have included of all the parser files in its initialize(i.e. in *__init__.py*). 

So if any script consider as "from xml import *" then *etree* should have accessibility on all of it's parser files i.e. etree should access like *etree.ElementTree* which is not working as expected currently. Currently it's enforced to use as normal behavior as "import xml.etree.ElementTree"

----------
components: XML
messages: 323872
nosy: nilanjan roy
priority: normal
severity: normal
status: open
title: Availability of parsers in etree initializer
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34461>
_______________________________________

From report at bugs.python.org  Wed Aug 22 07:23:56 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 22 Aug 2018 11:23:56 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534937036.29.0.56676864532.issue34457@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
pull_requests: +8329

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 07:32:52 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 22 Aug 2018 11:32:52 +0000
Subject: [issue34393] json.dumps - allow compression
In-Reply-To: <1534160063.78.0.56676864532.issue34393@psf.upfronthosting.co.za>
Message-ID: <1534937572.89.0.56676864532.issue34393@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not asking to be difficult, I'm asking because a full specification would be required in order to implement this.

For example, you're excluding the "compresslevel" parameter, so presumably you'd want the default of 9, which is the slowest option. I'm not sure this is a good idea. Shouldn't the caller be able to specify this? If not, why not?

In any event, I think the best thing to do is to let the caller use any compression they want, and allow them full control over the compression parameters.

Unless, of course, there's any documented standard for json compression (even a de facto standard would be interesting to know about).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34393>
_______________________________________

From report at bugs.python.org  Wed Aug 22 07:46:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 11:46:55 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534938415.45.0.56676864532.issue34457@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5223ce2131a121201a78d0680302ea06c4a58369 by Serhiy Storchaka (Alexey Izbyshev) in branch '2.7':
[2.7] bpo-34457: Python/ast.c: Add missing NULL check to alias_for_import_name(). (GH-8852) (GH-8858)
https://github.com/python/cpython/commit/5223ce2131a121201a78d0680302ea06c4a58369


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 07:47:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 11:47:23 +0000
Subject: [issue34457] Missing NULL check in alias_for_import_name() from
 Python/ast.c
In-Reply-To: <1534894652.28.0.56676864532.issue34457@psf.upfronthosting.co.za>
Message-ID: <1534938443.59.0.56676864532.issue34457@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34457>
_______________________________________

From report at bugs.python.org  Wed Aug 22 08:11:16 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Aug 2018 12:11:16 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1534939876.28.0.56676864532.issue34461@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8330
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34461>
_______________________________________

From report at bugs.python.org  Wed Aug 22 08:17:16 2018
From: report at bugs.python.org (Tal Einat)
Date: Wed, 22 Aug 2018 12:17:16 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534940236.96.0.56676864532.issue34454@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8331

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Wed Aug 22 08:21:25 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 12:21:25 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534940485.33.0.56676864532.issue34454@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I agree, that raising UnicodeEncodeError instead of ValueError is acceptable, since the former is a subclass of the latter. But since the default implementation raises more specialized subclass, it is probably that the user code will catch more narrow exception type. Seems, it is not hard to make the same exception be raised in all cases. For example, in date_fromisoformat():

    if (!dt_ptr || len != 10
        || parse_isoformat_date(dt_ptr, &year, &month, &day) < 0)
    {
        PyErr_Format(PyExc_ValueError, "Invalid isoformat string: %R", dstr);
        return NULL;
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Wed Aug 22 08:37:16 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 22 Aug 2018 12:37:16 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534941436.3.0.56676864532.issue34456@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 08:58:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Aug 2018 12:58:00 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534942680.96.0.56676864532.issue34456@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is 2.7 affected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 09:09:37 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Aug 2018 13:09:37 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1534943377.97.0.56676864532.issue34461@psf.upfronthosting.co.za>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34461>
_______________________________________

From report at bugs.python.org  Wed Aug 22 09:17:26 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 22 Aug 2018 13:17:26 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1534943846.73.0.56676864532.issue34456@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

No, I couldn't find any similar calls in save_global() in 2.7.

However, there is Py_BuildValue() call in initcPickle(), and its result is passed unchecked to PyDict_SetItemString(), where it's eventually dereferenced. In fact, all PyDict_SetItemString() calls in initcPickle() are made without checking for NULL. Should I file an issue for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Wed Aug 22 09:26:06 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 22 Aug 2018 13:26:06 +0000
Subject: [issue31436]
 test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails due
 to sendfile completing before timeout
In-Reply-To: <1505255563.72.0.314933914484.issue31436@psf.upfronthosting.co.za>
Message-ID: <1534944366.96.0.56676864532.issue31436@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I'm having the same issue on my devserver at work. I think we need to re-evaluate how those timeouts are working. This is flaky testing.

----------
nosy: +lukasz.langa
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31436>
_______________________________________

From report at bugs.python.org  Wed Aug 22 09:26:18 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 22 Aug 2018 13:26:18 +0000
Subject: [issue31436]
 test_socket.SendfileUsingSendfileTest.testWithTimeoutTriggeredSend fails due
 to sendfile completing before timeout
In-Reply-To: <1505255563.72.0.314933914484.issue31436@psf.upfronthosting.co.za>
Message-ID: <1534944378.91.0.56676864532.issue31436@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31436>
_______________________________________

From report at bugs.python.org  Wed Aug 22 09:39:13 2018
From: report at bugs.python.org (iPodClassic)
Date: Wed, 22 Aug 2018 13:39:13 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534908079.55.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <059B57B6-086B-4B0A-9886-B9B478E0F847@gmail.com>


iPodClassic <marianogedisman at gmail.com> added the comment:

Noted the issue with the email replies, sorry!

Do you want me to place the file in any folder in particular? Remember I?m a noob at this.  I placed it in the Python app folder, ran the script, played around with IDLE and I can still crash it using command + ^ .  Maybe it?s not a bug after all and a problem with OSX?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Aug 22 09:50:31 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Aug 2018 13:50:31 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1534945831.74.0.56676864532.issue34207@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Nothing has changed recently in the PEP 538 implementation itself, and both those builders were green last month:

* https://buildbot.python.org/all/#/builders/60/builds/181
* https://buildbot.python.org/all/#/builders/79/builds/185

The first failing debug build was https://buildbot.python.org/all/#/builders/60/builds/182 which rearranged some parts of the startup sequence: https://github.com/python/cpython/commit/d19d8d5279f156bc8f6736b5f16f069879b9519b

Similarly, the 3.7 builds started failing in https://buildbot.python.org/all/#/builders/124/builds/489, which made Py_Initialize work more closely to the way it worked in Python 3.6: https://github.com/python/cpython/commit/0c90d6f75931da4fec84d06c2efe9dd94bb96b77

So given the output reported in the current build failures, my guess would be that something has gotten out of sequence in the code that has to handle re-encoding and decoding command line values and environment variables that have initially been decoded incorrectly (i.e. as surrogate escaped ASCII).

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Wed Aug 22 10:04:49 2018
From: report at bugs.python.org (Anjali Bansal)
Date: Wed, 22 Aug 2018 14:04:49 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
In-Reply-To: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>
Message-ID: <1534946689.87.0.56676864532.issue33187@psf.upfronthosting.co.za>


Change by Anjali Bansal <anjali.mca17.du at gmail.com>:


----------
keywords: +patch
pull_requests: +8332
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Wed Aug 22 10:10:08 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 22 Aug 2018 14:10:08 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534947008.8.0.56676864532.issue34410@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Carlo: The point of Xiang's post is that this is only tangentially related to multiprocessing; the real problem is that tee-ing an iterator implemented in Python (of which pool.imap_unordered is just one example) and using the resulting tee-ed iterators in multiple threads (which pool.imap_unordered does implicitly, as there is a thread involved in dispatching work).

The problem is *exposed* by multiprocessing.pool.imap_unordered, but it entirely a problem with itertools.tee, and as Xiang's repro indicates, it can be triggered easily without the complexity of multiprocessing being involved.

I've updated the bug title to reflect this.

----------
components: +Library (Lib)
nosy: +josh.r
title: Segfault/TimeoutError: itertools.tee of multiprocessing.pool.imap_unordered -> itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Wed Aug 22 10:18:18 2018
From: report at bugs.python.org (Anjali Bansal)
Date: Wed, 22 Aug 2018 14:18:18 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
In-Reply-To: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>
Message-ID: <1534947498.79.0.56676864532.issue33187@psf.upfronthosting.co.za>


Anjali Bansal <anjali.mca17.du at gmail.com> added the comment:

Hello, 

I had created the PR for this issue. Please review and let me know if any modification required.

GitHub PR: https://github.com/python/cpython/pull/8861

bpo-33187: Fix document ElementInclude (XInclude) support in ElementTree issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Wed Aug 22 10:21:24 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Aug 2018 14:21:24 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1534947684.91.0.56676864532.issue34455@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

FWIW I can reproduce the problem with IDLE and tk_scroll.py:

1) Add a spanish keyboard layout in System Preferences (my normal layout is US International, matching the text on the keyboard)

2) Select this keyboard using the keyboard menu item

3) Type CMD-^ by pressing "CMD+SHIFT+[" (that is, at the same time press the keys CMD, SHIFT and the key where [ is on the keycap). 

With tk_scroll.py the following output is shown in the terminal:

2018-08-22 16:12:22.231 Python[51578:13988425] -[TKMenu submenuAction:]: unrecognized selector sent to instance 0x7fe078f56270
2018-08-22 16:12:22.315 Python[51578:13988425] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[TKMenu submenuAction:]: unrecognized selector sent to instance 0x7fe078f56270'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff30e8a2db __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fff58034c76 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff30f22db4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132
	3   CoreFoundation                      0x00007fff30e00820 ___forwarding___ + 1456
	4   CoreFoundation                      0x00007fff30e001e8 _CF_forwarding_prep_0 + 120
	5   AppKit                              0x00007fff2eb37a43 -[NSApplication(NSResponder) sendAction:to:from:] + 312
	6   AppKit                              0x00007fff2e82c1bb -[NSCarbonMenuImpl performMenuAction:withTarget:] + 155
	7   AppKit                              0x00007fff2e5cb232 -[NSMenu _performKeyEquivalentWithDelegate:] + 361
	8   AppKit                              0x00007fff2e5cacd8 -[NSMenu performKeyEquivalent:] + 68
	9   AppKit                              0x00007fff2eb366a9 routeKeyEquivalent + 884
	10  AppKit                              0x00007fff2eb33ce0 -[NSApplication(NSEvent) sendEvent:] + 1096
	11  libtk8.6.dylib                      0x0000000108e7f3ee -[TKApplication(TKNotify) sendEvent:] + 39
	12  libtk8.6.dylib                      0x0000000108e7f787 TkMacOSXEventsCheckProc + 434
	13  libtcl8.6.dylib                     0x0000000108d16d06 Tcl_DoOneEvent + 316
	14  _tkinter.cpython-37m-darwin.so      0x0000000108c4701d _tkinter_tkapp_mainloop + 269
	15  Python                              0x000000010865884e _PyMethodDef_RawFastCallKeywords + 430
	16  Python                              0x000000010865e462 _PyMethodDescr_FastCallKeywords + 82
	17  Python                              0x00000001087175e0 call_function + 832
	18  Python                              0x0000000108714546 _PyEval_EvalFrameDefault + 25126
	19  Python                              0x0000000108718096 _PyEval_EvalCodeWithName + 2422
	20  Python                              0x0000000108657d81 _PyFunction_FastCallKeywords + 257
	21  Python                              0x00000001087175bb call_function + 795
	22  Python                              0x0000000108714560 _PyEval_EvalFrameDefault + 25152
	23  Python                              0x0000000108718096 _PyEval_EvalCodeWithName + 2422
	24  Python                              0x000000010870e244 PyEval_EvalCode + 100
	25  Python                              0x000000010874b041 PyRun_FileExFlags + 209
	26  Python                              0x000000010874a8eb PyRun_SimpleFileExFlags + 859
	27  Python                              0x000000010876893c pymain_main + 8044
	28  Python                              0x0000000108768da1 _Py_UnixMain + 129
	29  libdyld.dylib                       0x00007fff58c4e015 start + 1
	30  ???                                 0x0000000000000002 0x0 + 2
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

I haven't (and won't) further investigated this problem, but at least this should help reproduce the problem.  Its likely a Tk problem, but maybe it is possible to tweak IDLE or Tkinter to avoid a crash. 

P.S. The crash does not happen with a US keyboard layout. 

P.P.S. SHIFT+[ appears to be how you enter "^" on a spanish keyboard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Aug 22 10:28:21 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 22 Aug 2018 14:28:21 +0000
Subject: [issue34425] :s formatting broken for objects without __format__
In-Reply-To: <1534551536.12.0.56676864532.issue34425@psf.upfronthosting.co.za>
Message-ID: <1534948101.92.0.56676864532.issue34425@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

About translating ":s" to "":

> The library seems
willing to do this for the empty format string, but not when the client
code specifically asks for a string....

You're not asking for a string when you specify ":s". You're asking the object to interpret "s" however it wants. For example, if the object is a datetime, you're asking for the output to be "s":

>>> f'{datetime.datetime.now():s}'
's'

versus:

>>> f'{datetime.datetime.now()}'
'2018-08-22 10:27:25.188891'

It's precisely because we want to let the object interpret the string that Python no longer guesses as to what you might mean.

For example, say you have a MyDate object, that doesn't support __format__, and you want Python to decide that format(MyDate(), 's') means is the same as format(MyDate(), ''). But later you decide that you want the format strings to call strftime (like datetime does). You couldn't do that without breaking existing usage of your library.

This actually happened with complex when I added complex.__format__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34425>
_______________________________________

From report at bugs.python.org  Wed Aug 22 10:57:21 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 22 Aug 2018 14:57:21 +0000
Subject: [issue34458] No way to alternate options
In-Reply-To: <1534896831.7.0.56676864532.issue34458@psf.upfronthosting.co.za>
Message-ID: <1534949841.16.0.56676864532.issue34458@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

That's a *really* niche use case; you want to store everything to a common destination list, in order, but distinguish which switch added each one? I don't know of any programs that use such a design outside of Python (and therefore, it seems unlikely there would be enough demand from argparse users to justify the development, maintenance, and complexity cost of adding it).

argparse does support defining custom Actions, so it's wholly possible to add this sort of support for yourself if there isn't enough demand to add it to argparse itself. For example, a simple implementation would be:

class AppendWithSwitchAction(argparse.Action):
    def __init__(self, option_strings, dest, *args, **kwargs):
        super().__init__(option_strings, dest, *args, **kwargs)
        # Map all possible switches to the final switch provided
        # so we store a consistent switch name
        self.option_map = dict.fromkeys(option_strings, option_strings[-1])

    def __call__(self, parser, namespace, values, option_string=None):
        option = self.option_map.get(option_string)
        try:
            getattr(namespace, self.dest).append((option, value))
        except AttributeError:
            setattr(namespace, self.dest, [(option, value)])

then use it with:

parser.add_argument('-p', '--preload', help='preload asset', action=AppendWithSwitchAction, metavar='NAMESPACE')

parser.add_argument('-f', '--file', help='preload file', action=AppendWithSwitchAction, metavar='FILE', dest='preload')

All that does is append ('--preload', argument) or ('--file', argument) instead of just appending the argument, so you can distinguish one from the other (for switch, arg in args.preload:, then test if switch=='--preload' or '--file'). It's bare bones (the actual class underlying the 'append' action ensures nargs isn't 0, and that if const is provided, nargs is '?'), but it would serve.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34458>
_______________________________________

From report at bugs.python.org  Wed Aug 22 11:17:40 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 22 Aug 2018 15:17:40 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534951060.41.0.56676864532.issue34434@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Bloating the documentation is almost certainly unjustifiable for list and tuple, and only barely justifiable for int, bool and float, given that:

1. The documentation (at least for Python 3) has *never* claimed the arguments could be passed by keyword (all of them used brackets to indicate the argument was optional without implying a meaningful default, which is typically how "does not take arguments by keyword" was described before the current "/" convention)

and

2. Aside from bool and float (and to a lesser extent, int), the documented name of said parameter didn't match the name it was accepted under, e.g.:

   a. The docs for tuple and list claimed the name was "iterable"; the only accepted name was "sequence"
   b. The online docs for int gave a wholly invalid "name", calling it "number | string", when in fact it was accepted only as "x". That said, int's docstring does describe the name "correctly" as "x"

So for tuple/list it would have been impossible to write code that depended on being able to pass the first parameter by keyword unless you'd gone mucking about in the CPython source code to figure out the secret keyword name. I could justify a note for int/bool/float given that the docstrings for all of them named the argument, and bool/float named it in the online docs, but we don't need to document a change that no one could have taken a dependency on without going to extreme trouble.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Wed Aug 22 11:34:33 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 22 Aug 2018 15:34:33 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534952073.48.0.56676864532.issue34434@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Oh, I was checking old docs when I said the online docs didn't call int's argument "x"; the current docs do, so int, float and bool all justify a change (barely), it's just tuple and list for which it's completely unjustifiable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Wed Aug 22 11:44:49 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 22 Aug 2018 15:44:49 +0000
Subject: [issue34425] :s formatting broken for objects without __format__
In-Reply-To: <1534551536.12.0.56676864532.issue34425@psf.upfronthosting.co.za>
Message-ID: <1534952689.04.0.56676864532.issue34425@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Forgot to add: I haven't looked at the docs yet, but I agree they should be clear on this issue.

The docs should say: for types that implement the documented mini-language, "s" is the same as "". It's just that not all types implement the mini-language (like datetime, and probably many non-standard, user-defined types).

If they don't say that, can you open a separate documentation issue? Thanks.

Or, maybe the problem is that the docs make it seem like all types do (or should?) implement the mini-language? That's definitely not true, and they shouldn't say that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34425>
_______________________________________

From report at bugs.python.org  Wed Aug 22 12:15:22 2018
From: report at bugs.python.org (paul j3)
Date: Wed, 22 Aug 2018 16:15:22 +0000
Subject: [issue34458] No way to alternate options
In-Reply-To: <1534896831.7.0.56676864532.issue34458@psf.upfronthosting.co.za>
Message-ID: <1534954522.55.0.56676864532.issue34458@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

I agree that a custom Action subclass like this is the way to go.

The regular 'append' is implemented in _AppendAction class, which is different from the default _StoreAction.  So even if there was enough demand for this new idea to be put into development, it would be implemented as subclass (along with a registry entry).

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34458>
_______________________________________

From report at bugs.python.org  Wed Aug 22 12:20:54 2018
From: report at bugs.python.org (iPodClassic)
Date: Wed, 22 Aug 2018 16:20:54 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534947684.91.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <44F528F9-B0EA-471A-AED7-6DD192E264E5@gmail.com>


iPodClassic <marianogedisman at gmail.com> added the comment:

Thanks for the more detailed and further explanation. So we at least know it?s bound to spanish keyboards only.  I wouldn?t even call it a bothersome bug except the key combo you press is very similar to when you try to enter a [ key (option+^) ; so you end up losing all code by mistake, when trying to enter an often used character on IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Aug 22 12:31:27 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 22 Aug 2018 16:31:27 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1534955487.67.0.56676864532.issue34454@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
pull_requests: +8336

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Wed Aug 22 12:50:23 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Aug 2018 16:50:23 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534956623.13.0.56676864532.issue34434@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Please don't use over-the-top language like "completely unjustifiable" because it is unnecessary and in this case wrong. We treat our documentation as a recording of the semantics of the stdlib as well as a recording of what semantic changes occurred between versions. Something did change semantically and so it should be documented. Whether the way the docs have previously been written would have suggested that someone accidentally used keyword arguments is not the critical point. Anyone could have looked at e.g. help() or simply stumbled upon the fact keyword arguments used to work and then suddenly discovered they didn't. At that point it's more helpful to the user to know when that changed occurred then to try and minimize the amount of text in the  docs simply because they happened to have not been written to suggest keyword arguments worked when they, in fact, did.

IOW adding a "version changed" note is not bloat, it's about letting people know who happened to have used keyword arguments what version of Python is going to break their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Wed Aug 22 13:37:36 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Wed, 22 Aug 2018 17:37:36 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1534959456.46.0.56676864532.issue34453@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

Hi Ikcl, are you working on the fix? I'd like to work on it.

----------
nosy: +prudvinit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Wed Aug 22 13:43:23 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Wed, 22 Aug 2018 17:43:23 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1534959803.78.0.56676864532.issue34453@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> Hi lkcl, are you working on the fix? I'd like to work on it.

hi prudvi, i'm not: i'm simply making people aware that there's
an issue that needs to be addressed (pun intended)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Wed Aug 22 13:52:44 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 22 Aug 2018 17:52:44 +0000
Subject: [issue34462] _xxsubinterpreters: Wrong NULL check in
 _copy_raw_string()
Message-ID: <1534960364.06.0.56676864532.issue34462@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The code at https://github.com/python/cpython/blob/28853a249b1d0c890b7e9ca345290bb8c1756446/Modules/_xxsubinterpretersmodule.c#L18 checks a wrong variable for NULL:

    const char *str = PyUnicode_AsUTF8(strobj);
    if (str == NULL) {
        return NULL;
    }
    char *copied = PyMem_Malloc(strlen(str)+1);
    if (str == NULL) {
        PyErr_NoMemory();
        return NULL;
    }

Reported by Svace static analyzer.

----------
components: Extension Modules
messages: 323897
nosy: eric.snow, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _xxsubinterpreters: Wrong NULL check in _copy_raw_string()
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34462>
_______________________________________

From report at bugs.python.org  Wed Aug 22 13:55:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 22 Aug 2018 17:55:49 +0000
Subject: [issue34462] _xxsubinterpreters: Wrong NULL check in
 _copy_raw_string()
In-Reply-To: <1534960364.06.0.56676864532.issue34462@psf.upfronthosting.co.za>
Message-ID: <1534960549.24.0.56676864532.issue34462@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8337
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34462>
_______________________________________

From report at bugs.python.org  Wed Aug 22 14:21:16 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Aug 2018 18:21:16 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1534962076.76.0.56676864532.issue2122@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e7d4b2f205c711d056bea73a0093e2e2b200544b by Berker Peksag in branch 'master':
bpo-2122: Make mmap.flush() behave same on all platforms (GH-8692)
https://github.com/python/cpython/commit/e7d4b2f205c711d056bea73a0093e2e2b200544b


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Wed Aug 22 14:22:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Aug 2018 18:22:51 +0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1534962171.77.0.56676864532.issue2122@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the suggestions and for the reviews!

----------
assignee: brian.curtin -> 
priority: high -> normal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2122>
_______________________________________

From report at bugs.python.org  Wed Aug 22 14:27:35 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Aug 2018 18:27:35 +0000
Subject: [issue34462] _xxsubinterpreters: Wrong NULL check in
 _copy_raw_string()
In-Reply-To: <1534960364.06.0.56676864532.issue34462@psf.upfronthosting.co.za>
Message-ID: <1534962455.92.0.56676864532.issue34462@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset c583919ffced0a3b6409766fc12f6e28bef4fac7 by Berker Peksag (Alexey Izbyshev) in branch 'master':
bpo-34462: Add missing NULL check to _copy_raw_string() (GH-8863)
https://github.com/python/cpython/commit/c583919ffced0a3b6409766fc12f6e28bef4fac7


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34462>
_______________________________________

From report at bugs.python.org  Wed Aug 22 14:28:06 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Aug 2018 18:28:06 +0000
Subject: [issue34462] _xxsubinterpreters: Wrong NULL check in
 _copy_raw_string()
In-Reply-To: <1534960364.06.0.56676864532.issue34462@psf.upfronthosting.co.za>
Message-ID: <1534962486.39.0.56676864532.issue34462@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34462>
_______________________________________

From report at bugs.python.org  Wed Aug 22 14:59:45 2018
From: report at bugs.python.org (Kurt Roeckx)
Date: Wed, 22 Aug 2018 18:59:45 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1534964385.43.0.56676864532.issue32947@psf.upfronthosting.co.za>


Kurt Roeckx <kurt at roeckx.be> added the comment:

This are the errors I'm currently getting testing with the pre9 verion in Debian:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python2.7/865936/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.6/865937/log.gz
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python3.7/865938/log.gz

----------
nosy: +kroeckx

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:01:06 2018
From: report at bugs.python.org (Timothy McCurrach)
Date: Wed, 22 Aug 2018 19:01:06 +0000
Subject: [issue34463] Discrepancy between traceback.print_exception and
 sys.__excepthook__
Message-ID: <1534964466.61.0.56676864532.issue34463@psf.upfronthosting.co.za>


New submission from Timothy McCurrach <tim.mccurrach at gmail.com>:

If you have set sys.excepthook to some function which calls traceback.print_exception, then I would expect to get identical traceback/exception messages. If you run raise SyntaxError("some message"), then print_exception has the extra line `File "<string>", line None`. 

This comes from lines 558-561 of traceback.py:

# It was a syntax error; show exactly where the problem was found.
filename = self.filename or "<string>"
lineno = str(self.lineno) or '?'
yield '  File "{}", line {}\n'.format(filename, lineno)

Is it expected behaviour that these two functions behave differently, or should there be something like:
if self.filename or self.lineno:
    etc.

Also, if self.lineno is None, then str(self.lineno) evaluates to "None" and so the ? is never used.

----------
components: Demos and Tools
messages: 323902
nosy: Timothy McCurrach
priority: normal
severity: normal
status: open
title: Discrepancy between traceback.print_exception and sys.__excepthook__
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34463>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:07:54 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 22 Aug 2018 19:07:54 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1534964874.18.0.56676864532.issue32947@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Kurt, can you try again with a current git checkout from master? I fixed a couple of issues lately. CPython master passes all tests with vanilla OpenSSL 1.1.1-pre9. Does Debian change some default settings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:08:50 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 22 Aug 2018 19:08:50 +0000
Subject: [issue34464] docs: keywords are special - eg constants.html
Message-ID: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

The identifiers True, False, None and __debug__ are keywords in the language.  For example
>>> __debug__ = __debug__
SyntaxError: assignment to keyword


1. The page constants.html incorrectly says then are in the built-in namespace. Some of them were, once.

2. The list keyword.kwlist does not contain __debug__. (Problem in Lib/keyword.py.)

3. https://docs.python.org/3/reference/datamodel.html for None, NotImplemented, etc.

4. There may be other places that need looking at.

See also: https://github.com/jfine2358/py-jfine2358/blob/master/docs/none-is-special.md

Credit: The __debug__ problem arises from Steve D'Aprano's message

https://mail.python.org/pipermail/python-ideas/2018-August/052917.html
The std lib contains a test that this correctly raises SyntaxError:
def f(*, x=lambda __debug__:0): pass

----------
assignee: docs at python
components: Documentation
messages: 323904
nosy: docs at python, jfine2358
priority: normal
severity: normal
status: open
title: docs: keywords are special - eg constants.html
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34464>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:10:55 2018
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 22 Aug 2018 19:10:55 +0000
Subject: [issue34464] docs: keywords are special - eg constants.html
In-Reply-To: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za>
Message-ID: <1534965055.88.0.56676864532.issue34464@psf.upfronthosting.co.za>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

I'm happy to work on improving the text here. I'm new to contributing to Python. I'm being mentored to work on #34431.

Once I'm done with that, I'll be better placed to contributed to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34464>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:48:00 2018
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Wed, 22 Aug 2018 19:48:00 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
Message-ID: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>


New submission from J?rn Heissler <launchpad at joern.heissler.de>:

Hi,

the ipaddress module accepts `bytes' objects in the constructors.
`bytearray' however is not supported, see paste below.

Should this be supported too?


>>> import ipaddress

>>> ipaddress.IPv4Address(bytes([127, 0, 0, 1]))
IPv4Address('127.0.0.1')

>>> ipaddress.IPv4Address(bytearray([127, 0, 0, 1]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/ipaddress.py", line 1301, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/usr/lib/python3.7/ipaddress.py", line 1135, in _ip_int_from_string
    raise AddressValueError("Expected 4 octets in %r" % ip_str)
ipaddress.AddressValueError: Expected 4 octets in "bytearray(b'\\x7f\\x00\\x00\\x01')"

----------
components: Library (Lib)
messages: 323906
nosy: joernheissler
priority: normal
severity: normal
status: open
title: ipaddress should accept bytearray in addition to bytes
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:51:47 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Aug 2018 19:51:47 +0000
Subject: [issue34464] There are inconsitencies in the treatment of True, False,
 None, and __debug__ keywords in the docs
In-Reply-To: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za>
Message-ID: <1534967507.12.0.56676864532.issue34464@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've removed 2.7 since those constants are not keywords in 2.7 (although None and __debug__ do raise syntax errors even in 2.7, they are not keywords there).  Which is almost certainly why the docs treat them inconsistently (leftovers from before they weren't keywords).  

We only update docs for the actively maintained versions, so I've removed everything before 3.6.  I also tried to clarify the issue in the title.

I don't know why you mention NotImplemented, that's not a keyword.

The issue with __debug__ and keywords.py probably requires a code change, since that file is auto-generated.  Please open a separate issue for that.

Thanks for wanting to improve python!

----------
nosy: +r.david.murray
title: docs: keywords are special - eg constants.html -> There are inconsitencies in the treatment of True, False, None, and __debug__ keywords in the docs
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34464>
_______________________________________

From report at bugs.python.org  Wed Aug 22 15:58:59 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 22 Aug 2018 19:58:59 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534967939.45.0.56676864532.issue34434@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

For tuple and list, no, they couldn't have looked at the help (because the help calls the argument "iterable", while the only keyword accepted was "sequence"). Nor was "sequence" documented in the online docs, nor anywhere else that I can find; it was solely in the C source code.

If it was discoverable in any other way, I wouldn't say documenting the change (outside of What's New) was completely unjustifiable (I acknowledge that int, bool and float warrant a mention, since they did document a functioning name for the argument; I was a little too down on them in my original messages).

But the only way someone would accidentally use keyword arguments for list/tuple is if they were fuzzing the constructor by submitting random keyword arguments until something worked. That seems an odd thing to worry about breaking. The error message wouldn't help either; the exception raised tells you what argument was unrecognized, but not the names of recognized arguments.

Even if you want to document it, it's hard to do so without being confusing, inaccurate, or both. The original PR's versionchanged message was:

*iterable* is now a positional-only parameter.

But "iterable" was never a legal keyword, so saying it's "now a positional-only parameter" implies that at some point, it wasn't, and you could pass it with the name "iterable", which is wrong/confusing. If you mention "sequence", you're mentioning a now defunct detail (confusing, but not wrong). I suppose you could have the versionchanged say "This function does not accept keyword arguments", but again, for all discoverable purposes, it never did.

I'm not saying *no* documentation of the change is needed, but I am saying, for list/tuple, the What's New note is sufficient to cover it for those people who went mucking through the CPython source code to find an undocumented keyword they could use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Wed Aug 22 16:20:38 2018
From: report at bugs.python.org (Kurt Roeckx)
Date: Wed, 22 Aug 2018 20:20:38 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1534969238.31.0.56676864532.issue32947@psf.upfronthosting.co.za>


Kurt Roeckx <kurt at roeckx.be> added the comment:

This are automated tests for the packages in Debian. I uploaded the pre9 version to unstable, and as a result of that all reverse dependencies got tested. I don't have any experience with python myself.

Anyway, the openssl.cnf in Debian contains:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT at SECLEVEL=2

So you might want to override that during the test suite by calling SSL_CTX_set_min_proto_version(ctx, 0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Wed Aug 22 17:04:11 2018
From: report at bugs.python.org (Fedor Korotkiy)
Date: Wed, 22 Aug 2018 21:04:11 +0000
Subject: [issue34466] socket.settimeout working incorrectly for connect()
 method of AF_UNIX socket
Message-ID: <1534971851.11.0.56676864532.issue34466@psf.upfronthosting.co.za>


New submission from Fedor Korotkiy <dartslon at gmail.com>:

Attached program creates listening server socket, fills backlog queue with 2 client socket and performs third connect attempt after setting socket timeout to 5 second.

I expect third connect() attempt to fail after specified timeout of 5 second. That is indeed what's happening for tcp socket (AF_INET).

But when underlying socket has type AF_UNIX, connect() fails immediately with 'Resource temporarily unavailable' error. I'm able to reproduce this issue on linux 4.17.12 and python 3.6.6.

The underlying issue seems to be different behavior of connect(3) system call for unix sockets. Instead of starting operation and returning EINPROGRESS error it fails immediately with EAGAIN error.

Thanks to Vladislav Bidzilya for discovering this issue.

----------
files: bug.py
messages: 323910
nosy: Slon
priority: normal
severity: normal
status: open
title: socket.settimeout working incorrectly for connect() method of AF_UNIX socket
versions: Python 3.6
Added file: https://bugs.python.org/file47759/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34466>
_______________________________________

From report at bugs.python.org  Wed Aug 22 18:02:43 2018
From: report at bugs.python.org (Sheng Zhong)
Date: Wed, 22 Aug 2018 22:02:43 +0000
Subject: [issue34467] No mechanism to abort created coroutine or suppress
 not-awaited warning
Message-ID: <1534975363.12.0.56676864532.issue34467@psf.upfronthosting.co.za>


New submission from Sheng Zhong <zhsh at umich.edu>:

As far as I know, there is no mechanism for aborting a created coroutine instance before it's executed with an await (directly or indirectly). I have a function which takes in coroutine instances and conditionally creates a task for them that I track so that they can be later gathered. When the condition is false, I'd like to not execute the passed in coroutine.

Simply ignoring the coroutine works but reports a RuntimeWarning about coroutine not being awaited on. Checking the conditional before calling the function works but damages maintainability and is putting the responsibility on the wrong party.

Creating the task then immediately cancelling it does not work since execution for it will start and leads to other cancellation issues.

Is there a way to abort a coroutine instance that I'm not aware of?

----------
components: asyncio
messages: 323911
nosy: Sheng Zhong, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: No mechanism to abort created coroutine or suppress not-awaited warning
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34467>
_______________________________________

From report at bugs.python.org  Wed Aug 22 19:57:14 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 22 Aug 2018 23:57:14 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
Message-ID: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

range_repr() contains the following snippet:

    /* Check for special case values for printing.  We don't always
       need the step value.  We don't care about errors
       (it means overflow), so clear the errors. */
    istep = PyNumber_AsSsize_t(r->step, NULL);
    if (istep != 1 || (istep == -1 && PyErr_Occurred())) {
        PyErr_Clear();
    }

The second condition in 'if' statement is always false (reported by Svace static analyzer). Moreover, the comment is incorrect. It implies that any error from PyNumber_AsSsize_t() means that an overflow occurred, but according to its implementation and documentation, any error is guaranteed *not* to be an OverflowError if the second parameter is NULL (the result is clamped on overflow).

In practice, 'range' invariants currently guarantee that no error can occur in this case because 'r->step' is a subtype of int (enforced in validate_step()). So the 'if' statement can be replaced either with an assert:

    assert(!(istep == -1 && PyErr_Occurred()))

or with a conservative check:

    if (istep == -1 && PyErr_Occurred())) {
        // may also add assert(!PyErr_ExceptionMatches( PyExc_OverflowError);
        return NULL;
    }

Suggestions are appreciated.

----------
components: Interpreter Core
messages: 323912
nosy: izbyshev, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: An always-false condition in range_repr() from Objects/rangeobject.c
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Wed Aug 22 19:59:51 2018
From: report at bugs.python.org (ppperry)
Date: Wed, 22 Aug 2018 23:59:51 +0000
Subject: [issue34467] No mechanism to abort created coroutine or suppress
 not-awaited warning
In-Reply-To: <1534975363.12.0.56676864532.issue34467@psf.upfronthosting.co.za>
Message-ID: <1534982391.19.0.56676864532.issue34467@psf.upfronthosting.co.za>


ppperry <mapreader at olum.org> added the comment:

Does calling `coro.close()` not work?

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34467>
_______________________________________

From report at bugs.python.org  Wed Aug 22 20:34:56 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Thu, 23 Aug 2018 00:34:56 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1534984496.45.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by Vladimir Matveev <desco.by at gmail.com>:


----------
pull_requests: +8338

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Wed Aug 22 20:49:01 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Aug 2018 00:49:01 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1534985341.5.0.56676864532.issue34455@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I should have been more specific.  I meant to run the file directly with python, with IDLE not involved.  "python3 .../path/to/tk_scroll.py".  Howver, running it from an IDLE editor and editing in the resulting non-IDLE text window is almost as good.

This reminds me of when trying to enter a French cedilla crashed tk.  That was fixed about at tk 8.5.15.

The only thing that could be done from IDLE is to add tk(inter) bind calls.

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Aug 22 21:44:35 2018
From: report at bugs.python.org (iPodClassic)
Date: Thu, 23 Aug 2018 01:44:35 +0000
Subject: [issue34455] Tkinter crashing when pressing Command + ^  (OSX)
In-Reply-To: <1534890010.44.0.56676864532.issue34455@psf.upfronthosting.co.za>
Message-ID: <1534988675.0.0.56676864532.issue34455@psf.upfronthosting.co.za>


iPodClassic <marianogedisman at gmail.com> added the comment:

I see. Well, I guess as far as I can go is to notify about the bug. The part about adding tkinter bind calls I have no idea. Should we just close this bug report as postponed or something?

Thanks for the help and explanation though! I guess the more I get into Python the more things I will find out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34455>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:04:07 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Aug 2018 03:04:07 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1534993447.2.0.56676864532.issue34434@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I'm not saying *no* documentation of the change is needed, 
> but I am saying, for list/tuple, the What's New note is 
> sufficient to cover it for those people who went mucking 
> through the CPython source code to find an undocumented 
> keyword they could use.

That seems like a reasonable position to take.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:14:39 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Aug 2018 03:14:39 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1534994079.52.0.56676864532.issue34410@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Xiang Zhang, would you like to submit a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:40:21 2018
From: report at bugs.python.org (Christopher Knorowski)
Date: Thu, 23 Aug 2018 03:40:21 +0000
Subject: [issue34469] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
Message-ID: <1534995621.59.0.56676864532.issue34469@psf.upfronthosting.co.za>


New submission from Christopher Knorowski <cknorow at gmail.com>:

Steps to repeate (windows 10)

msiexec.exe /i python-2.7.15.amd64.msi TARGET_DIR=C:/Users/Public/python /qr

(fresh install works without issue)

rm -r C:/Users/Public/python

msiexec.exe /i python-2.7.15.amd64.msi TARGET_DIR=C:/Users/Public/python /qr

(Scripts folder and all site-packages are not copied ie. no Pip or easy_install)

----------
components: Installation
messages: 323918
nosy: cdknorow
priority: normal
severity: normal
status: open
title: windows msi in headless mode fails to install Script directory on reinstall if the python folder was deleted but not uninstalled
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34469>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:45:13 2018
From: report at bugs.python.org (Christopher Knorowski)
Date: Thu, 23 Aug 2018 03:45:13 +0000
Subject: [issue34469] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534995621.59.0.56676864532.issue34469@psf.upfronthosting.co.za>
Message-ID: <1534995913.97.0.56676864532.issue34469@psf.upfronthosting.co.za>


Christopher Knorowski <cknorow at gmail.com> added the comment:

Steps to repeate (windows 10)

msiexec.exe /i python-2.7.15.amd64.msi TARGETDIR=C:/Users/Public/python /qr

(fresh install works without issue)

rm -r C:/Users/Public/python

msiexec.exe /i python-2.7.15.amd64.msi TARGETDIR=C:/Users/Public/python /qr

(Scripts folder and all site-packages are not copied ie. no Pip or easy_install)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34469>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:47:32 2018
From: report at bugs.python.org (Christopher Knorowski)
Date: Thu, 23 Aug 2018 03:47:32 +0000
Subject: [issue34469] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534995621.59.0.56676864532.issue34469@psf.upfronthosting.co.za>
Message-ID: <1534996052.96.0.56676864532.issue34469@psf.upfronthosting.co.za>


Christopher Knorowski <cknorow at gmail.com> added the comment:

Steps to repeate (windows 10)

msiexec.exe /i python-2.7.15.amd64.msi ALL_USERS=0 TARGETDIR=C:\Users\Public\python /qr

(fresh install works without issue)

rm -r C:/Users/Public/python

msiexec.exe /i python-2.7.15.amd64.msi ALL_USERS=0 TARGETDIR=C:\Users\Public\python /qr

(Scripts folder and all site-packages are not copied ie. no Pip or easy_install)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34469>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:48:26 2018
From: report at bugs.python.org (Christopher Knorowski)
Date: Thu, 23 Aug 2018 03:48:26 +0000
Subject: [issue34469] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534995621.59.0.56676864532.issue34469@psf.upfronthosting.co.za>
Message-ID: <1534996106.24.0.56676864532.issue34469@psf.upfronthosting.co.za>


Change by Christopher Knorowski <cknorow at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34469>
_______________________________________

From report at bugs.python.org  Wed Aug 22 23:50:13 2018
From: report at bugs.python.org (Christopher Knorowski)
Date: Thu, 23 Aug 2018 03:50:13 +0000
Subject: [issue34470] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
Message-ID: <1534996213.68.0.56676864532.issue34470@psf.upfronthosting.co.za>


New submission from Christopher Knorowski <cknorow at gmail.com>:

Steps to repeate (windows 10)

msiexec.exe /i python-2.7.15.amd64.msi ALL_USERS=0 TARGETDIR=C:\Users\Public\python /qr

(fresh install works without issue)

rm -r C:\Users\Public\python

(On reinstall scripts folder and all site-packages are not copied ie. no Pip or easy_install)

msiexec.exe /i python-2.7.15.amd64.msi ALL_USERS=0 TARGETDIR=C:\Users\Public\python /qr

----------
components: Installation
messages: 323921
nosy: cdknorow
priority: normal
severity: normal
status: open
title: windows msi in headless mode fails to install Script directory on reinstall if the python folder was deleted but not uninstalled
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34470>
_______________________________________

From report at bugs.python.org  Thu Aug 23 00:01:31 2018
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 23 Aug 2018 04:01:31 +0000
Subject: [issue34470] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534996213.68.0.56676864532.issue34470@psf.upfronthosting.co.za>
Message-ID: <1534996891.86.0.56676864532.issue34470@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Python 2.7 is nearing end-of-life, its installer scheme is no longer used on any other branch, and the maintainer of that installer retired some years ago.  If you provide a patch, we can take a look and possibly merge it for you, but it's unlikely that this will be picked up by a maintainer without a patch to review.

If you would like to try patching it, all the necessary files should be in 2.7/Tools/msi, and you can feel free to ask questions here if you get stuck.  Good luck!

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
priority: normal -> low
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34470>
_______________________________________

From report at bugs.python.org  Thu Aug 23 00:34:36 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Aug 2018 04:34:36 +0000
Subject: [issue34466] socket.settimeout working incorrectly for connect()
 method of AF_UNIX socket
In-Reply-To: <1534971851.11.0.56676864532.issue34466@psf.upfronthosting.co.za>
Message-ID: <1534998876.06.0.56676864532.issue34466@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think what you want to do is not use the timeout feature of Python sockets and instead use mysock.setsockopt(SO_SNDTIMEO, 5).

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34466>
_______________________________________

From report at bugs.python.org  Thu Aug 23 03:05:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 07:05:22 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535007922.56.0.56676864532.issue34436@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

bytes % args has been optimized using the _PyBytesWriter API in bpo-25349: commit fa7762ec066aa3632a25b6a52bb7597b8f17c2f3.

I converted my old benchmark from bpo-25349 to my new perf module:
https://github.com/vstinner/pymicrobench/blob/master/bench_bytes_format_int.py

See also my article on _PyBytesWriter API: https://vstinner.github.io/pybyteswriter.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 03:50:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 07:50:05 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535010605.6.0.56676864532.issue34436@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I ran a microbenchmark on PR 8826:

./python -m perf timeit -s 'fmt=b"%s%s"; args=(b"1", b"x"*(1024*1024))' 'fmt % args' -v -o patch.json

$ python3 -m perf compare_to ref.json patch.json
Mean +- std dev: [ref] 325 us +- 7 us -> [patch] 36.2 us +- 1.1 us: 8.98x faster (-89%)

Ooops, yeah, it's obvious that there was a missed optimization. It's now way faster ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 03:51:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 07:51:03 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535010663.46.0.56676864532.issue34436@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset ccd99752675042bd5f67d332c5b0ed85ba1f2da3 by Victor Stinner (Alexey Izbyshev) in branch 'master':
bpo-34436: Fix check that disables overallocation for the last fmt specifier (GH-8826)
https://github.com/python/cpython/commit/ccd99752675042bd5f67d332c5b0ed85ba1f2da3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 03:51:25 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Aug 2018 07:51:25 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535010685.0.0.56676864532.issue34436@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8339

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 03:51:34 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Aug 2018 07:51:34 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535010694.21.0.56676864532.issue34436@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8340

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 04:03:05 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Aug 2018 08:03:05 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535011385.58.0.56676864532.issue34436@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 042082692b7fab7361a8c9d0fb792532bb77e293 by Miss Islington (bot) in branch '3.7':
bpo-34436: Fix check that disables overallocation for the last fmt specifier (GH-8826)
https://github.com/python/cpython/commit/042082692b7fab7361a8c9d0fb792532bb77e293


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 04:15:06 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Aug 2018 08:15:06 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535012106.26.0.56676864532.issue34436@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 945771b3c7a08f0b2b875905d517a1566477bfaf by Miss Islington (bot) in branch '3.6':
bpo-34436: Fix check that disables overallocation for the last fmt specifier (GH-8826)
https://github.com/python/cpython/commit/945771b3c7a08f0b2b875905d517a1566477bfaf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 04:43:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 08:43:19 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>
Message-ID: <1535013799.12.0.56676864532.issue34423@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

It seems like a regression introduced by:

commit a853a8ba7850381d49b284295dd6f0dc491dbe44
Author: Benjamin Peterson <benjamin at python.org>
Date:   Thu Sep 7 11:13:59 2017 -0700

    bpo-31373: fix undefined floating-point demotions (#3396)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Thu Aug 23 04:51:55 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 23 Aug 2018 08:51:55 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535014315.82.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Thu Aug 23 04:52:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 08:52:43 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>
Message-ID: <1535014363.31.0.56676864532.issue34423@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm not sure that the pytime.c change in commit a853a8ba7850381d49b284295dd6f0dc491dbe44 is correct:

diff --git a/Python/pytime.c b/Python/pytime.c
index 8979adc219..f3c913226c 100644
--- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -276,7 +278,6 @@ static int
 _PyTime_FromFloatObject(_PyTime_t *t, double value, _PyTime_round_t round,
                         long unit_to_ns)
 {
-    double err;
     /* volatile avoids optimization changing how numbers are rounded */
     volatile double d;
 
@@ -285,12 +286,11 @@ _PyTime_FromFloatObject(_PyTime_t *t, double value, _PyTime_round_t round,
     d *= (double)unit_to_ns;
     d = _PyTime_Round(d, round);
 
-    *t = (_PyTime_t)d;
-    err = d - (double)*t;
-    if (fabs(err) >= 1.0) {
+    if (!_Py_InIntegralTypeRange(_PyTime_t, d)) {
         _PyTime_overflow();
         return -1;
     }
+    *t = (_PyTime_t)d;
     return 0;
 }


I don't think that modifying _Py_InIntegralTypeRange() macro to replace "<=" with "<" is correct, since this bug is very specific to pytime.c, when _Py_InIntegralTypeRange() is used with a double. The PR proposes:

#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v < _Py_IntegralTypeMax(type))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Thu Aug 23 04:54:55 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 08:54:55 +0000
Subject: [issue34436] Overallocation is never disabled in _PyBytes_FormatEx()
In-Reply-To: <1534704703.42.0.56676864532.issue34436@psf.upfronthosting.co.za>
Message-ID: <1535014495.74.0.56676864532.issue34436@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you for benchmarking and merging, Victor!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34436>
_______________________________________

From report at bugs.python.org  Thu Aug 23 05:40:09 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 23 Aug 2018 09:40:09 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535017209.23.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Thu Aug 23 05:51:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 09:51:12 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535017872.62.0.56676864532.issue34207@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8341
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 05:51:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 09:51:12 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1535017872.76.0.665841612001.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8342

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:06:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:06:35 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535018795.12.0.56676864532.issue34207@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I confirm that "LC_ALL= LANG= LC_CTYPE= ./python -m test -v test_cmd_line -m test_non_ascii" fails on FreeBSD on the master branch, whereas it pass  before commit d19d8d5279f156bc8f6736b5f16f069879b9519b. This commit introduced the regression.

Thanks for the bisection Nick!

My change avoids modifying global configurable variables, whereas Py_DecodeLocale() and Py_EncodeLocale() depend on Py_UTF8Mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:06:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:06:50 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535018810.37.0.56676864532.issue34207@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8343

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:06:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:06:50 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1535018810.53.0.665841612001.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8344

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:13:55 2018
From: report at bugs.python.org (Fedor Korotkiy)
Date: Thu, 23 Aug 2018 10:13:55 +0000
Subject: [issue34466] socket.settimeout working incorrectly for connect()
 method of AF_UNIX socket
In-Reply-To: <1534971851.11.0.56676864532.issue34466@psf.upfronthosting.co.za>
Message-ID: <1535019235.5.0.56676864532.issue34466@psf.upfronthosting.co.za>


Fedor Korotkiy <dartslon at gmail.com> added the comment:

Hello Benjamin.

That would be appropriate workaround.

Maybe we should update docs to mention it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34466>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:14:41 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 10:14:41 +0000
Subject: [issue34471] _datetime: Missing NULL check in
 tzinfo_from_isoformat_results()
Message-ID: <1535019280.96.0.56676864532.issue34471@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of new_delta() is not checked for NULL at https://github.com/python/cpython/blob/ccd99752675042bd5f67d332c5b0ed85ba1f2da3/Modules/_datetimemodule.c#L1292 and then dereferenced.

Reported by Svace static analyzer.

----------
components: Extension Modules
messages: 323934
nosy: belopolsky, izbyshev, p-ganssle, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _datetime: Missing NULL check in tzinfo_from_isoformat_results()
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34471>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:18:04 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 10:18:04 +0000
Subject: [issue34471] _datetime: Missing NULL check in
 tzinfo_from_isoformat_results()
In-Reply-To: <1535019280.96.0.56676864532.issue34471@psf.upfronthosting.co.za>
Message-ID: <1535019484.58.0.56676864532.issue34471@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8345
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34471>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:18:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:18:52 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535019532.42.0.56676864532.issue34207@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 8867 but it doesn't fix all cases, so I abandonned it.

Then I wrote PR 8868 which sets Py_UTF8Mode in pymain_read_conf() and should fix the issue.

The root issue is that we have C functions which depend on the global configuration variables like Py_UTF8Mode :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:23:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:23:48 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1535019828.86.0.56676864532.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 89487f51b8d6ba8a55f5de0ed689e46fefe73cc9 by Victor Stinner in branch 'master':
bpo-34207: Fix pymain_read_conf() for UTF-8 Mode (GH-8868)
https://github.com/python/cpython/commit/89487f51b8d6ba8a55f5de0ed689e46fefe73cc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:23:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:23:48 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535019828.96.0.902498594338.issue34207@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 89487f51b8d6ba8a55f5de0ed689e46fefe73cc9 by Victor Stinner in branch 'master':
bpo-34207: Fix pymain_read_conf() for UTF-8 Mode (GH-8868)
https://github.com/python/cpython/commit/89487f51b8d6ba8a55f5de0ed689e46fefe73cc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:27:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:27:34 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535020054.3.0.56676864532.issue34207@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8346

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:27:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:27:34 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1535020054.61.0.665841612001.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8347

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:41:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:41:39 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1535020899.29.0.56676864532.issue34170@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 80a0ebaa8385988b1d2dbbbb71ed1f548fc32ad7 by Victor Stinner in branch '3.7':
bpo-34207: Fix pymain_read_conf() for UTF-8 Mode (GH-8868) (GH-8870)
https://github.com/python/cpython/commit/80a0ebaa8385988b1d2dbbbb71ed1f548fc32ad7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:41:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:41:39 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535020899.38.0.902498594338.issue34207@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 80a0ebaa8385988b1d2dbbbb71ed1f548fc32ad7 by Victor Stinner in branch '3.7':
bpo-34207: Fix pymain_read_conf() for UTF-8 Mode (GH-8868) (GH-8870)
https://github.com/python/cpython/commit/80a0ebaa8385988b1d2dbbbb71ed1f548fc32ad7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:43:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:43:50 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535021030.52.0.56676864532.issue34207@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The regression should now be fixed in 3.7 and master branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:44:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:44:58 +0000
Subject: [issue34170] Py_Initialize(): computing path configuration must not
 have side effect (PEP 432)
In-Reply-To: <1532100252.91.0.56676864532.issue34170@psf.upfronthosting.co.za>
Message-ID: <1535021098.72.0.56676864532.issue34170@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34170>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:48:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:48:50 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535021330.05.0.56676864532.issue34347@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I fixed bpo-34207.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Thu Aug 23 06:51:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 10:51:30 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535021490.16.0.56676864532.issue34347@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Your issue is about decoding command line argument which is done from main() function. It doesn't use Python codecs, but functions like Py_DecodeLocale().

> Question 1: why is windows excluded? Because it does not use UTF-8 as it's default (it's default is CP1252)

Windows uses wmain() which gets command line arguments as wchar_t* strings: Unicode. No decoding is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Thu Aug 23 08:57:59 2018
From: report at bugs.python.org (Silas Sewell)
Date: Thu, 23 Aug 2018 12:57:59 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
Message-ID: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>


New submission from Silas Sewell <silas at sewell.org>:

When adding a fileobj that is not seekable to a zip using the zipfile module, the optional signature value 0x08074b50 is not included. This breaks certain zip implementations, including the builtin MacOS Archive Utility.

See https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT sections 4.3.9.3 and 4.3.9.4

----------
components: Library (Lib)
files: zip_stream_example.py
messages: 323943
nosy: silas
priority: normal
severity: normal
status: open
title: zipfile: does not include optional descriptor signature
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47760/zip_stream_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Thu Aug 23 09:01:46 2018
From: report at bugs.python.org (Silas Sewell)
Date: Thu, 23 Aug 2018 13:01:46 +0000
Subject: [issue34472] zipfile: does not include optional descriptor signature
In-Reply-To: <1535029079.23.0.56676864532.issue34472@psf.upfronthosting.co.za>
Message-ID: <1535029306.0.0.56676864532.issue34472@psf.upfronthosting.co.za>


Change by Silas Sewell <silas at sewell.org>:


----------
keywords: +patch
pull_requests: +8348
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34472>
_______________________________________

From report at bugs.python.org  Thu Aug 23 09:27:22 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 13:27:22 +0000
Subject: [issue34412] strsignal(3) does not exist on HP-UX
In-Reply-To: <1534430872.24.0.56676864532.issue34412@psf.upfronthosting.co.za>
Message-ID: <1535030842.08.0.56676864532.issue34412@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 48ce4897f8f8d91d948ecd1241ffab002df2be9e by Berker Peksag (Michael Osipov) in branch 'master':
bpo-34412: Make signal.strsignal() work on HP-UX (GH-8786)
https://github.com/python/cpython/commit/48ce4897f8f8d91d948ecd1241ffab002df2be9e


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34412>
_______________________________________

From report at bugs.python.org  Thu Aug 23 09:28:07 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 13:28:07 +0000
Subject: [issue34412] strsignal(3) does not exist on HP-UX
In-Reply-To: <1534430872.24.0.56676864532.issue34412@psf.upfronthosting.co.za>
Message-ID: <1535030887.25.0.56676864532.issue34412@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34412>
_______________________________________

From report at bugs.python.org  Thu Aug 23 09:36:22 2018
From: report at bugs.python.org (Matt Tuttle)
Date: Thu, 23 Aug 2018 13:36:22 +0000
Subject: [issue34473] pip is unusable on Windows 10 1803 - SHA-1 certificates
 are untrusted
Message-ID: <1535031382.08.0.56676864532.issue34473@psf.upfronthosting.co.za>


New submission from Matt Tuttle <mtuttle at aha-net.org>:

Running pip install ANYTHING results in an SSL failure on Windows 10 1803 because SHA-1 certificates are untrusted.

----------
components: Installation, Windows
messages: 323945
nosy: mtuttle, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip is unusable on Windows 10 1803 - SHA-1 certificates are untrusted
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34473>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:04:14 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 14:04:14 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
Message-ID: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyFloat_FromDouble() at https://github.com/python/cpython/blob/48ce4897f8f8d91d948ecd1241ffab002df2be9e/Python/bltinmodule.c#L2403 is not checked for NULL and then dereferenced.

Reported by Svace static analyzer.

A similar issue in an 'if' statement above was fixed in #18560. Note that 2.7 is affected by both issues, so I can fix both if needed.

----------
components: Interpreter Core
messages: 323946
nosy: berker.peksag, izbyshev, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Python/bltinmodule.c: Missing NULL check in builtin_sum_impl()
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:07:27 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 14:07:27 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535033247.49.0.56676864532.issue34474@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8350
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:25:59 2018
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 23 Aug 2018 14:25:59 +0000
Subject: [issue34475] functools.partial objects have no __qualname__ attribute
Message-ID: <1535034359.11.0.56676864532.issue34475@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

functools.partial objects have no __qualname__ attribute. This means, for example, that code expecting a callable that logs the __qualname__ attribute can break when passed a functools.partial object.

Example:

>>> import functools
>>> int.__qualname__
'int'
>>> p = functools.partial(int)
>>> p.__qualname__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'functools.partial' object has no attribute '__qualname__'

----------
components: Library (Lib)
messages: 323947
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: functools.partial objects have no __qualname__ attribute
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34475>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:34:33 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 14:34:33 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535034873.6.0.56676864532.issue34474@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Personally I wouldn't bother fixing 2.7, but let's see what other core devs think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:41:27 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Thu, 23 Aug 2018 14:41:27 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
Message-ID: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

Looking at the implementation and at the old issue at https://github.com/python/asyncio/issues/284 shows that asyncio.sleep special-cases asyncio.sleep(0) to mean "yield control to the event loop" without incurring additional overhead of sleeping. However, this is not documented at https://docs.python.org/3/library/asyncio-task.html#asyncio.sleep .

I propose to add to the documentation a statement along the lines of:

"""
A delay of 0 will relinquish control to the event loop, allowing other tasks and callbacks to run. The control will be returned to the coroutine as soon as they have run, without an explicit delay.
"""

----------
assignee: docs at python
components: Documentation, asyncio
messages: 323949
nosy: asvetlov, docs at python, hniksic, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.sleep(0) not documented
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:42:20 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Thu, 23 Aug 2018 14:42:20 +0000
Subject: [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1535035340.07.0.56676864532.issue34476@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Also, the "Create a coroutine ..." wording in the current documentation is a bit strange - sleep() is already marked as a coroutine, and documentation of other coroutines simply state their effect in imperative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34476>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:52:19 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 14:52:19 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
Message-ID: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyTuple_GetSlice() at https://github.com/python/cpython/blob/48ce4897f8f8d91d948ecd1241ffab002df2be9e/Objects/typeobject.c#L2297 is not checked for NULL and then dereferenced.

Reported by Svace static analyzer.

Currently, PyTuple_GetSlice() for a zero-length slice can fail only if it's the first zero-length tuple ever created. If there is an invariant that at least one zero-length tuple exists on any type_init() call, the check may be replaced with an assert.

----------
components: Interpreter Core
messages: 323951
nosy: berker.peksag, izbyshev, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Objects/typeobject.c: Missing NULL check in type_init()
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Thu Aug 23 10:55:45 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 14:55:45 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535036145.19.0.56676864532.issue34477@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8351
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:03:58 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 15:03:58 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1535036638.05.0.56676864532.issue34448@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The message is a bit more descriptive if wchar_t isn't usable:

> checking whether wchar_t is signed... yes
> no usable wchar_t found

I'm not sure if it's worth to backport to 3.6, but it's a nice improvement for 3.7 and master branches. Also, it simplifies the checking for wchar_t a bit, which is good.

----------
nosy: +berker.peksag
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:05:23 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Aug 2018 15:05:23 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1535036723.71.0.56676864532.issue11192@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I nearly have a patch - to resolve all the remaining test_socket() issues with AIX. However, this (new?) issue remains:

        f = lambda a: inet_pton(AF_INET6, a)
        assertInvalid = lambda a: self.assertRaises(
            (OSError, ValueError), f, a
        )

>>> f('1:2:3:4:5:6:7:8')
b'\x00\x01\x00\x02\x00\x03\x00\x04\x00\x05\x00\x06\x00\x07\x00\x08'
>>> f('1:2:3:4:5:6:7:8:')
b'\x00\x01\x00\x02\x00\x03\x00\x04\x00\x05\x00\x06\x00\x07\x00\x08'
>>> f('1::')
b'\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> f('1:2:3:4:5:6:7:8::')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
OSError: illegal IP address string passed to inet_pton

>>> f('1:2:3:4:5:6:7')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
OSError: illegal IP address string passed to inet_pton


Is, maybe, the last test meant to be '::' on the end, rather than ':'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:06:23 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 23 Aug 2018 15:06:23 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1535036783.61.0.56676864532.issue34454@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 096329f0b2bf5e3f0a16363aa631d993ce078737 by Tal Einat (Paul Ganssle) in branch 'master':
bpo-34454: fix .fromisoformat() methods crashing on inputs with surrogate code points (GH-8862)
https://github.com/python/cpython/commit/096329f0b2bf5e3f0a16363aa631d993ce078737


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:06:35 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Aug 2018 15:06:35 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1535036795.13.0.56676864532.issue34454@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8352

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:07:34 2018
From: report at bugs.python.org (Segev Finer)
Date: Thu, 23 Aug 2018 15:07:34 +0000
Subject: [issue34478] Possibly misleading/wrong documentation about
 PyModuleDef.m_free
Message-ID: <1535036854.66.0.56676864532.issue34478@psf.upfronthosting.co.za>


New submission from Segev Finer <segev208 at gmail.com>:

This section in the documentation https://docs.python.org/3.7/howto/cporting.html#module-initialization-and-state shows how to implement an extension module that works for both Python 2 and 3. It also shows how to use m_size to manage module state instead of using static globals. But it omits implementing m_free. This is also done in https://www.python.org/dev/peps/pep-3121/#example

To my understanding, m_clear is *only* called by the Python GC when the object is a part of a reference cycle. It won't be called for a normal free when the object wasn't a part of a reference cycle. This means that for such a case the objects referenced in the state structure will leak!

Looking around the standard library, it seems the extension modules there point m_free to calling the function used to implement m_clear.

The documentation of the structure is also quite unclear on the subject https://docs.python.org/3/c-api/module.html?highlight=pymoduledef#c.PyModuleDef.

P.S. There is also no freeing/DECREF-ing stuff in the state on error in the Python 2 case, but I think even the standard library is like this.

----------
assignee: docs at python
components: Documentation
messages: 323955
nosy: Segev Finer, docs at python
priority: normal
severity: normal
status: open
title: Possibly misleading/wrong documentation about PyModuleDef.m_free
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34478>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:32:12 2018
From: report at bugs.python.org (Siming Yuan)
Date: Thu, 23 Aug 2018 15:32:12 +0000
Subject: [issue34479] ArgumentParser subparser error display at the wrong level
Message-ID: <1535038332.48.0.56676864532.issue34479@psf.upfronthosting.co.za>


New submission from Siming Yuan <siming85 at gmail.com>:

If you take the example from
https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers

# create the top-level parser
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument('--foo', action='store_true', help='foo help')
subparsers = parser.add_subparsers(help='sub-command help')
# create the parser for the "a" command
parser_a = subparsers.add_parser('a', help='a help')
parser_a.add_argument('-bar', type=int, help='bar help')
# create the parser for the "b" command
parser_b = subparsers.add_parser('b', help='b help')
parser_b.add_argument('--baz', choices='XYZ', help='baz help')


and run a subcommand but with an argument the subcommand doesn't understand

parser.parse_args(['a', '-x'])

the output doesn't help much - because the usage is coming from the main parser

usage: PROG [-h] [--foo] {a,b} ...
PROG: error: unrecognized arguments: -x


the reason for failure is because the error api being called in this case is
parser.error(msg)

not the subparser
parser_a.error(msg)

the proper error should've been

usage: PROG a [-h] [-bar BAR]
PROG a: error: unrecognized arguments: -x

----------
components: Library (Lib)
messages: 323956
nosy: siming85
priority: normal
severity: normal
status: open
title: ArgumentParser subparser error display at the wrong level
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34479>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:48:10 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 23 Aug 2018 15:48:10 +0000
Subject: [issue34473] pip is unusable on Windows 10 1803 - SHA-1 certificates
 are untrusted
In-Reply-To: <1535031382.08.0.56676864532.issue34473@psf.upfronthosting.co.za>
Message-ID: <1535039290.33.0.56676864532.issue34473@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Can you be more precise about which versions are affected and any other system configuration you have (firewalls, network security software, enterprise configs, etc.)?

I have been using pip quite happily on 1803, so it's certainly not widespread enough to justify this vague a report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34473>
_______________________________________

From report at bugs.python.org  Thu Aug 23 11:54:51 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Aug 2018 15:54:51 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1535039691.6.0.56676864532.issue34454@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 89b1654e0bc7bc69709dca86dd4c92eb7122ac7e by Miss Islington (bot) in branch '3.7':
bpo-34454: fix .fromisoformat() methods crashing on inputs with surrogate code points (GH-8862)
https://github.com/python/cpython/commit/89b1654e0bc7bc69709dca86dd4c92eb7122ac7e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Thu Aug 23 12:19:02 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Thu, 23 Aug 2018 16:19:02 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>
Message-ID: <1535041142.33.0.56676864532.issue34423@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

Although you're right - this issue is specific to pytime.c, when _Py_InIntegralTypeRange() is used with a double, it is actually true that _Py_InIntegralTypeRange() is used with double, in pytime.c only (as a quick recursive grep discovers).

Perhaps the macro should be renamed not to cause confusion (include note about floating point, or define it as a function).

I don't have good idea on how this issue could be resolved otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Thu Aug 23 12:47:49 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 23 Aug 2018 16:47:49 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1535042869.03.0.56676864532.issue34454@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the report and initial patch, Alexey!

Thanks for the followup and final PR, Paul!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:14:25 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 23 Aug 2018 17:14:25 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1535021490.16.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <9a2bf6f5-2270-2900-3955-d53557cc140f@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 23/08/2018 12:51, STINNER Victor wrote:
> STINNER Victor <vstinner at redhat.com> added the comment:
>
> Your issue is about decoding command line argument which is done from main() function. It doesn't use Python codecs, but functions like Py_DecodeLocale().
This is beyond my understanding atm.
Early on I tried making the expected just be 'arg' and went from
situation A to situation B - which looked much closer, BUT, the 'types'
differed:

Situaltion A (original)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

I tried saying the "expected" is arg, but arg is still a byte object, the cmd_line result is not (printed as such).

Situation B
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "[b'h\\xc3\\xa9\\xe2\\x82\\xac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ [b'h\xc3\xa9\xe2\x82\xac']
?  +
 : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']

After further digging - to understand why it was coming as "\x encoding rather than \udc"

I looked at what was happening here:

out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
becomes
out = self.get_output('-X', utf8_opt, '-c', code, 'h\xe9\u20ac'.encode('utf-8'), **kw)
becomes
out = self.get_output('-X', utf8_opt, '-c', code, b'h\xc3\xa9\xe2\x82\xac', **kw)

And finally, at the CLI becomes:
['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8', '-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']

/data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.ar
gv[1:])))', b'h\xc3\xa9\xe2\x82\xac'
UTF-8:['bh\\xc3\\xa9\\xe2\\x82\\xac']

/data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.
argv[1:])))', b'h\xc3\xa9\xe2\x82\xac'
ISO8859-1:['bh\\xc3\\xa9\\xe2\\x82\\xac']

Note:
/data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.
argv[1:])))', 'h\udcc3\udca9\udce2\udc82\udcac'
ISO8859-1:['h\\udcc3\\udca9\\udce2\\udc82\\udcac']

/data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.
argv[1:])))', b'h\udcc3\udca9\udce2\udc82\udcac'
ISO8859-1:['bh\\udcc3\\udca9\\udce2\\udc82\\udcac']

root at x066:[/data/prj/python/python3-3.8]/data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8' '-c' 'import locale, sys; print("%s:%s" % (>
UTF-8:['bh\\udcc3\\udca9\\udce2\\udc82\\udcac']

Summary:
a) concerned about how b'h....' becomes 'bh....'
b) whatwever argv[1] is, is very close to what is returned - so whatever happens durinf the transformation from 
self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
 determines the output and the (failed) comparison.

>> Question 1: why is windows excluded? Because it does not use UTF-8 as it's default (it's default is CP1252)
> Windows uses wmain() which gets command line arguments as wchar_t* strings: Unicode. No decoding is needed.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34347>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:30:37 2018
From: report at bugs.python.org (Conrad)
Date: Thu, 23 Aug 2018 17:30:37 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
Message-ID: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>


New submission from Conrad <conrad.roche at gmail.com>:

$ pip freeze | grep beautifulsoup4
beautifulsoup4==4.6.3

$ python
Python 3.7.0 (default, Jul 23 2018, 20:24:19)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from bs4 import BeautifulSoup
>>> text = "<![hi world]>"
>>> BeautifulSoup(text, 'html.parser')
/Users/conradroche/solvvy/ml-pipeline/venv/lib/python3.7/site-packages/bs4/builder/_htmlparser.py:78: UserWarning: unknown status keyword 'hi ' in marked section
  warnings.warn(msg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/conradroche/solvvy/ml-pipeline/venv/lib/python3.7/site-packages/bs4/__init__.py", line 282, in __init__
    self._feed()
  File "/Users/conradroche/solvvy/ml-pipeline/venv/lib/python3.7/site-packages/bs4/__init__.py", line 343, in _feed
    self.builder.feed(self.markup)
  File "/Users/conradroche/solvvy/ml-pipeline/venv/lib/python3.7/site-packages/bs4/builder/_htmlparser.py", line 247, in feed
    parser.feed(markup)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 111, in feed
    self.goahead(0)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 179, in goahead
    k = self.parse_html_declaration(i)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 264, in parse_html_declaration
    return self.parse_marked_section(i)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_markupbase.py", line 160, in parse_marked_section
    if not match:
UnboundLocalError: local variable 'match' referenced before assignment
>>>

----------
components: Library (Lib)
messages: 323962
nosy: kodial
priority: normal
severity: normal
status: open
title: _markupbase.py fails with UnboundLocalError on invalid keyword in marked section
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:40:57 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 17:40:57 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
Message-ID: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The C datetime implementation uses PyUnicode_AsUTF8AndSize() in wrap_strftime() and rejects strings containing surrogate code points (0xD800 - 0xDFFF) since they can't be encoded in UTF-8. On the other hand, the pure-Python datetime implementation doesn't have this restriction:

>>> import sys
>>> sys.modules['_datetime'] = None # block C implementation
>>> from datetime import time
>>> time().strftime('\ud800')
'\ud800'
>>> del sys.modules['datetime']
>>> del sys.modules['_datetime']
>>> from datetime import time
>>> time().strftime('\ud800')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 0: surrogates not allowed

----------
components: Extension Modules
messages: 323963
nosy: belopolsky, izbyshev, pitrou, serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:41:50 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 17:41:50 +0000
Subject: [issue34482] datetime: Tests for potential crashes due to
 non-UTF-8-encodable strings
Message-ID: <1535046110.83.0.56676864532.issue34482@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

This is a follow-up of #34454. 'datetime' extension module attempts to encode input strings into UTF-8 in several places, which requires special care because some valid Python strings can't be represented in UTF-8. It makes sense to add more tests for methods dealing with strings.

Note that my PR doesn't attempt to deal with #34481. In cases where behavior differs between C and Python datetime impls the tests check only for  absence of crashes.

----------
components: Extension Modules
messages: 323964
nosy: belopolsky, izbyshev, p-ganssle, serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: datetime: Tests for potential crashes due to non-UTF-8-encodable strings
type: security
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34482>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:49:17 2018
From: report at bugs.python.org (Alex)
Date: Thu, 23 Aug 2018 17:49:17 +0000
Subject: [issue34483] eval() raises NameError: name '...' is not defined
Message-ID: <1535046557.48.0.56676864532.issue34483@psf.upfronthosting.co.za>


New submission from Alex <bojenko.alex at gmail.com>:

Builtin eval() function raises NameError on a valid expression:


--- example of bug on Python 3.4
Python 3.4.5 (default, May 29 2017, 15:17:55)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1,2,3]
>>> [x for i in x]
[[1, 2, 3], [1, 2, 3], [1, 2, 3]]
>>> eval('[x for i in x]', {}, dict(x=x))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <listcomp>
NameError: name 'x' is not defined


--- example on Python 2.7 (no bug)
Python 2.7.5 (default, May  3 2017, 07:55:04)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1,2,3]
>>> [x for i in x]
[[1, 2, 3], [1, 2, 3], [1, 2, 3]]
>>> eval('[x for i in x]', {}, dict(x=x))
[[1, 2, 3], [1, 2, 3], [1, 2, 3]]


---

Bug reproduced on:
- Windows 7: Python 3.4, 3.7
- Red Hat Enterprise Linux Server: Python 3.4

Works without errors on:
- Windows 7: Python 2.7
- Red Hat Enterprise Linux Server: Python 2.7

----------
components: Interpreter Core
messages: 323965
nosy: alexb
priority: normal
severity: normal
status: open
title: eval() raises NameError: name '...' is not defined
versions: Python 3.4, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34483>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:49:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 17:49:49 +0000
Subject: [issue34482] datetime: Tests for potential crashes due to
 non-UTF-8-encodable strings
In-Reply-To: <1535046110.83.0.56676864532.issue34482@psf.upfronthosting.co.za>
Message-ID: <1535046589.72.0.56676864532.issue34482@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8353
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34482>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:49:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 17:49:49 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1535046589.87.0.665841612001.issue34454@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
pull_requests: +8354

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Thu Aug 23 13:53:12 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 17:53:12 +0000
Subject: [issue34482] datetime: Tests for potential crashes due to
 non-UTF-8-encodable strings
In-Reply-To: <1535046110.83.0.56676864532.issue34482@psf.upfronthosting.co.za>
Message-ID: <1535046792.39.0.56676864532.issue34482@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
pull_requests: +8355

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34482>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:12:27 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 18:12:27 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1535047947.61.0.56676864532.issue34480@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report.

HTMLParser.error() was supposed to raise an exception, but the BeautifulSoup project just prints a warning here:

    def error(self, msg):
        warnings.warn(msg)

https://bazaar.launchpad.net/~leonardr/beautifulsoup/bs4/view/head:/bs4/builder/_htmlparser.py#L69

As a result of this, the code doesn't stop executing in the following branch:

    else:
        self.error('unknown status keyword %r in marked section' % rawdata[i+3:j])
    if not match:
        return -1

https://github.com/python/cpython/blob/3.7/Lib/_markupbase.py#L159

Note that HTMLParser.error() was removed in Python 3.5 (https://github.com/python/cpython/commit/73a4359eb0eb624c588c5d52083ea4944f9787ea#diff-1a7486df8279dbac7f20abd487947845L171) and there is an open issue about the status of _markupbase.ParserBase.error(): Issue 31844.

I also think that https://github.com/python/cpython/commit/73a4359eb0eb624c588c5d52083ea4944f9787ea#diff-1a7486df8279dbac7f20abd487947845L171 may have caused a minor regression when it was removed the error() method and its uses from the HTMLParser class. It still calls the parse_marked_section() method of _markupbase.ParserBase() which it then calls the error() method of _markupbase.ParserBase():

    elif rawdata[i:i+3] == '<![':
        return self.parse_marked_section(i)

https://github.com/python/cpython/blob/3.7/Lib/html/parser.py#L264

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:12:56 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 18:12:56 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1535047976.79.0.56676864532.issue34480@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
status:  -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:13:11 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 18:13:11 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1535047991.73.0.56676864532.issue34480@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
Removed message: https://bugs.python.org/msg323967

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:16:08 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 18:16:08 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1535048168.95.0.56676864532.issue31844@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

After triaging issue 34480, I realized that we can't simply remove the error() method because the _markupbase.ParserBase() class still uses it. I've just closed PR 8562.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:18:40 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 18:18:40 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1535048320.36.0.56676864532.issue31844@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:29:27 2018
From: report at bugs.python.org (Matt Tuttle)
Date: Thu, 23 Aug 2018 18:29:27 +0000
Subject: [issue34473] pip is unusable on Windows 10 1803 - SHA-1 certificates
 are untrusted
In-Reply-To: <1535031382.08.0.56676864532.issue34473@psf.upfronthosting.co.za>
Message-ID: <1535048967.48.0.56676864532.issue34473@psf.upfronthosting.co.za>


Matt Tuttle <mtuttle at aha-net.org> added the comment:

It was a firewall issue that affected pip and conda in the same way.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34473>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:30:51 2018
From: report at bugs.python.org (Matt Tuttle)
Date: Thu, 23 Aug 2018 18:30:51 +0000
Subject: [issue34473] pip is unusable on Windows 10 1803 - SHA-1 certificates
 are untrusted
In-Reply-To: <1535039290.33.0.56676864532.issue34473@psf.upfronthosting.co.za>
Message-ID: <BYAPR04MB4071483BCA4B317CF84A3DD2F1370@BYAPR04MB4071.namprd04.prod.outlook.com>


Matt Tuttle <mtuttle at aha-net.org> added the comment:

Thanks Steve, you were right it is a firewall issue that impacted both pip and conda simultaneously. ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34473>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:31:53 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 18:31:53 +0000
Subject: [issue32876] HTMLParser raises exception on some inputs
In-Reply-To: <1519069936.36.0.467229070634.issue32876@psf.upfronthosting.co.za>
Message-ID: <1535049113.33.0.56676864532.issue32876@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Issue 34480 is another relevant issue. The HTMLParse method doesn't have an error() method and it doesn't raise any exceptions, but its base class still does. I think there is a compatibility problem between html.parser.HTMLParser() and _markupbase.ParserBase() classes. See https://bugs.python.org/msg323966 for more details about this.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32876>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:32:42 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 23 Aug 2018 18:32:42 +0000
Subject: [issue34423] Overflow when casting from double to time_t,
 and_PyTime_t.
In-Reply-To: <1534543009.21.0.56676864532.issue34423@psf.upfronthosting.co.za>
Message-ID: <1535049162.58.0.56676864532.issue34423@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34423>
_______________________________________

From report at bugs.python.org  Thu Aug 23 14:36:03 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 23 Aug 2018 18:36:03 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535049363.86.0.56676864532.issue34481@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Thu Aug 23 15:23:29 2018
From: report at bugs.python.org (Matt Tuttle)
Date: Thu, 23 Aug 2018 19:23:29 +0000
Subject: [issue34473] pip is unusable on Windows 10 1803 - SHA-1 certificates
 are untrusted
In-Reply-To: <1535039290.33.0.56676864532.issue34473@psf.upfronthosting.co.za>
Message-ID: <BYAPR04MB4071AA936984346F72D06476F1370@BYAPR04MB4071.namprd04.prod.outlook.com>


Matt Tuttle <mtuttle at aha-net.org> added the comment:

Yep. You are right it is a firewall issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34473>
_______________________________________

From report at bugs.python.org  Thu Aug 23 16:15:10 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 23 Aug 2018 20:15:10 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535055310.15.0.56676864532.issue34468@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think your second proposal sounds about right, Alexey.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Thu Aug 23 16:37:31 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Aug 2018 20:37:31 +0000
Subject: [issue33187] Document ElementInclude (XInclude) support in ElementTree
In-Reply-To: <1522427694.7.0.467229070634.issue33187@psf.upfronthosting.co.za>
Message-ID: <1535056651.01.0.56676864532.issue33187@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33187>
_______________________________________

From report at bugs.python.org  Thu Aug 23 16:42:40 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 23 Aug 2018 20:42:40 +0000
Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format
In-Reply-To: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za>
Message-ID: <1535056960.94.0.56676864532.issue27195@psf.upfronthosting.co.za>


Zackery Spytz <zspytz at gmail.com> added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27195>
_______________________________________

From report at bugs.python.org  Thu Aug 23 16:59:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 20:59:55 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1535057995.31.0.56676864532.issue26901@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8356

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26901>
_______________________________________

From report at bugs.python.org  Thu Aug 23 17:01:07 2018
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 23 Aug 2018 21:01:07 +0000
Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format
In-Reply-To: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za>
Message-ID: <1535058067.33.0.56676864532.issue27195@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

PyBUF_RECORDS pulls in PyBUF_STRIDES, which should IMO not be done in a stable release.

Maybe (PyBUF_CONTIG_RO|PyBUF_FORMAT), but I'm uneasy even about that. The potential for breakage is huge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27195>
_______________________________________

From report at bugs.python.org  Thu Aug 23 17:01:13 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 23 Aug 2018 21:01:13 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1535058073.86.0.56676864532.issue30717@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30717>
_______________________________________

From report at bugs.python.org  Thu Aug 23 17:14:39 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Aug 2018 21:14:39 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
Message-ID: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The Unicode HOWTO currently has contains this text in the "Files in an Unknown Encoding" section [1]:

> The surrogateescape error handler will decode any non-ASCII bytes as code
> points in the Unicode Private Use Area ranging from U+DC80 to U+DCFF. These
> private code points will then be turned back into the same bytes when the
> surrogateescape error handler is used when encoding the data and writing it
> back out.

Unless I'm missing something, the subrange U+DC80 to U+DCFF of the low surrogates is *not* a Private Use Area. There *is* a kinda-sorta PUA in the high surrogates from U+DB80 to U+DBFF (because the only valid codepoints that use these surrogates in their UTF-16 encoding are the codepoints in planes 15 and 16, which are almost entirely PUA codepoints), but that's not what the surrogateescape handler is using.


[1] https://docs.python.org/3/howto/unicode.html#files-in-an-unknown-encoding

----------
assignee: docs at python
components: Documentation
messages: 323976
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Unicode HOWTO incorrectly refers to Private Use Area for surrogateescape
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34484>
_______________________________________

From report at bugs.python.org  Thu Aug 23 17:24:39 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Aug 2018 21:24:39 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1535059479.73.0.56676864532.issue34484@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For history, this text was introduced as a result of issue #4163.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34484>
_______________________________________

From report at bugs.python.org  Thu Aug 23 17:25:15 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Aug 2018 21:25:15 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1535059515.32.0.56676864532.issue34484@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops. Sorry, that should be #4153.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34484>
_______________________________________

From report at bugs.python.org  Thu Aug 23 18:03:25 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 22:03:25 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535061805.25.0.56676864532.issue34468@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8357
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Thu Aug 23 18:04:21 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 23 Aug 2018 22:04:21 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535061861.93.0.56676864532.issue34468@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you, Brett, I've submitted a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Thu Aug 23 19:44:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 23:44:09 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
Message-ID: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Currently, the code to select the encoding and error handler of sys.stdin, sys.stdout and sys.stderr is run later in Py_Initialize(). I propose to move most of this code into _PyCoreConfig_Read() and add stdio_encoding and stdio_errors to _PyCoreConfig to easily let Python embedders to select the encoding.

Attached PR implements this idea. During Py_Initialize(), the code still reads the LC_CTYPE locale to choose the error handler if stdio_errors is NULL. This check cannot be done earlier, since the LC_CTYPE locale is only set to the user locale in Py_Initialize(): after _PyCoreConfig_Read().

The Py_SetStandardStreamEncoding() function has been added by Nick Coghlan in bpo-16129.

    This new pre-initialization API allows embedding
    applications like Blender to force a particular
    encoding and error handler for the standard IO streams.

----------
messages: 323980
nosy: vstinner
priority: normal
severity: normal
status: open
title: _PyCoreConfig: add stdio_encoding and stdio_errors
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Thu Aug 23 19:45:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2018 23:45:06 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535067906.14.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8358
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Thu Aug 23 19:52:02 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 23:52:02 +0000
Subject: [issue28206] signal.Signals not documented
In-Reply-To: <1474297204.47.0.613989661481.issue28206@psf.upfronthosting.co.za>
Message-ID: <1535068322.11.0.56676864532.issue28206@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28206>
_______________________________________

From report at bugs.python.org  Thu Aug 23 19:54:00 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Aug 2018 23:54:00 +0000
Subject: [issue28069] signalmodule.c does "is" comparisons for SIG_IGN and
 SIG_DFL
In-Reply-To: <1473536959.93.0.176407274769.issue28069@psf.upfronthosting.co.za>
Message-ID: <1535068440.67.0.56676864532.issue28069@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib)
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28069>
_______________________________________

From report at bugs.python.org  Thu Aug 23 20:28:36 2018
From: report at bugs.python.org (Julian Mehnle)
Date: Fri, 24 Aug 2018 00:28:36 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1535070516.21.0.56676864532.issue26467@psf.upfronthosting.co.za>


Change by Julian Mehnle <julian at mehnle.net>:


----------
nosy: +jmehnle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Thu Aug 23 20:45:17 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Aug 2018 00:45:17 +0000
Subject: [issue34483] eval() raises NameError: name '...' is not defined
In-Reply-To: <1535046557.48.0.56676864532.issue34483@psf.upfronthosting.co.za>
Message-ID: <1535071517.78.0.56676864532.issue34483@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I believe you're seeing this: https://docs.python.org/3/reference/executionmodel.html#naming-and-binding

See the paragraph that starts with "Class definition blocks and arguments to exec() and eval() are special in the context of name resolution", and the example that follows it.

Basically, you're running eval() as if it were at class scope. I think (but am not positive) that this statement, from the exec() documentation, also applies to eval(): "Remember that at module level, globals and locals are the same dictionary. If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition."

If so, then eval()'s docs should reference this, too.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34483>
_______________________________________

From report at bugs.python.org  Thu Aug 23 20:49:18 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 24 Aug 2018 00:49:18 +0000
Subject: [issue34483] eval() raises NameError: name '...' is not defined
In-Reply-To: <1535046557.48.0.56676864532.issue34483@psf.upfronthosting.co.za>
Message-ID: <1535071758.48.0.56676864532.issue34483@psf.upfronthosting.co.za>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34483>
_______________________________________

From report at bugs.python.org  Thu Aug 23 22:10:31 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Fri, 24 Aug 2018 02:10:31 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535076631.49.0.56676864532.issue34465@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

I think it should be supported too. How about a list of bytes? eg : [127,0,0,1].. Should that be supported as well?

----------
nosy: +prudvinit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:22:19 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Aug 2018 04:22:19 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535084539.47.0.56676864532.issue34477@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset f6247aac08c1a79d0479145a405718bb76dba434 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34477: Objects/typeobject.c: Add missing NULL check to type_init() (GH-8876)
https://github.com/python/cpython/commit/f6247aac08c1a79d0479145a405718bb76dba434


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:22:29 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:22:29 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535084549.35.0.56676864532.issue34477@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:22:35 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:22:35 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535084555.07.0.56676864532.issue34477@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8360

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:22:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:22:44 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535084564.36.0.56676864532.issue34477@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8361

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:27:55 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Aug 2018 04:27:55 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535084875.57.0.56676864532.issue34474@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 2b824b2538c4a5f9f520c5de8a1eae5a0c181a94 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34474: Python/bltinmodule.c: Add missing NULL check in builtin_sum_impl() (GH-8872)
https://github.com/python/cpython/commit/2b824b2538c4a5f9f520c5de8a1eae5a0c181a94


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:28:02 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:28:02 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535084882.22.0.56676864532.issue34474@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8362

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:28:08 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:28:08 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535084888.68.0.56676864532.issue34474@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8363

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:28:14 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:28:14 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535084894.67.0.56676864532.issue34474@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8364

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:33:13 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Aug 2018 04:33:13 +0000
Subject: [issue18560] builtin_sum() doesn't check return value of
 PyLong_FromLong()
In-Reply-To: <1374850346.2.0.318881980727.issue18560@psf.upfronthosting.co.za>
Message-ID: <1535085193.24.0.56676864532.issue18560@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8365

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18560>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:38:19 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:38:19 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535085499.86.0.56676864532.issue34477@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 609062a23f018f4ffc180a88435d61f871165518 by Miss Islington (bot) in branch '3.7':
closes bpo-34477: Objects/typeobject.c: Add missing NULL check to type_init() (GH-8876)
https://github.com/python/cpython/commit/609062a23f018f4ffc180a88435d61f871165518


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:39:47 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Aug 2018 04:39:47 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535085587.9.0.56676864532.issue34468@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 7ecae3ca0bda3cacf3b0125bae0bc718a17cc071 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34468: Objects/rangeobject.c: Fix an always-false condition in range_repr() (GH-8880)
https://github.com/python/cpython/commit/7ecae3ca0bda3cacf3b0125bae0bc718a17cc071


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:39:54 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:39:54 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535085594.33.0.56676864532.issue34468@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8366

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:39:59 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:39:59 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535085599.88.0.56676864532.issue34468@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:49:33 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:49:33 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535086173.5.0.56676864532.issue34477@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fbe359a5e0b22e96065d24d033bebf27cdb374be by Miss Islington (bot) in branch '3.6':
closes bpo-34477: Objects/typeobject.c: Add missing NULL check to type_init() (GH-8876)
https://github.com/python/cpython/commit/fbe359a5e0b22e96065d24d033bebf27cdb374be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:51:49 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:51:49 +0000
Subject: [issue34477] Objects/typeobject.c: Missing NULL check in type_init()
In-Reply-To: <1535035939.28.0.56676864532.issue34477@psf.upfronthosting.co.za>
Message-ID: <1535086309.9.0.56676864532.issue34477@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ea21206626d0907e0ecfd3efbb186f14f1a8a5d4 by Miss Islington (bot) in branch '2.7':
closes bpo-34477: Objects/typeobject.c: Add missing NULL check to type_init() (GH-8876)
https://github.com/python/cpython/commit/ea21206626d0907e0ecfd3efbb186f14f1a8a5d4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34477>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:56:02 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 24 Aug 2018 04:56:02 +0000
Subject: [issue31861] aiter() and anext() built-in functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1535086562.6.0.56676864532.issue31861@psf.upfronthosting.co.za>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
keywords: +patch
pull_requests: +8368
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:57:32 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 24 Aug 2018 04:57:32 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1535086652.14.0.56676864532.issue31861@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

Updating the issue title to reflect the decision to add these to the operator module rather than to built-ins.

Submitted a PR here: https://github.com/python/cpython/pull/8895

----------
title: aiter() and anext() built-in functions -> add aiter() and anext() functions to operator module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Aug 24 00:59:19 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 04:59:19 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535086759.52.0.56676864532.issue34474@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a59036365b304d43bba0f050fa9a7d76100e0ae1 by Miss Islington (bot) in branch '3.7':
closes bpo-34474: Python/bltinmodule.c: Add missing NULL check in builtin_sum_impl() (GH-8872)
https://github.com/python/cpython/commit/a59036365b304d43bba0f050fa9a7d76100e0ae1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 01:11:00 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 05:11:00 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535087460.75.0.56676864532.issue34474@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7d470f3f24d0c091cf1da4f13695c6bb3200a713 by Miss Islington (bot) in branch '3.6':
closes bpo-34474: Python/bltinmodule.c: Add missing NULL check in builtin_sum_impl() (GH-8872)
https://github.com/python/cpython/commit/7d470f3f24d0c091cf1da4f13695c6bb3200a713


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 01:13:21 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 05:13:21 +0000
Subject: [issue34474] Python/bltinmodule.c: Missing NULL check in
 builtin_sum_impl()
In-Reply-To: <1535033054.32.0.56676864532.issue34474@psf.upfronthosting.co.za>
Message-ID: <1535087601.86.0.56676864532.issue34474@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 45ee452751d095d665717bafb61cfd7c65b729b4 by Miss Islington (bot) in branch '2.7':
closes bpo-34474: Python/bltinmodule.c: Add missing NULL check in builtin_sum_impl() (GH-8872)
https://github.com/python/cpython/commit/45ee452751d095d665717bafb61cfd7c65b729b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34474>
_______________________________________

From report at bugs.python.org  Fri Aug 24 01:31:37 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Aug 2018 05:31:37 +0000
Subject: [issue18560] builtin_sum() doesn't check return value of
 PyLong_FromLong()
In-Reply-To: <1374850346.2.0.318881980727.issue18560@psf.upfronthosting.co.za>
Message-ID: <1535088697.33.0.56676864532.issue18560@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Backported to 2.7 in 67dafd5c202cd529e209bf3f35e022ce766709eb. (I messed up the commit message.)

----------
nosy: +benjamin.peterson
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18560>
_______________________________________

From report at bugs.python.org  Fri Aug 24 01:34:09 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 05:34:09 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535088849.75.0.56676864532.issue34468@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d9e1abf8d36da19f074f16046c4a9b5fe54cc083 by Miss Islington (bot) in branch '3.7':
closes bpo-34468: Objects/rangeobject.c: Fix an always-false condition in range_repr() (GH-8880)
https://github.com/python/cpython/commit/d9e1abf8d36da19f074f16046c4a9b5fe54cc083


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Fri Aug 24 01:45:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 05:45:44 +0000
Subject: [issue34468] An always-false condition in range_repr() from
 Objects/rangeobject.c
In-Reply-To: <1534982234.29.0.56676864532.issue34468@psf.upfronthosting.co.za>
Message-ID: <1535089543.99.0.56676864532.issue34468@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 902f1618388280eeeb3957b273f0ccb3df938723 by Miss Islington (bot) in branch '3.6':
closes bpo-34468: Objects/rangeobject.c: Fix an always-false condition in range_repr() (GH-8880)
https://github.com/python/cpython/commit/902f1618388280eeeb3957b273f0ccb3df938723


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34468>
_______________________________________

From report at bugs.python.org  Fri Aug 24 06:28:43 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Aug 2018 10:28:43 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <9a2bf6f5-2270-2900-3955-d53557cc140f@felt.demon.nl>
Message-ID: <9e38ed86-5f28-efc0-8916-7f1d8479db16@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 23/08/2018 19:14, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> On 23/08/2018 12:51, STINNER Victor wrote:
>> STINNER Victor <vstinner at redhat.com> added the comment:
>>
>> Your issue is about decoding command line argument which is done from main() function. It doesn't use Python codecs, but functions like Py_DecodeLocale().
> This is beyond my understanding atm.
> Early on I tried making the expected just be 'arg' and went from
> situation A to situation B - which looked much closer, BUT, the 'types'
> differed:
>
> Situaltion A (original)
> AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
> - ['h\xc3\xa9\xe2\x82\xac']
> + ['h\udcc3\udca9\udce2\udc82\udcac']
>  : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']
>
> I tried saying the "expected" is arg, but arg is still a byte object, the cmd_line result is not (printed as such).
>
> Situation B
> AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "[b'h\\xc3\\xa9\\xe2\\x82\\xac']"
> - ['h\xc3\xa9\xe2\x82\xac']
> + [b'h\xc3\xa9\xe2\x82\xac']
> ?  +
>  : ISO8859-1:['h\xc3\xa9\xe2\x82\xac']
>
> After further digging - to understand why it was coming as "\x encoding rather than \udc"
>
> I looked at what was happening here:
>
> out = self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
> becomes
> out = self.get_output('-X', utf8_opt, '-c', code, 'h\xe9\u20ac'.encode('utf-8'), **kw)
> becomes
> out = self.get_output('-X', utf8_opt, '-c', code, b'h\xc3\xa9\xe2\x82\xac', **kw)
>
> And finally, at the CLI becomes:
> ['/data/prj/python/python3-3.8/python', '-X', 'faulthandler', '-X', 'utf8', '-c', 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))', b'h\xc3\xa9\xe2\x82\xac']
>
> /data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.ar
> gv[1:])))', b'h\xc3\xa9\xe2\x82\xac'
> UTF-8:['bh\\xc3\\xa9\\xe2\\x82\\xac']
>
> /data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.
> argv[1:])))', b'h\xc3\xa9\xe2\x82\xac'
> ISO8859-1:['bh\\xc3\\xa9\\xe2\\x82\\xac']
>
> Note:
> /data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.
> argv[1:])))', 'h\udcc3\udca9\udce2\udc82\udcac'
> ISO8859-1:['h\\udcc3\\udca9\\udce2\\udc82\\udcac']
>
> /data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.
> argv[1:])))', b'h\udcc3\udca9\udce2\udc82\udcac'
> ISO8859-1:['bh\\udcc3\\udca9\\udce2\\udc82\\udcac']
>
> root at x066:[/data/prj/python/python3-3.8]/data/prj/python/python3-3.8/python '-X' 'faulthandler' '-X' 'utf8' '-c' 'import locale, sys; print("%s:%s" % (>
> UTF-8:['bh\\udcc3\\udca9\\udce2\\udc82\\udcac']
>
> Summary:
> a) concerned about how b'h....' becomes 'bh....'
> b) whatwever argv[1] is, is very close to what is returned - so whatever happens durinf the transformation from 
> self.get_output('-X', utf8_opt, '-c', code, arg, **kw)
>  determines the output and the (failed) comparison.
p.s. also tried:
michael at x071:[/data/prj/python/git/python3-3.8]/data/prj/python/python3-3.8/python
'-X' 'faulthandler' '-X' 'utf8=0' '-c' 'import locale, sys;
print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))',
'h\xe9\u20ac'.encode\('utf-8'\)
ISO8859-1:['h\\xe9\\u20ac.encode(utf-8)']
michael at x071:[/data/prj/python/git/python3-3.8]/data/prj/python/python3-3.8/python
'-X' 'faulthandler' '-X' 'utf8=1' '-c' 'import locale, sys;
print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))',
'h\xe9\u20ac'.encode\('utf-8'\)
UTF-8:['h\\xe9\\u20ac.encode(utf-8)']

Really unclear to me what this test is trying to verify. The CLI seems
to just 'echo' what it is provided.
>>> Question 1: why is windows excluded? Because it does not use UTF-8 as it's default (it's default is CP1252)
>> Windows uses wmain() which gets command line arguments as wchar_t* strings: Unicode. No decoding is needed.
>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue34347>
>> _______________________________________
>>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34347>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Fri Aug 24 07:18:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 24 Aug 2018 11:18:08 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1535109488.31.0.56676864532.issue31861@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Great, thanks! There's someone working on a pr to add them as builtins (so that pr is in C). I'll have to take a look when i'm back from vacation at that pr too, before we can make a decision. 

I've been to europython, pycon ru, and pybay conferences recently and the number of people who want these as builtins was surprisingly high.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:02:35 2018
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Skonieczny_=28Uosiu=29?=)
Date: Fri, 24 Aug 2018 14:02:35 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
Message-ID: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>


New submission from Stanis?aw Skonieczny (Uosiu) <stanislaw.skonieczny at gmail.com>:

Sometimes when thread is starting it raises "RuntimeError: release unlocked lock". That is when signal handler is invoked in the same time.

Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 551, in wait
    signaled = self._cond.wait(timeout)
  File "/usr/lib/python3.6/threading.py", line 304, in wait
    self._acquire_restore(saved_state)
  File "start_threads.py", line 12, in sighandler
    raise MyException("got signal")
__main__.MyException: got signal

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "start_threads.py", line 28, in <module>
    thread.start()
  File "/usr/lib/python3.6/threading.py", line 851, in start
    self._started.wait()
  File "/usr/lib/python3.6/threading.py", line 552, in wait
    return signaled
  File "/usr/lib/python3.6/threading.py", line 243, in __exit__
    return self._lock.__exit__(*args)
RuntimeError: release unlocked lock

I have attached to files that reproduce the problem. First runs python and starts noop threads in the loop. It uses signal handler that raises exception. Second is a bash script to run python script and send signal to it. After some time, when signal is handled in unfortunate place, python script breaks due to unreleased lock.

----------
components: Library (Lib)
files: start_threads.py
messages: 323998
nosy: Stanis?aw Skonieczny (Uosiu)
priority: normal
severity: normal
status: open
title: "RuntimeError: release unlocked lock" when starting a thread
versions: Python 3.6
Added file: https://bugs.python.org/file47761/start_threads.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:03:41 2018
From: report at bugs.python.org (=?utf-8?q?Stanis=C5=82aw_Skonieczny_=28Uosiu=29?=)
Date: Fri, 24 Aug 2018 14:03:41 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1535119421.22.0.56676864532.issue34486@psf.upfronthosting.co.za>


Stanis?aw Skonieczny (Uosiu) <stanislaw.skonieczny at gmail.com> added the comment:

This scripts runs start_threads.py and send a signal to it. After some number of loops problem can be reproduced.

----------
Added file: https://bugs.python.org/file47762/test.sh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:18:08 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 24 Aug 2018 14:18:08 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535120288.71.0.56676864532.issue6700@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 91cb298f811961277fd4cc4a32211899d48bedcb by Tal Einat (Vladimir Matveev) in branch 'master':
bpo-6700: Fix inspect.getsourcelines for module level frames/tracebacks (GH-8864)
https://github.com/python/cpython/commit/91cb298f811961277fd4cc4a32211899d48bedcb


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:18:14 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 14:18:14 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535120294.56.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8369

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:18:20 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 14:18:20 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535120300.71.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8370

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:25:51 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Aug 2018 14:25:51 +0000
Subject: [issue33569] dataclasses InitVar does not maintain any type info
In-Reply-To: <1526647195.4.0.682650639539.issue33569@psf.upfronthosting.co.za>
Message-ID: <1535120751.16.0.56676864532.issue33569@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Can you create a pull request? It's easier to review that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33569>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:40:15 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 24 Aug 2018 14:40:15 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535121615.75.0.56676864532.issue6700@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +8371

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:41:43 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 14:41:43 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535121703.37.0.56676864532.issue6700@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0e707b4c6a47086d8e723c7a010c3f5cf8296946 by Miss Islington (bot) in branch '3.6':
bpo-6700: Fix inspect.getsourcelines for module level frames/tracebacks (GH-8864)
https://github.com/python/cpython/commit/0e707b4c6a47086d8e723c7a010c3f5cf8296946


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:44:31 2018
From: report at bugs.python.org (Gerrit Holl)
Date: Fri, 24 Aug 2018 14:44:31 +0000
Subject: [issue34487] enum _sunder_ names mix metaclass and enum class
 attributes
Message-ID: <1535121871.11.0.56676864532.issue34487@psf.upfronthosting.co.za>


New submission from Gerrit Holl <gerrit.holl at gmail.com>:

In the [`enum` module](https://docs.python.org/3/library/enum.html#supported-sunder-names) documentation, some of the `_sunder_` names are on `EnumMeta`, whereas others are on the produced `Enum` class:

> 8.13.15.3.2. Supported `_sunder_` names

> * `_name_` ? name of the member
> * `_value_` ? value of the member; can be set / modified in __new__
> * `_missing_` ? a lookup function used when a value is not found; may be overridden
> * `_ignore_` ? a list of names, either as a list() or a str(), that will not be transformed into members, and will be removed from the final class
> * `_order_` ? used in Python 2/3 code to ensure member order is consistent (class attribute, removed during class creation)
> * `_generate_next_value_` ? used by the Functional API and by auto to get an appropriate value for an enum member; may be overridden

Experimentally, it appears `_name_` and `_value_` are on the `Enum` class, whereas the others are all on the `EnumMeta` class:

In [272]: class Test(enum.Enum): a = 0

In [273]: Test.a._name_
Out[273]: 'a'

In [274]: Test._name
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-274-8d4f758e0fb7> in <module>()
----> 1 Test._name

/group_workspaces/cems2/fiduceo/Users/gholl/anaconda3/envs/FCDR37a/lib/python3.7/enum.py in __getattr__(cls, name)
    344             return cls._member_map_[name]
    345         except KeyError:
--> 346             raise AttributeError(name) from None
    347 
    348     def __getitem__(cls, name):

AttributeError: _name

In [275]: Test.a._value_
Out[275]: 0

In [276]: Test._value
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-276-a1cd5032d83d> in <module>()
----> 1 Test._value

/group_workspaces/cems2/fiduceo/Users/gholl/anaconda3/envs/FCDR37a/lib/python3.7/enum.py in __getattr__(cls, name)
    344             return cls._member_map_[name]
    345         except KeyError:
--> 346             raise AttributeError(name) from None
    347 
    348     def __getitem__(cls, name):

AttributeError: _value

In [277]: Test.a._missing_
Out[277]: <bound method Enum._missing_ of <enum 'Test'>>

In [278]: Test._missing_
Out[278]: <bound method Enum._missing_ of <enum 'Test'>>


This is not clear from the documentation.

----------
assignee: docs at python
components: Documentation
messages: 324003
nosy: Gerrit.Holl, docs at python
priority: normal
severity: normal
status: open
title: enum _sunder_ names mix metaclass and enum class attributes
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34487>
_______________________________________

From report at bugs.python.org  Fri Aug 24 10:44:50 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 14:44:50 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535121890.05.0.56676864532.issue6700@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3e6020c4ddf7acea91efdae770320c6ce06b93db by Miss Islington (bot) in branch '3.7':
bpo-6700: Fix inspect.getsourcelines for module level frames/tracebacks (GH-8864)
https://github.com/python/cpython/commit/3e6020c4ddf7acea91efdae770320c6ce06b93db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Fri Aug 24 11:52:29 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 24 Aug 2018 15:52:29 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1535125949.56.0.56676864532.issue31861@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Aug 24 11:53:23 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 24 Aug 2018 15:53:23 +0000
Subject: [issue34471] _datetime: Missing NULL check in
 tzinfo_from_isoformat_results()
In-Reply-To: <1535019280.96.0.56676864532.issue34471@psf.upfronthosting.co.za>
Message-ID: <1535126003.35.0.56676864532.issue34471@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 498845368ff0f6238750ab1d443e7cf4ec98ccd2 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34471: _datetime: Add missing NULL check to tzinfo_from_isoformat_results. (GH-8869)
https://github.com/python/cpython/commit/498845368ff0f6238750ab1d443e7cf4ec98ccd2


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34471>
_______________________________________

From report at bugs.python.org  Fri Aug 24 11:53:27 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 15:53:27 +0000
Subject: [issue34471] _datetime: Missing NULL check in
 tzinfo_from_isoformat_results()
In-Reply-To: <1535019280.96.0.56676864532.issue34471@psf.upfronthosting.co.za>
Message-ID: <1535126007.95.0.56676864532.issue34471@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8372

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34471>
_______________________________________

From report at bugs.python.org  Fri Aug 24 12:14:01 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 16:14:01 +0000
Subject: [issue34471] _datetime: Missing NULL check in
 tzinfo_from_isoformat_results()
In-Reply-To: <1535019280.96.0.56676864532.issue34471@psf.upfronthosting.co.za>
Message-ID: <1535127241.91.0.56676864532.issue34471@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c7f543520161b895796a571881da74e805d0b1eb by Miss Islington (bot) in branch '3.7':
closes bpo-34471: _datetime: Add missing NULL check to tzinfo_from_isoformat_results. (GH-8869)
https://github.com/python/cpython/commit/c7f543520161b895796a571881da74e805d0b1eb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34471>
_______________________________________

From report at bugs.python.org  Fri Aug 24 12:15:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Aug 2018 16:15:46 +0000
Subject: [issue34456] pickle: Missing NULL check in save_global()
In-Reply-To: <1534893326.11.0.56676864532.issue34456@psf.upfronthosting.co.za>
Message-ID: <1535127346.93.0.56676864532.issue34456@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

We don't bother to fix low probably bugs in 2.7 if the code is too different from 3.x. But if you create a PR it will be merged. Seems this should be a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34456>
_______________________________________

From report at bugs.python.org  Fri Aug 24 12:17:22 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Aug 2018 16:17:22 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1535127442.78.0.56676864532.issue34448@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 3738fadc670274ecc4649f51b52a93602820a375 by Berker Peksag (Michael Osipov) in branch 'master':
bpo-34448: Improve output of usable wchar_t check (GH-8846)
https://github.com/python/cpython/commit/3738fadc670274ecc4649f51b52a93602820a375


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Fri Aug 24 12:17:30 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 16:17:30 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1535127450.41.0.56676864532.issue34448@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8373

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Fri Aug 24 12:30:52 2018
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 24 Aug 2018 16:30:52 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1535128252.86.0.56676864532.issue31861@psf.upfronthosting.co.za>


Joshua Bronson <jabronson at gmail.com> added the comment:

Interesting, thanks Yury!

I only saw the discussion here which implied these wouldn't go directly into builtins for 3.8 (and I searched here and in GitHub, and couldn't find the PR you mentioned either), so I'm curious if that was tracked somewhere. It'd be unfortunate if the work I did on that PR couldn't be used, but I'd be even happier to have these as builtins.

Thanks again for reviewing when you're back, and have a wonderful vacation in the meantime!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Aug 24 12:36:32 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Aug 2018 16:36:32 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1535128592.95.0.56676864532.issue34448@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4973f767891e8eb14925a58313085e14cf6ea621 by Miss Islington (bot) in branch '3.7':
bpo-34448: Improve output of usable wchar_t check (GH-8846)
https://github.com/python/cpython/commit/4973f767891e8eb14925a58313085e14cf6ea621


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Fri Aug 24 13:55:50 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Fri, 24 Aug 2018 17:55:50 +0000
Subject: [issue34488] improve performance of BytesIO.writelines() by avoiding
 creation of unused PyLongs
Message-ID: <1535133350.73.0.56676864532.issue34488@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

Currently BytesIO.writelines() uses BytesIO.write() which returns number of written bytes as Python ints, but these ints are not used by BytesIO.writelines(), so avoiding creation of these ints can improve performance of BytesIO.writelines() especially for a large number of small lines.

Benchmarks:

python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from io import BytesIO; lines = [b'']*10000;" "BytesIO().writelines(lines)"                                          
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 153 us +- 3 us
/home/sergey/tmp/cpython-venv/bin/python: ..................... 126 us +- 4 us

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 153 us +- 3 us -> [/home/sergey/tmp/cpython-venv/bin/python] 126 us +- 4 us: 1.22x faster (-18%)

python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from io import BytesIO; lines = [b'b']*10000;" "BytesIO().writelines(lines)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 164 us +- 2 us
/home/sergey/tmp/cpython-venv/bin/python: ..................... 142 us +- 1 us

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 164 us +- 2 us -> [/home/sergey/tmp/cpython-venv/bin/python] 142 us +- 1 us: 1.16x faster (-13%)

python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from io import BytesIO; lines = [b'b'*10]*10000;" "BytesIO().writelines(lines)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 387 us +- 6 us
/home/sergey/tmp/cpython-venv/bin/python: ..................... 365 us +- 8 us

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 387 us +- 6 us -> [/home/sergey/tmp/cpython-venv/bin/python] 365 us +- 8 us: 1.06x faster (-5%)

python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from io import BytesIO; lines = [b'b'*100]*10000;" "BytesIO().writelines(lines)"                                                    
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 319 us +- 5 us
/home/sergey/tmp/cpython-venv/bin/python: ..................... 305 us +- 16 us

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 319 us +- 5 us -> [/home/sergey/tmp/cpython-venv/bin/python] 305 us +- 16 us: 1.04x faster (-4%)

python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from io import BytesIO; lines = [b'b'*1000]*10000;" "BytesIO().writelines(lines)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 1.13 ms +- 0.02 ms
/home/sergey/tmp/cpython-venv/bin/python: ..................... 988 us +- 88 us

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 1.13 ms +- 0.02 ms -> [/home/sergey/tmp/cpython-venv/bin/python] 988 us +- 88 us: 1.14x faster (-12%)

python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from io import BytesIO; lines = [b'b'*10000]*10000;" "BytesIO().writelines(lines)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 38.7 ms +- 0.1 ms
/home/sergey/tmp/cpython-venv/bin/python: ..................... 38.2 ms +- 0.1 ms

Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 38.7 ms +- 0.1 ms -> [/home/sergey/tmp/cpython-venv/bin/python] 38.2 ms +- 0.1 ms: 1.01x faster (-1%)

----------
components: Extension Modules
messages: 324011
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: improve performance of BytesIO.writelines() by avoiding creation of unused PyLongs
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34488>
_______________________________________

From report at bugs.python.org  Fri Aug 24 13:59:50 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Fri, 24 Aug 2018 17:59:50 +0000
Subject: [issue34488] improve performance of BytesIO.writelines() by avoiding
 creation of unused PyLongs
In-Reply-To: <1535133350.73.0.56676864532.issue34488@psf.upfronthosting.co.za>
Message-ID: <1535133590.51.0.56676864532.issue34488@psf.upfronthosting.co.za>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
keywords: +patch
pull_requests: +8374
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34488>
_______________________________________

From report at bugs.python.org  Fri Aug 24 14:02:27 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Aug 2018 18:02:27 +0000
Subject: [issue34448] incomplete/missing message from configure.ac for usable
 wchar_t
In-Reply-To: <1534841426.48.0.56676864532.issue34448@psf.upfronthosting.co.za>
Message-ID: <1535133747.72.0.56676864532.issue34448@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34448>
_______________________________________

From report at bugs.python.org  Fri Aug 24 14:59:31 2018
From: report at bugs.python.org (Christopher Knorowski)
Date: Fri, 24 Aug 2018 18:59:31 +0000
Subject: [issue34470] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534996891.86.0.56676864532.issue34470@psf.upfronthosting.co.za>
Message-ID: <CAALiirUr39rkCj2ak0oqosXmhcKptFUUQv103k3Gfqii8Cr6Pg@mail.gmail.com>


Christopher Knorowski <cknorow at gmail.com> added the comment:

This also happens in python 3.7. following a similar procedure.

On Wed, Aug 22, 2018 at 9:01 PM Zachary Ware <report at bugs.python.org> wrote:

>
> Zachary Ware <zachary.ware at gmail.com> added the comment:
>
> Python 2.7 is nearing end-of-life, its installer scheme is no longer used
> on any other branch, and the maintainer of that installer retired some
> years ago.  If you provide a patch, we can take a look and possibly merge
> it for you, but it's unlikely that this will be picked up by a maintainer
> without a patch to review.
>
> If you would like to try patching it, all the necessary files should be in
> 2.7/Tools/msi, and you can feel free to ask questions here if you get
> stuck.  Good luck!
>
> ----------
> components: +Windows
> nosy: +paul.moore, steve.dower, tim.golden, zach.ware
> priority: normal -> low
> type: compile error -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34470>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34470>
_______________________________________

From report at bugs.python.org  Fri Aug 24 15:43:12 2018
From: report at bugs.python.org (Sergey G. Brester)
Date: Fri, 24 Aug 2018 19:43:12 +0000
Subject: [issue33515] subprocess.Popen on a Windows batch file always acts as
 if shell=True
In-Reply-To: <1526382091.26.0.682650639539.issue33515@psf.upfronthosting.co.za>
Message-ID: <1535139792.0.0.56676864532.issue33515@psf.upfronthosting.co.za>


Change by Sergey G. Brester <serg.brester at sebres.de>:


----------
keywords: +patch
pull_requests: +8375
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33515>
_______________________________________

From report at bugs.python.org  Fri Aug 24 15:44:10 2018
From: report at bugs.python.org (Sergey G. Brester)
Date: Fri, 24 Aug 2018 19:44:10 +0000
Subject: [issue34489] subprocess: execution of batch-files (.cmd/.bat) is
 vulnerable in python for windows / insufficient escape
Message-ID: <1535139850.17.0.56676864532.issue34489@psf.upfronthosting.co.za>


New submission from Sergey G. Brester <serg.brester at sebres.de>:

There is a vulnerability "insufficient escape of special chars for quoting of arguments by exec process" for python-language, if executing windows batch-files (bat/cmd).

### What version of python is affected?
All

### Does this issue reproduce with the latest master?
Yes

### What did you do?
Execution of batch-file using `subprocess` module with arguments containing some special meta-characters.

A recipe for reproducing the error as well as more extensive PoC with additional info (and more lang's affected also):
- https://github.com/sebres/PoC/blob/master/SB-0D-001-win-exec/README.md
A complete runnable program:
- https://github.com/sebres/PoC/blob/master/SB-0D-001-win-exec/test-dump-inv.py

#### A simple example:
```diff
 # invoke exe-file:
 >>> import subprocess
 >>> subprocess.call(['test-dump.exe', 'test&whoami'])
+    `test-dump.exe? `test&whoami?
 # invoke cmd-file:
 >>> subprocess.call(['test-dump.CMD', 'test&whoami'])
-    `test-dump.exe? `test?my_domain\sebres
```
For more "broken" cases, see the result of my test-suite:
- https://github.com/sebres/PoC/blob/master/SB-0D-001-win-exec/results/python.diff

### What did you expect to see?
Arguments are escaped/quoted properly.

### What did you see instead?
Arguments are insufficient escaped/quoted, so it is vulnerable currently.

### Solution:

For possible solution see the github-PR#8906:
- https://github.com/python/cpython/pull/8906 
For algorithm description:
- https://github.com/sebres/PoC/blob/master/SB-0D-001-win-exec/SOLUTION.md
resp. how it was fixed in TCL (C-code):
- https://core.tcl-lang.org/tcl/vdiff?from=core-8-5-branch&to=0-day-21b0629c81 (see the function `BuildCommandLine`)

### Possible similar issues:
bpo-33515

----------
components: Library (Lib), Windows
messages: 324013
nosy: paul.moore, sebres, steve.dower, tim.golden, zach.ware
priority: normal
pull_requests: 8376
severity: normal
status: open
title: subprocess: execution of batch-files (.cmd/.bat) is vulnerable in python for windows / insufficient escape
type: security
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34489>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:03:01 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Fri, 24 Aug 2018 20:03:01 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535140981.23.0.56676864532.issue34453@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

Hi lkcl, can you help me understand why exactly the below IPv6 addresses are invalid?
('1111:2222:3333:4444:5555:6666:00.00.00.00', False)
('1111:2222:3333:4444:5555:6666:000.000.000.000', False)

I pulled the above addresses from your git testcase.

But, below 2 IPv6 addresses are given as valid
('1111:2222:3333:4444:5555:6666:123.123.123.123', True)
('1111:2222:3333:4444:5555::123.123.123.123', True)

I don't see any difference between both. Both of them have IPv4 styled suffixes. According to the code, they are getting converted at runtime. Can you please clarify? 

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:40:22 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Aug 2018 20:40:22 +0000
Subject: [issue20682] test_create_ssl_unix_connection() of test_asyncio failed
 on "x86 Tiger 3.x"
In-Reply-To: <1392771715.34.0.287107007832.issue20682@psf.upfronthosting.co.za>
Message-ID: <1535143222.1.0.56676864532.issue20682@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Inspired by msg211764 I made a PR - which I hope is okay to add here.

If not, a new issue and PR can be made later.

In short: 
   For address family of AF_UNIX or AF_UNIX_CCSID, getsockname() returns 0 if issued before a bind(). The address length is 0. This is always the case for sockets created by socketpair().

That is at least one possible explanation I found.

Have testewd on AIX 6.1 and AIX 7.1 - on AF_UNIX family getsockname() returns 'None' (i.e., transport.get_extra_info('sockname') returns None)

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20682>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:41:34 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Aug 2018 20:41:34 +0000
Subject: [issue20682] test_create_ssl_unix_connection() of test_asyncio failed
 on "x86 Tiger 3.x"
In-Reply-To: <1392771715.34.0.287107007832.issue20682@psf.upfronthosting.co.za>
Message-ID: <1535143294.97.0.56676864532.issue20682@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Ah, leave closed. I'll make a new issue, and reference this one. Sorry for the noise here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20682>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:46:20 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Aug 2018 20:46:20 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
Message-ID: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Inspired by msg211764, issue20682

In short: 
   For address family of AF_UNIX or AF_UNIX_CCSID, getsockname() returns 0 if issued before a bind(). The address length is 0. This is always the case for sockets created by socketpair().

That is at least one possible explanation I found.

Have tested on AIX 6.1 and AIX 7.1 - transport.get_extra_info('sockname') returns None

----------
components: Tests
messages: 324017
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: transport.get_extra_info('sockname') of test_asyncio fails on AIX
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:54:34 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Aug 2018 20:54:34 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1535144074.33.0.56676864532.issue34490@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8377
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:54:34 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Aug 2018 20:54:34 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1535144074.4.0.56676864532.issue34490@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch, patch
pull_requests: +8377, 8378
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Fri Aug 24 16:58:45 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Fri, 24 Aug 2018 20:58:45 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535144325.93.0.56676864532.issue34465@psf.upfronthosting.co.za>


Change by Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com>:


----------
keywords: +patch
pull_requests: +8379
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Fri Aug 24 17:08:46 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 24 Aug 2018 21:08:46 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1535144926.73.0.56676864532.issue34461@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

The normal way to use ElementTree is to import the ElementTree module from the xml.etree package. Why do you think that needs to change? And why do you want to enforce an import of all modules before you even know which of them the users actually wants?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34461>
_______________________________________

From report at bugs.python.org  Fri Aug 24 17:15:18 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 24 Aug 2018 21:15:18 +0000
Subject: [issue34491] _bsddb.c: Missing Py_DECREF() in DB_join()
Message-ID: <1535145318.12.0.56676864532.issue34491@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
components: Extension Modules
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: _bsddb.c: Missing Py_DECREF() in DB_join()
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34491>
_______________________________________

From report at bugs.python.org  Fri Aug 24 17:17:44 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 24 Aug 2018 21:17:44 +0000
Subject: [issue34491] _bsddb.c: Missing Py_DECREF() in DB_join()
Message-ID: <1535145464.73.0.56676864532.issue34491@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8380
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34491>
_______________________________________

From report at bugs.python.org  Fri Aug 24 17:25:41 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 24 Aug 2018 21:25:41 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535145941.8.0.56676864532.issue34453@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

hi prudvi: i have absolutely no idea.  i am simply running test
validators online, which show and confirm that they are correctly
INVALID.  a google search shows a number of IPv6 validators:
https://www.google.co.uk/search?q=ipv6+address+validator

i have absolutely no actual knowledge of what constitutes a valid IPv6
address or not, nor know of any "official" resources.

all i know is: consensus tends to agree that these two addresses
are accepted by the python ipaddress module when they should not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Fri Aug 24 17:29:51 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 24 Aug 2018 21:29:51 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
 using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1535146191.44.0.56676864532.issue6531@psf.upfronthosting.co.za>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Fri Aug 24 18:37:17 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 24 Aug 2018 22:37:17 +0000
Subject: [issue34492] Python/coreconfig.c: Missing NULL check in
 _Py_wstrlist_copy()
Message-ID: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyMem_RawMalloc() is not checked for NULL at https://github.com/python/cpython/blob/ef8861c112ed1dac9351958c121bc24ca4ecdb08/Python/coreconfig.c#L71.

Reported by Svace static analyzer.

----------
components: Interpreter Core
messages: 324021
nosy: berker.peksag, izbyshev, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Python/coreconfig.c: Missing NULL check in _Py_wstrlist_copy()
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Fri Aug 24 18:38:16 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 24 Aug 2018 22:38:16 +0000
Subject: [issue34492] Python/coreconfig.c: Missing NULL check in
 _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535150296.23.0.56676864532.issue34492@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8382
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Fri Aug 24 19:05:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 24 Aug 2018 23:05:49 +0000
Subject: [issue34493] Objects/genobject.c: Missing NULL check in
 compute_cr_origin()
Message-ID: <1535151949.16.0.56676864532.issue34493@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyTuple_New() is not checked for NULL at https://github.com/python/cpython/blob/ef8861c112ed1dac9351958c121bc24ca4ecdb08/Objects/genobject.c#L1130 and then dereferenced.

----------
components: Interpreter Core
messages: 324022
nosy: berker.peksag, izbyshev, njs, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Objects/genobject.c: Missing NULL check in compute_cr_origin()
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34493>
_______________________________________

From report at bugs.python.org  Fri Aug 24 19:07:59 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 24 Aug 2018 23:07:59 +0000
Subject: [issue34493] Objects/genobject.c: Missing NULL check in
 compute_cr_origin()
In-Reply-To: <1535151949.16.0.56676864532.issue34493@psf.upfronthosting.co.za>
Message-ID: <1535152079.78.0.56676864532.issue34493@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8383
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34493>
_______________________________________

From report at bugs.python.org  Fri Aug 24 19:35:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Aug 2018 23:35:00 +0000
Subject: [issue34492] Python/coreconfig.c: Missing NULL check in
 _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535153700.69.0.56676864532.issue34492@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset eb746dbae8b320758ee08f811316d7f283435cc0 by Victor Stinner (Alexey Izbyshev) in branch 'master':
bpo-34492: Python/coreconfig.c: Fix _Py_wstrlist_copy() (GH-8910)
https://github.com/python/cpython/commit/eb746dbae8b320758ee08f811316d7f283435cc0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Fri Aug 24 20:15:33 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Aug 2018 00:15:33 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1535156133.4.0.56676864532.issue1621@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.7, Python 3.8 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1621>
_______________________________________

From report at bugs.python.org  Fri Aug 24 20:19:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Aug 2018 00:19:27 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535156367.2.0.56676864532.issue13312@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Fri Aug 24 20:29:09 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Aug 2018 00:29:09 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535156949.34.0.56676864532.issue13312@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +8384
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Fri Aug 24 20:41:13 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Sat, 25 Aug 2018 00:41:13 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535157673.22.0.56676864532.issue34453@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

According to the RFC ( https://tools.ietf.org/html/rfc4291#section-2.2 ), last four bytes can be an address in the format of IPv4 address. The latter doesn't specify whether leading zeros are permitted or not. For illustration let's look at the implementation of the POSIX function `inet_aton` from Fedora 28, as documented by manual:

> In  all  of the above forms, components of the dotted address can be specified in decimal, octal (with a leading 0), or hexadecimal, with a leading 0X).

But notice that if you prefix a 0 with 0, the value stays the same, so it doesn't hurt not to raise errors if given either of 

1111:2222:3333:4444:5555:6666:00.00.00.00
1111:2222:3333:4444:5555:6666:000.000.000.000

If however you try

1111:2222:3333:4444:5555:6666:000.000.010.000

then the address is ambiguous, so appropriately you get 

AddressValueError: Ambiguous (octal/decimal) value in '010' not permitted in '000.000.010.000' in '1111:2222:3333:4444:5555:6666:000.000.010.000'


I believe the issue is handled correctly.

----------
nosy: +enedil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Fri Aug 24 20:57:50 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 25 Aug 2018 00:57:50 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1535158670.44.0.56676864532.issue31844@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Fri Aug 24 21:05:27 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Aug 2018 01:05:27 +0000
Subject: [issue33569] dataclasses InitVar does not maintain any type info
In-Reply-To: <1526647195.4.0.682650639539.issue33569@psf.upfronthosting.co.za>
Message-ID: <1535159127.94.0.56676864532.issue33569@psf.upfronthosting.co.za>


Eric V. Smith <ericvsmith at gmail.com> added the comment:

test message, please ignore

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33569>
_______________________________________

From report at bugs.python.org  Fri Aug 24 21:08:53 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Aug 2018 01:08:53 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535159333.6.0.56676864532.issue13312@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 76be0fffff8b7dbe649ad4821144461800ffb0d0 by Gregory P. Smith in branch 'master':
bpo-13312: Avoid int underflow in time year. (GH-8912)
https://github.com/python/cpython/commit/76be0fffff8b7dbe649ad4821144461800ffb0d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Fri Aug 24 21:09:04 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 01:09:04 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535159344.11.0.56676864532.issue13312@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8385

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Fri Aug 24 21:09:10 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 01:09:10 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535159350.46.0.56676864532.issue13312@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8386

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Fri Aug 24 21:48:25 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Aug 2018 01:48:25 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535161705.49.0.56676864532.issue34426@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 21:51:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Aug 2018 01:51:57 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1535161917.2.0.56676864532.issue34427@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:00:30 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 25 Aug 2018 02:00:30 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535162430.15.0.56676864532.issue34426@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 09efe49c07e2d5f93b415ead757c87e20cc0026f by Mariatta (Danish Prakash) in branch 'master':
bpo-34426: fix typo (__lltrace__ -> __ltrace__) (GH-8822)
https://github.com/python/cpython/commit/09efe49c07e2d5f93b415ead757c87e20cc0026f


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:00:36 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 02:00:36 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535162436.15.0.56676864532.issue34426@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:00:42 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 02:00:42 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535162442.01.0.56676864532.issue34426@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8388

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:08:01 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 25 Aug 2018 02:08:01 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535162881.56.0.56676864532.issue34426@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:08:03 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Aug 2018 02:08:03 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1535162883.01.0.56676864532.issue34428@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Luke: If and when you have legal code that fails when run with purely with CPython, you can re-open or try an new issue.

----------
nosy: +serhiy.storchaka, terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:14:14 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 02:14:14 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535163254.78.0.56676864532.issue34426@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0dc75f04575a6bfb2b072f62e5233444aea23e89 by Miss Islington (bot) in branch '3.7':
bpo-34426: fix typo (__lltrace__ -> __ltrace__) (GH-8822)
https://github.com/python/cpython/commit/0dc75f04575a6bfb2b072f62e5233444aea23e89


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:15:59 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 25 Aug 2018 02:15:59 +0000
Subject: [issue34426] "__lltrace__"  seems to be wrong ,
 "__ltrace__" is correct in Misc/SpecialBuilds.txt
In-Reply-To: <1534570511.08.0.56676864532.issue34426@psf.upfronthosting.co.za>
Message-ID: <1535163359.36.0.56676864532.issue34426@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset b26fcd6e22b7c150318d555f67b009cedcf5c797 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-34426: fix typo (__lltrace__ -> __ltrace__) (GH-8822)
https://github.com/python/cpython/commit/b26fcd6e22b7c150318d555f67b009cedcf5c797


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34426>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:21:30 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Aug 2018 02:21:30 +0000
Subject: [issue34429] On Windows tempfile.TemporaryFile behaves like
 NamedTemporaryFile
In-Reply-To: <1534590017.91.0.56676864532.issue34429@psf.upfronthosting.co.za>
Message-ID: <1535163690.13.0.56676864532.issue34429@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.4 and 3.5 only get security fixes.

Anyone preparing PR should check that behavior and doc is same on master; I just assumed in setting Versions header.

In the proposed text, it is not clear that 'non' applies to cygwin also.  Instead: "On platforms that are neither Posix nor Cygwin, ..."
Or "On non-Posix, non-Cygwin platforms, ..."

----------
nosy: +terry.reedy
versions: +Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34429>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:28:17 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 02:28:17 +0000
Subject: [issue33550] Sigpipe handling issue should be documented
In-Reply-To: <1526514952.03.0.682650639539.issue33550@psf.upfronthosting.co.za>
Message-ID: <1535164097.61.0.56676864532.issue33550@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +8389
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33550>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:29:01 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 25 Aug 2018 02:29:01 +0000
Subject: [issue33550] Sigpipe handling issue should be documented
In-Reply-To: <1526514952.03.0.682650639539.issue33550@psf.upfronthosting.co.za>
Message-ID: <1535164141.74.0.56676864532.issue33550@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 7b0ed43af55c1e2844aa0ccd5e088b2ddd38dbdb by Mariatta (Miss Islington (bot)) in branch '3.7':
bpo-33550: Warn not to set SIGPIPE to SIG_DFL (GH-6773)
https://github.com/python/cpython/commit/7b0ed43af55c1e2844aa0ccd5e088b2ddd38dbdb


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33550>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:32:02 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 25 Aug 2018 02:32:02 +0000
Subject: [issue33550] Sigpipe handling issue should be documented
In-Reply-To: <1526514952.03.0.682650639539.issue33550@psf.upfronthosting.co.za>
Message-ID: <1535164322.52.0.56676864532.issue33550@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33550>
_______________________________________

From report at bugs.python.org  Fri Aug 24 22:32:27 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Aug 2018 02:32:27 +0000
Subject: [issue34442] zlib module not built on windows
In-Reply-To: <1534776014.27.0.56676864532.issue34442@psf.upfronthosting.co.za>
Message-ID: <1535164347.38.0.56676864532.issue34442@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What precisely does 'running' mean, so that we can try to reproduce?

python -m test.test_zipfile

Runs 208/207 tests in about a minute on the repository debug builds without failure for both 3.8 and 3.7.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34442>
_______________________________________

From report at bugs.python.org  Sat Aug 25 00:22:29 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 04:22:29 +0000
Subject: [issue34491] _bsddb.c: Missing Py_DECREF() in DB_join()
Message-ID: <1535170949.75.0.56676864532.issue34491@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:


New changeset 032e85f3fb6d2e6668d4e860b40525ed6cb8dd69 by Xiang Zhang (Zackery Spytz) in branch '2.7':
bpo-34491: Add missing Py_DECREF() in _bsddb's DB_join() (GH-8909)
https://github.com/python/cpython/commit/032e85f3fb6d2e6668d4e860b40525ed6cb8dd69


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34491>
_______________________________________

From report at bugs.python.org  Sat Aug 25 00:23:25 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 04:23:25 +0000
Subject: [issue34491] _bsddb.c: Missing Py_DECREF() in DB_join()
In-Reply-To: <1535170949.75.0.56676864532.issue34491@psf.upfronthosting.co.za>
Message-ID: <1535171005.83.0.56676864532.issue34491@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34491>
_______________________________________

From report at bugs.python.org  Sat Aug 25 01:26:30 2018
From: report at bugs.python.org (Tyler Reddy)
Date: Sat, 25 Aug 2018 05:26:30 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
Message-ID: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>


New submission from Tyler Reddy <treddy at dal.ca>:

Downstream in NumPy we've noticed that a "sequence" object defined as below will hang (infinite __getitem__ calls) if we try to turn it into an array. The same holds in CPython for converting it to a list:

class OneList:

    def __len__(self):
        # this won't be checked by
        # PySequence_Fast and several
        # over C API calls
        return 1

    def __getitem__(self, x):
        # called indefinitely by
        # i.e., PySequence_Fast
        return 1

Just to confirm -- this is intentional / desired behavior:

list(OneList()) should hang in CPython?

related: 
https://github.com/numpy/numpy/issues/8912
https://github.com/numpy/numpy/pull/11815
https://stackoverflow.com/a/43566241/2942522

----------
messages: 324037
nosy: treddy
priority: normal
severity: normal
status: open
title: simple "sequence" class ignoring __len__
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sat Aug 25 01:53:03 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 05:53:03 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535176383.42.0.56676864532.issue13312@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d5f017bbd65f37ac53fd3c6c439a53155eef2475 by Miss Islington (bot) in branch '3.7':
bpo-13312: Avoid int underflow in time year. (GH-8912)
https://github.com/python/cpython/commit/d5f017bbd65f37ac53fd3c6c439a53155eef2475


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Sat Aug 25 01:53:24 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 05:53:24 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535176404.09.0.56676864532.issue13312@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c47acc2bb1d0a3fb6dda14ced958d272fb2821a6 by Miss Islington (bot) in branch '3.6':
bpo-13312: Avoid int underflow in time year. (GH-8912)
https://github.com/python/cpython/commit/c47acc2bb1d0a3fb6dda14ced958d272fb2821a6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Sat Aug 25 01:54:42 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 25 Aug 2018 05:54:42 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535176482.88.0.56676864532.issue13312@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

OverflowError is now raised for negative values that would trigger a problem and the unittest has been updated to test this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Sat Aug 25 02:22:15 2018
From: report at bugs.python.org (Tatyana)
Date: Sat, 25 Aug 2018 06:22:15 +0000
Subject: [issue34495] excess_args asserts if args == nullptr
Message-ID: <1535178135.11.0.56676864532.issue34495@psf.upfronthosting.co.za>


New submission from Tatyana <tatyana at synopsys.com>:

Since version 3.7 PyTuple_GET_SIZE performs assert(PyTuple_Check(args)); Due to this change, object_new and object_init cannot be called with args == nullptr.

Such behavior breaks existing user's code, particularly a code generated with Swig.

----------
components: Library (Lib)
messages: 324041
nosy: tkrasnukha
priority: normal
pull_requests: 8390
severity: normal
status: open
title: excess_args asserts if args == nullptr
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34495>
_______________________________________

From report at bugs.python.org  Sat Aug 25 02:46:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 06:46:39 +0000
Subject: [issue34495] excess_args asserts if args == nullptr
In-Reply-To: <1535178135.11.0.56676864532.issue34495@psf.upfronthosting.co.za>
Message-ID: <1535179599.79.0.56676864532.issue34495@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

object_new and object_init should not be called with args == NULL. This looks like a bug in the user code.

Even without assert(PyTuple_Check(args)) in PyTuple_GET_SIZE it dereferences the NULL pointer if args == NULL.

Unless there is a code in CPython implementation itself which calls object_new and object_init with args == NULL this issue will be closed as not a bug.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34495>
_______________________________________

From report at bugs.python.org  Sat Aug 25 02:51:30 2018
From: report at bugs.python.org (fralau)
Date: Sat, 25 Aug 2018 06:51:30 +0000
Subject: [issue34496] Argparse library: parse --set type
Message-ID: <1535179890.87.0.56676864532.issue34496@psf.upfronthosting.co.za>


New submission from fralau <laur2035 at yahoo.co.uk>:

With argparse, an common requirement is is that a user may want to pass a series of key/value pairs (a sort of equivalent of **args on the command line). Here is a solution that could be implemented in the standard library with little effort.

This can be done so, e.g.:
    command --set foo=hello bar="hello world" baz=5

With the benefit of experience, this is easy and very intuitive.

This does not require any modification, as the '--set' option can be defined as:  
   nargs='+',
   metavar="KEY=VALUE"

The next step is to parse the resulting list.

See github gist for a trivial implementation: https://gist.github.com/fralau/061a4f6c13251367ef1d9a9a99fb3e8d). 

It might be useful to integrate a helper method to the standard library together with an explanation in the doc on how to do it.

----------
components: Library (Lib)
messages: 324043
nosy: fralau
priority: normal
severity: normal
status: open
title: Argparse library: parse --set type
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34496>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:15:28 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Aug 2018 07:15:28 +0000
Subject: [issue34493] Objects/genobject.c: Missing NULL check in
 compute_cr_origin()
In-Reply-To: <1535151949.16.0.56676864532.issue34493@psf.upfronthosting.co.za>
Message-ID: <1535181328.61.0.56676864532.issue34493@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 8fdd331bbf7e60dd81c02c7077f44c7939e2a05d by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34493: Objects/genobject.c: Add missing NULL check to compute_cr_origin() (GH-8911)
https://github.com/python/cpython/commit/8fdd331bbf7e60dd81c02c7077f44c7939e2a05d


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34493>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:15:45 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 07:15:45 +0000
Subject: [issue34493] Objects/genobject.c: Missing NULL check in
 compute_cr_origin()
In-Reply-To: <1535151949.16.0.56676864532.issue34493@psf.upfronthosting.co.za>
Message-ID: <1535181345.65.0.56676864532.issue34493@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34493>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:26:44 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 07:26:44 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1535182004.01.0.56676864532.issue34486@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +vstinner, xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:27:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 07:27:58 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535182078.33.0.56676864532.issue34171@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c406d5cd74002964a64c3eb7d9e2445a7fd3a03f by Serhiy Storchaka in branch 'master':
bpo-34171: Prevent creating Lib/trace.cover when run the trace module. (GH-8841)
https://github.com/python/cpython/commit/c406d5cd74002964a64c3eb7d9e2445a7fd3a03f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:28:07 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 07:28:07 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535182087.15.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8392

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:36:38 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 07:36:38 +0000
Subject: [issue34493] Objects/genobject.c: Missing NULL check in
 compute_cr_origin()
In-Reply-To: <1535151949.16.0.56676864532.issue34493@psf.upfronthosting.co.za>
Message-ID: <1535182598.44.0.56676864532.issue34493@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 46af206ea4e9d67375559f8c584a996f70b7b7e5 by Miss Islington (bot) in branch '3.7':
closes bpo-34493: Objects/genobject.c: Add missing NULL check to compute_cr_origin() (GH-8911)
https://github.com/python/cpython/commit/46af206ea4e9d67375559f8c584a996f70b7b7e5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34493>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:37:24 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 07:37:24 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535182644.7.0.56676864532.issue34465@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is your use case?

New features can be added only in the developed version.

----------
nosy: +ncoghlan, pmoody, serhiy.storchaka
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:44:32 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 07:44:32 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1535183072.43.0.56676864532.issue34355@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

So this is a dupliate of #34087 and we can close it?

----------
nosy: +inada.naoki, xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:47:25 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 07:47:25 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535183245.57.0.56676864532.issue34171@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 80e9fedcf579537c5bc51ff3c9c18d14d9598564 by Miss Islington (bot) in branch '3.7':
bpo-34171: Prevent creating Lib/trace.cover when run the trace module. (GH-8841)
https://github.com/python/cpython/commit/80e9fedcf579537c5bc51ff3c9c18d14d9598564


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:47:38 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 07:47:38 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1535183258.25.0.56676864532.issue34334@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Sat Aug 25 03:47:44 2018
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Sat, 25 Aug 2018 07:47:44 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535183264.78.0.56676864532.issue34465@psf.upfronthosting.co.za>


J?rn Heissler <launchpad at joern.heissler.de> added the comment:

My use case is parsing binary data. For that I use a bytearray as a buffer. buf[:4] gets me another bytearray which I'd want to convert to an ipaddress.

I can't think of a usecase for list-of-int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Sat Aug 25 04:01:02 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 08:01:02 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535184062.64.0.56676864532.issue34465@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

Why not just bytes(buf[:4]) before passing?

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Sat Aug 25 04:08:23 2018
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Sat, 25 Aug 2018 08:08:23 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535184503.25.0.56676864532.issue34465@psf.upfronthosting.co.za>


J?rn Heissler <launchpad at joern.heissler.de> added the comment:

That's what I'm doing now.
But it would be more convenient if I could pass a bytearray.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Sat Aug 25 04:25:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 08:25:58 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535185558.16.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 04:54:43 2018
From: report at bugs.python.org (Danish Prakash)
Date: Sat, 25 Aug 2018 08:54:43 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1535187283.69.0.56676864532.issue34334@psf.upfronthosting.co.za>


Danish Prakash <grafitykoncept at gmail.com> added the comment:

I would like to work on this, just making sure you are not.

----------
nosy: +prakashdanish

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Sat Aug 25 04:56:59 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 25 Aug 2018 08:56:59 +0000
Subject: [issue34428] tokenize
In-Reply-To: <1534588167.35.0.56676864532.issue34428@psf.upfronthosting.co.za>
Message-ID: <1535187419.35.0.56676864532.issue34428@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

yep good call terry, not getting any response from the
autopep8 developer, and i believe it was down to a loop
where the text is being thrown line-by-line at tokenize
and it was losing critical state information.  so...
not a bug in tokenize.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34428>
_______________________________________

From report at bugs.python.org  Sat Aug 25 04:59:42 2018
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 25 Aug 2018 08:59:42 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535187582.01.0.56676864532.issue34453@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

that's interesting, michael: it means that all of the
IPv6 validators online are wrong, like this one!
https://formvalidation.io/guide/validators/ip/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Sat Aug 25 05:13:51 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Sat, 25 Aug 2018 09:13:51 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
In-Reply-To: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>
Message-ID: <1535188431.86.0.56676864532.issue34494@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

I think it should hang, since we are not throwing any StopIteration exception to break the infinite loop

----------
nosy: +prudvinit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sat Aug 25 05:15:33 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Sat, 25 Aug 2018 09:15:33 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535188533.94.0.56676864532.issue34453@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

I think Michal is right

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Sat Aug 25 05:22:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 09:22:56 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535188976.68.0.56676864532.issue34453@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ncoghlan, pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Sat Aug 25 06:41:14 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 10:41:14 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1535193674.93.0.56676864532.issue23325@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Sat Aug 25 06:42:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 10:42:02 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1535193722.23.0.56676864532.issue34395@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 90555eca44a19c743d39b7fd2e05f7bc37fb5cb8 by Serhiy Storchaka (Sergey Fedoseev) in branch 'master':
bpo-34395: Don't free allocated memory on realloc fail in load_mark() in _pickle.c. (GH-8788)
https://github.com/python/cpython/commit/90555eca44a19c743d39b7fd2e05f7bc37fb5cb8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Sat Aug 25 06:42:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 10:42:58 +0000
Subject: [issue34395] memory leaks in error handling in csv and pickle modules
In-Reply-To: <1534179202.53.0.56676864532.issue34395@psf.upfronthosting.co.za>
Message-ID: <1535193778.06.0.56676864532.issue34395@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report and fix Sergey.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34395>
_______________________________________

From report at bugs.python.org  Sat Aug 25 07:37:26 2018
From: report at bugs.python.org (Dan Snider)
Date: Sat, 25 Aug 2018 11:37:26 +0000
Subject: [issue34497] Remove needless set operator restriction
Message-ID: <1535197046.82.0.56676864532.issue34497@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

I only just now realized that `dict.fromkeys('abc').keys() - 'bc'` returns {'a'} instead of raising an error like {*'abc'} - 'bc' would, which is really quite handy. 

The __xor__, __and__, and __sub__ methods of dict_keys (and items, assuming no there are no unhashable values) work just as set.symmetric_difference, set.intersection, and set.difference do, respectively.

>>> a, b, c, d = [*map(dict.keys, map(dict.fromkeys, 'abcd'))]
>>> ((a | 'a') | (b & 'b') | (c ^ 'c')) - d
{'b', 'a'}
>>> a, b, c, d = [*map(dict.items, map(dict.fromkeys, 'abcd'))]
>>> ((a | 'a') | (b & 'b') | (c ^ 'c')) - d
{'c', ('a', None), 'a', ('c', None)}

However, set objects are arbitrarily restricted to taking a set object for the second argument on these functions. As for the first example here, there is even code specifically there to handle a dictionary as the second argument, but it is unreachable when called through the dunder version. 

{<class 'list'>, <class 'dict'>, <class 'set'>}
>>> {list, set} | dict.fromkeys((dict, set))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'set' and 'dict'

>>> {*'abc'}.difference('cde')
{'b', 'a'}
>>> {*'abc'} - set('cde')
{'b', 'a'}
>>> {*'abc'} - 'cde'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for -: 'set' and 'str'

>>> {1,2,3}.symmetric_difference(b'\x00')
{0, 1, 2, 3}
>>> {1,2,3} ^ b'\x00'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for ^: 'set' and 'bytes'

The sources of set_and, set_sub, and set_xor all look like this. All they do is add a check that the second argument is a set and then simply call the same function their respective non-dunder method uses. They're so identical in fact that set_xor actually calls the exact same C function used in the PyMethodDef for set.symmetric_update:

static PyObject *
set_xor(PySetObject *so, PyObject *other)
{
    if (!PyAnySet_Check(so) || !PyAnySet_Check(other))
        Py_RETURN_NOTIMPLEMENTED;
    return set_symmetric_difference(so, other);
}
static PyMethodDef set_methods[] = {
/* ... */
{"symmetric_difference",(PyCFunction)set_symmetric_difference, 
 METH_O, symmetric_difference_doc},
/* ... */
};

All that's needed to fix this is to remove a total of 106 characters from setobject.c (4 x " || !PyAnySet_Check(other)").

----------
components: Interpreter Core, Library (Lib)
messages: 324060
nosy: bup
priority: normal
severity: normal
status: open
title: Remove needless set operator restriction
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34497>
_______________________________________

From report at bugs.python.org  Sat Aug 25 07:39:17 2018
From: report at bugs.python.org (Dan Snider)
Date: Sat, 25 Aug 2018 11:39:17 +0000
Subject: [issue34497] Remove needless set operator restriction
In-Reply-To: <1535197046.82.0.56676864532.issue34497@psf.upfronthosting.co.za>
Message-ID: <1535197157.23.0.56676864532.issue34497@psf.upfronthosting.co.za>


Change by Dan Snider <mr.assume.away at gmail.com>:


----------
keywords: +patch
pull_requests: +8394
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34497>
_______________________________________

From report at bugs.python.org  Sat Aug 25 08:19:29 2018
From: report at bugs.python.org (Dutcho)
Date: Sat, 25 Aug 2018 12:19:29 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
Message-ID: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>


New submission from Dutcho <dutcho at ziggo.nl>:

In Python 3.6, the argument to the register() method of a single-dispatch function (i.e. a function decorated by @functools.singledispatch) can be a 'type-like' class (pseudo-type?) from e.g. the typing module that supports isinstance().

The below demonstrates it works in Python 3.6:

$ py -3.6
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import singledispatch
>>> from typing import Sequence
>>> isinstance([1,2,3], Sequence) # 'pseudo-type' okay with isinstance
True
>>> @singledispatch
... def f(arg):
...     print('unqualified', arg)
...
>>> @f.register(Sequence) # 'pseudo-type' okay with register
... def _(arg):
...     print('sequence', *arg)
...
>>> f(1)
unqualified 1
>>> f([1,2,3])
sequence 1 2 3

This code breaks in Python 3.7:

$ py
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import singledispatch
>>> from typing import Sequence
>>> isinstance([1,2,3], Sequence) # 'pseudo-type' okay with isinstance
True
>>> @singledispatch
... def f(arg):
...     print('unqualified', arg)
...
>>> @f.register(Sequence)  # 'pseudo-type' NOT okay with register
... def _(arg):
...     print('sequence', *arg)
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Program Files\Python\Python37\lib\functools.py", line 801, in register
    f"Invalid first argument to `register()`: {cls!r}. "
TypeError: Invalid first argument to `register()`: typing.Sequence. Use either `@register(some_class)` or plain `@register` on an annotated function.

While agreeing a check on the register() arg IS required, the current check isinstance(cls, type) seems overly restrictive. This is especially true when considering the (welcome!) Python 3.7 use of annotations for single dispatch functions.

----------
components: Library (Lib)
messages: 324061
nosy: Dutcho
priority: normal
severity: normal
status: open
title: Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Sat Aug 25 08:23:52 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 12:23:52 +0000
Subject: [issue34497] Remove needless set operator restriction
In-Reply-To: <1535197046.82.0.56676864532.issue34497@psf.upfronthosting.co.za>
Message-ID: <1535199832.78.0.56676864532.issue34497@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34497>
_______________________________________

From report at bugs.python.org  Sat Aug 25 08:33:38 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 25 Aug 2018 12:33:38 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535200418.86.0.56676864532.issue34171@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Several buildbots are failing due to commit c406d5cd74002964a64c3eb7d9e2445a7fd3a03f:

https://buildbot.python.org/all/#/builders/40/builds/709
https://buildbot.python.org/all/#/builders/21/builds/1459
https://buildbot.python.org/all/#/builders/13/builds/1476
https://buildbot.python.org/all/#/builders/53/builds/1470
https://buildbot.python.org/all/#/builders/133/builds/477
https://buildbot.python.org/all/#/builders/145/builds/327
https://buildbot.python.org/all/#/builders/85/builds/1302
https://buildbot.python.org/all/#/builders/141/builds/358
https://buildbot.python.org/all/#/builders/126/builds/564
https://buildbot.python.org/all/#/builders/147/builds/213
https://buildbot.python.org/all/#/builders/119/builds/611
https://buildbot.python.org/all/#/builders/116/builds/590
https://buildbot.python.org/all/#/builders/143/builds/233
https://buildbot.python.org/all/#/builders/93/builds/1072
https://buildbot.python.org/all/#/builders/3/builds/1257
https://buildbot.python.org/all/#/builders/32/builds/1331
https://buildbot.python.org/all/#/builders/115/builds/520
https://buildbot.python.org/all/#/builders/128/builds/571
https://buildbot.python.org/all/#/builders/99/builds/1335
https://buildbot.python.org/all/#/builders/121/builds/497
https://buildbot.python.org/all/#/builders/113/builds/540
https://buildbot.python.org/all/#/builders/154/builds/166

Sample error:

======================================================================
FAIL: test_cover_files_written_no_highlight (test.test_trace.TestCoverageCommandLineOutput)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.nondebug/build/Lib/test/test_trace.py", line 393, in test_cover_files_written_no_highlight
    self.assertFalse(os.path.exists(tracecoverpath))
AssertionError: True is not false
----------------------------------------------------------------------
Ran 21 tests in 17.796s
FAILED (failures=1)
test test_trace failed
1 test failed again:
    test_trace

----------
nosy: +pablogsal
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 08:38:48 2018
From: report at bugs.python.org (Dutcho)
Date: Sat, 25 Aug 2018 12:38:48 +0000
Subject: [issue34499] Extend registering of single-dispatch functions to
 parametrized generic pseudo-types
Message-ID: <1535200728.53.0.56676864532.issue34499@psf.upfronthosting.co.za>


New submission from Dutcho <dutcho at ziggo.nl>:

While issue #34498 signalled a break in Python 3.7 of legal Python 3.6 code that registers a single-dispatch function with a 'pseudo-type' like typing.Sequence, both Python 3.6 and Python 3.7 don't work with a 'parametrized pseudo-type' like typing.Sequence[int].
However, to fully benefit from Python 3.7's use of annotations for registering single-dispatch functions, these 'parametrized pseudo-types' should also be acceptable.

E.g. in Python 3.6:
$ py -3.6
Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 27 2018, 03:37:03) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import singledispatch
>>> from typing import Iterable, Sequence, T
>>>
>>> @singledispatch
... def last(iterable: Iterable[T]) -> T:
...     for last in iterable:
...             pass
...     return 'slow', last
...
>>> @last.register(Sequence)
... def _(sequence: Sequence[T]) -> T:
...     return 'fast', sequence[-1]
...
>>> print(*last(iter([1, 2, 3])))
slow 3
>>> print(*last([1, 2, 3]))
fast 3

Note in Python 3.6 no match results if the 'parametrized pseudo-type' Sequence[T] is specified as argument to last.register() as isinstance(..., Sequence[T]) fails.

To fully benefit from Python 3.7's use of annotations for single-dispatch functions, it should
(1) accept 
>>> @last.register
... def _(sequence: Sequence[T]) -> T:
...     return 'fast', sequence[-1]
and (2) remove the T parameter of Sequence for matching when dispatching. I recognize this could potentially create a clash between e.g. Sequence[int] and Sequence[str]

----------
components: Library (Lib)
messages: 324063
nosy: Dutcho
priority: normal
severity: normal
status: open
title: Extend registering of single-dispatch functions to parametrized generic pseudo-types
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34499>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:08:50 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 13:08:50 +0000
Subject: [issue34492] Python/coreconfig.c: Missing NULL check in
 _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535202530.95.0.56676864532.issue34492@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
pull_requests: +8395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:12:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 13:12:56 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535202776.35.0.56676864532.issue34171@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems this is a temporary issue. Tests are failed due to trace.cover files left from previous runs. Recreating the working space from zero should fix the issue, but I don't know how to do this on all buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:17:20 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 25 Aug 2018 13:17:20 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535203040.9.0.56676864532.issue34171@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

@zach.ware Is there a way to clean the workspace of these buildbots programmatically/from the UI? I can do it myself if you tell me how it must be done.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:19:09 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 13:19:09 +0000
Subject: [issue34492] Python/coreconfig.c: Missing NULL check in
 _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535203149.44.0.56676864532.issue34492@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:20:35 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 13:20:35 +0000
Subject: [issue34492] Python/coreconfig.c: Fix _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535203235.72.0.56676864532.issue34492@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
title: Python/coreconfig.c: Missing NULL check in _Py_wstrlist_copy() -> Python/coreconfig.c: Fix _Py_wstrlist_copy()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:28:29 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Aug 2018 13:28:29 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1535203709.81.0.56676864532.issue32973@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think the best work-around for now is to implement a bit of PEP 489, including a module create function that always returns the same static module reference instead of creating a new one after the first call, and a module exec function that simply returns if the module has already been initialised. Keeping a global pointer to the module instance around should work. This is what the current Cython master branch does (also to make use of some of the nice features that PEP 489 brings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32973>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:38:20 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 25 Aug 2018 13:38:20 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535204300.27.0.56676864532.issue34347@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8396
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:40:42 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 25 Aug 2018 13:40:42 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535204442.15.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Solution much simpler than I thought:

not arg.decode('ascii', 'surrogateescape'), but arg.decode('iso-8859-1')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Sat Aug 25 09:54:13 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Sat, 25 Aug 2018 13:54:13 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1535205253.79.0.56676864532.issue32973@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

That's quite problematic, since then you're sharing a mutable object across interpreters.
The user can store any attribute on module objects, including e.g. Python functions that reference their original interpreter's global state, but become callable in other interpreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32973>
_______________________________________

From report at bugs.python.org  Sat Aug 25 10:25:19 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Aug 2018 14:25:19 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1535207119.76.0.56676864532.issue32973@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Well, first of all, it's better than a crash. :)

Secondly, I'm sure NumPy doesn't currently support subinterpreters, just like most other extension modules. If I'm not mistaken, an interpreter switch can be detected through the interpreter state pointer [1] in the thread state, and extension modules that lack subinterpreter support can consider a change an error for them. since then something is trying to re-import the module into a different interpreter. That's not entirely safe since addresses can be reused, which I guess was the reason for adding an ID [2] in Py3.7, but that's only available in Py3.7+, not in Py3.5. So, the interpreter address is probably as good as it gets for Py<3.7.

[1] https://docs.python.org/3/c-api/init.html#c.PyThreadState
[2] https://docs.python.org/3/c-api/init.html#c.PyInterpreterState_GetID

Note: I'm not trying to keep anyone from implementing subinterpreter support here ? just showing a way to keep things working and improving gradually as long as there is no full support for PEP 489, extension module reloading and subinterpreters, so that users don't have to go all the way in one step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32973>
_______________________________________

From report at bugs.python.org  Sat Aug 25 10:33:51 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 25 Aug 2018 14:33:51 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535207631.91.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

It might be as simple as what I saw for AIX:

diff --git a/Lib/test/test_utf8_mode.py b/Lib/test/test_utf8_mode.py
index 26e2e13ec5..3e918fd54c 100644
--- a/Lib/test/test_utf8_mode.py
+++ b/Lib/test/test_utf8_mode.py
@@ -219,6 +219,8 @@ class UTF8ModeTests(unittest.TestCase):
         check('utf8', [arg_utf8])
         if sys.platform == 'darwin' or support.is_android:
             c_arg = arg_utf8
+        elif sys.platform.startswith("aix"):
+            c_arg = arg.decode('iso-8859-1')
         else:
             c_arg = arg_ascii
         check('utf8=0', [c_arg], LC_ALL='C')

so, adding below might be all that is needed:
+        elif sys.platform == "hpux":
+            c_arg = arg.decode('roman8')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Sat Aug 25 11:09:38 2018
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Sat, 25 Aug 2018 15:09:38 +0000
Subject: [issue34500] Fix ResourceWarning in difflib.py
Message-ID: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>


New submission from Micka?l Schoentgen <contact at tiger-222.fr>:

Fix 2 unclosed files in the documentation and the difflib.py script:

diff.py:77: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/tmpnby8pemn' mode='U' encoding='UTF-8'>
    fromlines = open(fromfile, 'U').readlines()
diff.py:78: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/tmpnby8pemm' mode='U' encoding='UTF-8'>
    self.tolines = open(tofile, 'U').readlines()

----------
assignee: docs at python
components: Demos and Tools, Documentation
messages: 324071
nosy: David Bieber, Tiger-222, docs at python
priority: normal
severity: normal
status: open
title: Fix ResourceWarning in difflib.py
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34500>
_______________________________________

From report at bugs.python.org  Sat Aug 25 11:15:23 2018
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Sat, 25 Aug 2018 15:15:23 +0000
Subject: [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535210123.76.0.56676864532.issue34500@psf.upfronthosting.co.za>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
keywords: +patch
pull_requests: +8397
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34500>
_______________________________________

From report at bugs.python.org  Sat Aug 25 11:18:51 2018
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Sat, 25 Aug 2018 15:18:51 +0000
Subject: [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535210331.7.0.56676864532.issue34500@psf.upfronthosting.co.za>


Micka?l Schoentgen <contact at tiger-222.fr> added the comment:

This is a little patch to mostly keep aligned with https://github.com/google/python-fire/pull/135.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34500>
_______________________________________

From report at bugs.python.org  Sat Aug 25 11:26:40 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 15:26:40 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
Message-ID: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

In the following snippet from PyType_FromSpecWithBases() in Objects/typeobject.c, spec->name is dereferenced by strrchr() but then is checked for NULL:

    /* Set the type name and qualname */
    s = strrchr(spec->name, '.');
    if (s == NULL)
        s = (char*)spec->name;
    else
        s++;

    [snip]

    type->tp_name = spec->name;
    if (!type->tp_name)
        goto fail;

This was reported by Svace static analyzer.

If I were to check spec->name first, what error should I report to the caller? Is something like the following OK?

    if (spec->name == NULL) {
        PyErr_SetString(PyExc_SystemError,
                       "Type spec does not define the name field.");
        goto fail;
    }

----------
components: Interpreter Core
messages: 324073
nosy: berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyType_FromSpecWithBases: spec->name is dereferenced before checking for NULL
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 11:55:41 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 25 Aug 2018 15:55:41 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535212541.57.0.56676864532.issue34171@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

No, there isn't.  However, https://github.com/python/buildmaster-config/pull/43 should help; I'll try to get that deployed later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:26:34 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 16:26:34 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1535214394.78.0.56676864532.issue23325@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I'm afraid this could break old codes so not sure it's worth or not. I've seen code like `SIGTERM = 15; signal.signal(SIGTERM, handler)`. I won't be surprised to see a handcraft SIG_DFL/IGN.

----------
nosy: +xiang.zhang
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:33:09 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Sat, 25 Aug 2018 16:33:09 +0000
Subject: [issue34453] ipaddress module accepts some strange IPv6 addresses
 that it shouldn't
In-Reply-To: <1534882978.68.0.56676864532.issue34453@psf.upfronthosting.co.za>
Message-ID: <1535214789.68.0.56676864532.issue34453@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

The point is that the specification is not complete and thus left for the implementations to decide. Python's version hits the sweet spot between inclusive and correct - as long as a version is unambiguous, it is accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34453>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:36:18 2018
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 25 Aug 2018 16:36:18 +0000
Subject: [issue32973] Importing the same extension module under multiple names
 breaks non-reinitialisable extension modules
In-Reply-To: <1519843860.12.0.467229070634.issue32973@psf.upfronthosting.co.za>
Message-ID: <1535214978.11.0.56676864532.issue32973@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

FYI, I've updated Cython's module import checks to include an interpreter check. This (multi-file) test shows the new behaviour, which is to raise an ImportError on module creation when it detects a different interpreter than during the initial import:

https://github.com/cython/cython/blob/master/tests/run/reimport_from_subinterpreter.srctree

The checks are implemented here (and called a bit further down in the module create function):
https://github.com/cython/cython/blob/4ce754271ff4cfbd8df2b278e812154fb1b02319/Cython/Utility/ModuleSetupCode.c#L909-L932

I also added a test that should match the problem discussed here, which makes what I described appear as a viable solution (or work-around):

https://github.com/cython/cython/blob/master/tests/run/reimport_from_package.srctree

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32973>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:47:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Aug 2018 16:47:00 +0000
Subject: [issue34492] Python/coreconfig.c: Fix _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535215620.95.0.56676864532.issue34492@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 388bd4bd7622f6781260ed388f7c76b673adb0e1 by Victor Stinner (Alexey Izbyshev) in branch '3.7':
[3.7] bpo-34492: Modules/main.c: Fix copy_wstrlist() (GH-8910) (GH-8922)
https://github.com/python/cpython/commit/388bd4bd7622f6781260ed388f7c76b673adb0e1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:47:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Aug 2018 16:47:27 +0000
Subject: [issue34492] Python/coreconfig.c: Fix _Py_wstrlist_copy()
In-Reply-To: <1535150237.85.0.56676864532.issue34492@psf.upfronthosting.co.za>
Message-ID: <1535215647.1.0.56676864532.issue34492@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Alexey Izbyshev for the bug report and the fix for 3.7 and master branches!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34492>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:51:48 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Aug 2018 16:51:48 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1535215908.26.0.56676864532.issue32968@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry that I've taken so long to get back to this. I've just updated the PR, and I think it's ready to go. Looks like it does need you to update your GitHub username here in the "Your Details" section of the bugtracker, though; sorry about that.

> If we can't depend on that result, do you have any suggestions?

Yes: check that 1.0 // 1/10 equals 1.0 // 0.1, and similarly for %. I've made that change in the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:52:07 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Aug 2018 16:52:07 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1535215927.65.0.56676864532.issue32968@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Sat Aug 25 12:52:30 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Sat, 25 Aug 2018 16:52:30 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1535215950.89.0.56676864532.issue34498@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

The change is not only in the added `isinstance` check:

~ $ python3.6 -q
>>> import typing
>>> isinstance(typing.Sequence, type)
True
>>>
~ $ python3.7 -q
>>> import typing
>>> isinstance(typing.Sequence, type)
False
>>>

----------
nosy: +enedil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:00:25 2018
From: report at bugs.python.org (Eric Wieser)
Date: Sat, 25 Aug 2018 17:00:25 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
In-Reply-To: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>
Message-ID: <1535216425.69.0.56676864532.issue34494@psf.upfronthosting.co.za>


Change by Eric Wieser <wieser.eric+pybug at gmail.com>:


----------
nosy: +Eric.Wieser

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:14:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 17:14:04 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1535217244.04.0.56676864532.issue34498@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:30:57 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 25 Aug 2018 17:30:57 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1535218257.25.0.56676864532.issue34498@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This is why we have 4 months of betas :-)

On one hand making objects in `typing` module not classes was intentional, but on another hand this use case looks totally fine.

I would say we could update the check in `functools` to accept more things. I am however not sure what to allow here in addition to proper classes, maybe just anything that overrides `__subclasscheck__` and/or `__instancecheck__`? I could imagine there might be some other objects that implement custom instance and class checks beyond `typing` that are rejected by current checks in `functools`.

As a temporary workaround you can use `collections.abc.Sequence`, this type is aliased by `typing.Sequence`, in fact all instance checks etc. are relayed to the former.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:31:35 2018
From: report at bugs.python.org (Eric Wieser)
Date: Sat, 25 Aug 2018 17:31:35 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
In-Reply-To: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>
Message-ID: <1535218295.44.0.56676864532.issue34494@psf.upfronthosting.co.za>


Eric Wieser <wieser.eric+pybug at gmail.com> added the comment:

What I think I find surprising is that I'd expect the sequence protocol to be defined by `__getitem__` and `__len__`, and for `__iter__` to be inferred as:

    def __iter__(self):
        for i in range(len(self)):
            yield self[i]

But in reality it seems it is inferred only from `__getitem__`, as:

    def __iter__(self):
        i = 0
        while True:
            try:
                yield self[i]
            except IndexError:
                return
            i += 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:34:20 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 25 Aug 2018 17:34:20 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1535218460.05.0.56676864532.issue32968@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:42:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Aug 2018 17:42:29 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1535218949.25.0.56676864532.issue23325@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Numerical values of signal numbers are standardized. signal.signal(15, handler) is valid. SIGTERM is just a handy name for the constant 15.

But SIG_DFL and SIG_IGN are not integers in C (they are special pointers), and it is not declared anywhere that they should be integers in Python. The code that converts them to Python integer is implementation depending (PyLong_FromVoidPtr). Handcrafted SIG_DFL and SIG_IGN are broken by design, because the signal module uses identity comparison for SIG_DFL and SIG_IGN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:42:38 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 25 Aug 2018 17:42:38 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535218958.07.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

As the AIX complaint is (was once the PR merges):
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']

And the HP-UX complaint is:
  File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 223, in check
    self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\udcc3\\udca9\\udce2\\udc82\\udcac']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\udcc3\udca9\udce2\udc82\udcac']

Maybe a change such as:

--- a/Lib/test/test_utf8_mode.py
+++ b/Lib/test/test_utf8_mode.py
@@ -219,6 +219,8 @@ class UTF8ModeTests(unittest.TestCase):
         check('utf8', [arg_utf8])
         if sys.platform == 'darwin' or support.is_android:
             c_arg = arg_utf8
+        elif (platform.system == "AIX") or
+              sys.platform.startswith("hp-ux"):
+            c_arg = arg.decode('iso-8859-1')
         else:
             c_arg = arg_ascii
         check('utf8=0', [c_arg], LC_ALL='C')

I mention this because it seems neither roman8 nor roman9 have 'official' iso names or alias (correct me if I am wrong).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:46:32 2018
From: report at bugs.python.org (Augusto Hack)
Date: Sat, 25 Aug 2018 17:46:32 +0000
Subject: [issue33569] dataclasses InitVar does not maintain any type info
In-Reply-To: <1526647195.4.0.682650639539.issue33569@psf.upfronthosting.co.za>
Message-ID: <1535219192.25.0.56676864532.issue33569@psf.upfronthosting.co.za>


Change by Augusto Hack <me at hak.cx>:


----------
keywords: +patch
pull_requests: +8399
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33569>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:54:28 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 17:54:28 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
Message-ID: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

Docs for sys.exit() contain the following note added in https://github.com/python/cpython/blame/1871a4a35123b278443b960255cb14314ce196f6/Doc/library/sys.rst#L336

Changed in version 3.7: Added utf8_mode attribute for the new -X utf8 flag.

Does it belong to the adjacent docs for sys.flags (though they mention utf8_mode too)?

----------
assignee: docs at python
components: Documentation
messages: 324086
nosy: docs at python, izbyshev, vstinner
priority: normal
severity: normal
status: open
title: Docs of sys.exit() mention utf8_mode for an unclear reason
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Sat Aug 25 13:57:27 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 17:57:27 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535219847.94.0.56676864532.issue34502@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8400
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:23:04 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Aug 2018 18:23:04 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535221384.78.0.56676864532.issue34502@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 44838be9f79870ff3c9e04b7398a1dc3d56d53ed by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34502: Remove a note about utf8_mode from sys.exit() docs. (GH-8928)
https://github.com/python/cpython/commit/44838be9f79870ff3c9e04b7398a1dc3d56d53ed


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:23:18 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 18:23:18 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535221398.6.0.56676864532.issue34502@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:31:51 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Aug 2018 18:31:51 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535221911.24.0.56676864532.issue34501@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Your suggested fix seems fine to me.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:36:22 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 18:36:22 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535222182.64.0.56676864532.issue34502@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 42a1ca65d00ba59fe63cc65df0ff297a885e61b8 by Miss Islington (bot) in branch '3.7':
closes bpo-34502: Remove a note about utf8_mode from sys.exit() docs. (GH-8928)
https://github.com/python/cpython/commit/42a1ca65d00ba59fe63cc65df0ff297a885e61b8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:37:40 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Sat, 25 Aug 2018 18:37:40 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535222260.89.0.56676864532.issue34501@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

But if the error message is set, then for consistency, it should be also the case that the later checks set some kind of error message.

----------
nosy: +enedil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:40:00 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 18:40:00 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535222400.23.0.56676864532.issue34501@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8402
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:43:29 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 18:43:29 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535222609.27.0.56676864532.issue34501@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

@enedil It seems that all later check either set a message or simply propagate the error set by a called function. Did you mean any specific later check?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:53:49 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Aug 2018 18:53:49 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535223229.75.0.56676864532.issue34501@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 5f79b50763d687aeeed8edcb4efcc7ac9f8fa186 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34501: PyType_FromSpecWithBases: Check spec->name before dereferencing it. (GH-8930)
https://github.com/python/cpython/commit/5f79b50763d687aeeed8edcb4efcc7ac9f8fa186


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:54:08 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 18:54:08 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535223248.89.0.56676864532.issue34501@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8403

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 14:54:19 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 18:54:19 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535223259.31.0.56676864532.issue34501@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 15:11:32 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 19:11:32 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535224292.59.0.56676864532.issue34501@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 15dadacabf6a1c62e9920b6a42ff8936ea1830f8 by Miss Islington (bot) in branch '3.7':
closes bpo-34501: PyType_FromSpecWithBases: Check spec->name before dereferencing it. (GH-8930)
https://github.com/python/cpython/commit/15dadacabf6a1c62e9920b6a42ff8936ea1830f8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 15:17:16 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 19:17:16 +0000
Subject: [issue34501] PyType_FromSpecWithBases: spec->name is dereferenced
 before checking for NULL
In-Reply-To: <1535210800.55.0.56676864532.issue34501@psf.upfronthosting.co.za>
Message-ID: <1535224636.35.0.56676864532.issue34501@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 323a91bb3a2b5639637efc517fe3f30d3bc288e2 by Miss Islington (bot) in branch '3.6':
closes bpo-34501: PyType_FromSpecWithBases: Check spec->name before dereferencing it. (GH-8930)
https://github.com/python/cpython/commit/323a91bb3a2b5639637efc517fe3f30d3bc288e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34501>
_______________________________________

From report at bugs.python.org  Sat Aug 25 15:22:26 2018
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 25 Aug 2018 19:22:26 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1535224946.61.0.56676864532.issue14465@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
pull_requests: +8405

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sat Aug 25 15:33:39 2018
From: report at bugs.python.org (Michael Felt)
Date: Sat, 25 Aug 2018 19:33:39 +0000
Subject: [issue11190] test_locale error on AIX
In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>
Message-ID: <1535225619.8.0.56676864532.issue11190@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

FYI - this test passes on Python3.X and Python3.7 bots, still fails on Python2.7

In short "fixed" for Python3.

----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11190>
_______________________________________

From report at bugs.python.org  Sat Aug 25 15:36:50 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 25 Aug 2018 19:36:50 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1535225810.53.0.56676864532.issue23325@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I miss that. So this change seems to be user transparent and make more sense then.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Sat Aug 25 15:46:27 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 25 Aug 2018 19:46:27 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535226387.28.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

This is a very thorough analysis. Kudos to that.

----------
nosy: +michael-o

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Sat Aug 25 16:00:03 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Aug 2018 20:00:03 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1535227203.67.0.56676864532.issue14465@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

A few more thoughts for consideration:

* We already have a toprettyxml() tool in the minidom package.

* Since whitespace is significant in XML, prettifying changes the content and meaning, so it doesn't round-trip and should only be used for debugging purposes.

* Usually, I recommend using XML viewers such as the one built into the Chrome browser.  That provides indentation without changing meaning. It also lets you run searches and conveniently supports folding and unfolding elements.   I would rather someone use a viewer rather than something like toprettyxml().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sat Aug 25 16:00:20 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 20:00:20 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
Message-ID: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

'exc_value' reference is leaked at https://github.com/python/cpython/blob/5f79b50763d687aeeed8edcb4efcc7ac9f8fa186/Python/errors.c#L113

----------
components: Interpreter Core
messages: 324099
nosy: benjamin.peterson, berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Reference leak in PyErr_SetObject()
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sat Aug 25 16:01:12 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Aug 2018 20:01:12 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
In-Reply-To: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>
Message-ID: <1535227272.32.0.56676864532.issue34494@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sat Aug 25 16:02:10 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 20:02:10 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535227330.41.0.56676864532.issue34503@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8406
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sat Aug 25 16:17:09 2018
From: report at bugs.python.org (Michael Osipov)
Date: Sat, 25 Aug 2018 20:17:09 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535228229.69.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

I think you are absoltely right.

> In any case, it seems to be broken for any system that does not have UTF-8 as default.

You likely mean ASCII. Python assumes that LANG=C is ASCII which is not the case for AIX and HP-UX.

Your patch looks reasonable, I will try this on Monday. The problem is that there is no roman8 codec in Python. Maybe ISO-8859-1 will do it for the test, but I am still eager to add one.

> I mention this because it seems neither roman8 nor roman9 have 'official' iso names or alias (correct me if I am wrong).

There are no ISO names because this is not an ISO encoding. This is an HP invention aka hp-roman8 (roman8, ibm-1051, r8, Cp1051).

Edit: there is roman8 support: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/encodings/hp_roman8.py as well as aliases.

There are a few aliases missing: cp1051, ibm1051 and hp-roman8. This needs an additonal PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Sat Aug 25 17:05:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 21:05:49 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
Message-ID: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The argument of PySequence_Check() is dereferenced at https://github.com/python/cpython/blob/5f79b50763d687aeeed8edcb4efcc7ac9f8fa186/Objects/abstract.c#L1511 and then checked for NULL.

Reported by Svace static analyzer.

Since other PySomething_Check() functions seem to expect a non-NULL argument, I suggest to remove the NULL check instead of moving it.

----------
components: Interpreter Core
messages: 324101
nosy: benjamin.peterson, berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PySequence_Check: argument is dereferenced and then checked for NULL
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 17:07:36 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 25 Aug 2018 21:07:36 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
In-Reply-To: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>
Message-ID: <1535231256.91.0.56676864532.issue34504@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8407
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 17:11:01 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Aug 2018 21:11:01 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1535231461.18.0.56676864532.issue34334@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Patching QueueHandler.prepare() to set exc_text to None seems to fix this.

I'm not sure that's the right fix. The change appears to have come from this commit:

https://github.com/python/cpython/commit/adfe3440f65dfd6cf4463db6cd02cdc78e77ce17

Specifically, the prepare() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Sat Aug 25 17:12:16 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Aug 2018 21:12:16 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1535231536.85.0.56676864532.issue34334@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Possibly a test needs to be added for this, as it appears to be a regression that went unnoticed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Sat Aug 25 18:19:06 2018
From: report at bugs.python.org (Alex)
Date: Sat, 25 Aug 2018 22:19:06 +0000
Subject: [issue34483] eval() raises NameError: name '...' is not defined
In-Reply-To: <1535046557.48.0.56676864532.issue34483@psf.upfronthosting.co.za>
Message-ID: <1535235546.62.0.56676864532.issue34483@psf.upfronthosting.co.za>


Alex <bojenko.alex at gmail.com> added the comment:

Eric, thank you for the clarification. Do you want me to close the ticket?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34483>
_______________________________________

From report at bugs.python.org  Sat Aug 25 18:23:13 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 25 Aug 2018 22:23:13 +0000
Subject: [issue34483] eval() raises NameError: name '...' is not defined
In-Reply-To: <1535046557.48.0.56676864532.issue34483@psf.upfronthosting.co.za>
Message-ID: <1535235793.49.0.56676864532.issue34483@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'll close this. I'm still reviewing the docs on it, and I might open a documentation issue once I understand it better.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34483>
_______________________________________

From report at bugs.python.org  Sat Aug 25 18:58:09 2018
From: report at bugs.python.org (Victor Porton)
Date: Sat, 25 Aug 2018 22:58:09 +0000
Subject: [issue34306] minidom: wrong processing of xmlns attributes
In-Reply-To: <1533130349.62.0.56676864532.issue34306@psf.upfronthosting.co.za>
Message-ID: <1535237889.58.0.56676864532.issue34306@psf.upfronthosting.co.za>


Victor Porton <porton at narod.ru> added the comment:

My bug report was wrong:

https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html
In the DOM, all namespace declaration attributes are by definition bound to the namespace URI: "http://www.w3.org/2000/xmlns/". These are the attributes whose namespace prefix or qualified name is "xmlns" as introduced in [XML Namespaces 1.1].

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34306>
_______________________________________

From report at bugs.python.org  Sat Aug 25 19:52:30 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Aug 2018 23:52:30 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
In-Reply-To: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>
Message-ID: <1535241150.03.0.56676864532.issue34504@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b57b4ac042b977e0b42a2f5ddb30ca7edffacfa9 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
closes bpo-34504: Remove the useless NULL check in PySequence_Check(). (GH-8935)
https://github.com/python/cpython/commit/b57b4ac042b977e0b42a2f5ddb30ca7edffacfa9


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 19:52:46 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 23:52:46 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
In-Reply-To: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>
Message-ID: <1535241166.56.0.56676864532.issue34504@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8408

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 19:52:54 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Aug 2018 23:52:54 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
In-Reply-To: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>
Message-ID: <1535241174.19.0.56676864532.issue34504@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8409

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 20:03:52 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Aug 2018 00:03:52 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
In-Reply-To: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>
Message-ID: <1535241832.54.0.56676864532.issue34504@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d6725fcdd54cb3c72201eaa8841dd72d84f5f71d by Miss Islington (bot) in branch '3.7':
closes bpo-34504: Remove the useless NULL check in PySequence_Check(). (GH-8935)
https://github.com/python/cpython/commit/d6725fcdd54cb3c72201eaa8841dd72d84f5f71d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 20:14:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Aug 2018 00:14:40 +0000
Subject: [issue34504] PySequence_Check: argument is dereferenced and then
 checked for NULL
In-Reply-To: <1535231149.7.0.56676864532.issue34504@psf.upfronthosting.co.za>
Message-ID: <1535242480.64.0.56676864532.issue34504@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d60bdf239e322316c8b5e37679cb8e789028aae2 by Miss Islington (bot) in branch '3.6':
closes bpo-34504: Remove the useless NULL check in PySequence_Check(). (GH-8935)
https://github.com/python/cpython/commit/d60bdf239e322316c8b5e37679cb8e789028aae2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34504>
_______________________________________

From report at bugs.python.org  Sat Aug 25 20:50:14 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Sun, 26 Aug 2018 00:50:14 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1535244614.32.0.56676864532.issue34443@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

Serhiy, would it be ok to put '__module__' + '.' + __qualname__ here?

----------
nosy: +enedil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Sat Aug 25 21:24:24 2018
From: report at bugs.python.org (Balibax)
Date: Sun, 26 Aug 2018 01:24:24 +0000
Subject: [issue34505] urllib2 fails for proxy credentials that contains a '/'
 character
Message-ID: <1535246664.68.0.56676864532.issue34505@psf.upfronthosting.co.za>


New submission from Balibax <gamekela1 at gmail.com>:

How can solve this<a href="https://www.pinterest.com/CoreTricks/">?</a>

----------
components: Build
messages: 324111
nosy: Balibax5445
priority: normal
severity: normal
status: open
title: urllib2 fails for proxy credentials that contains a '/' character
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34505>
_______________________________________

From report at bugs.python.org  Sun Aug 26 03:22:02 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Aug 2018 07:22:02 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535268122.67.0.56676864532.issue34171@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

It looks like https://github.com/python/buildmaster-config/pull/43 won't actually help; I changed it to use `method='clean'` because we don't want to blow away the `externals` directory on Windows buildbots, and `*.cover` is in `.gitignore` so `Lib/trace.cover` will not be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sun Aug 26 03:29:09 2018
From: report at bugs.python.org (Windson Yang)
Date: Sun, 26 Aug 2018 07:29:09 +0000
Subject: [issue33741] UnicodeEncodeError onsmtplib.login(MAIL_USER,
 MAIL_PASSWORD)
In-Reply-To: <1527979236.47.0.592728768989.issue33741@psf.upfronthosting.co.za>
Message-ID: <1535268549.28.0.56676864532.issue33741@psf.upfronthosting.co.za>


Change by Windson Yang <wiwindson at gmail.com>:


----------
pull_requests: +8410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33741>
_______________________________________

From report at bugs.python.org  Sun Aug 26 03:43:15 2018
From: report at bugs.python.org (Windson Yang)
Date: Sun, 26 Aug 2018 07:43:15 +0000
Subject: [issue29750] smtplib doesn't handle unicode passwords
In-Reply-To: <1488919224.48.0.0966376973087.issue29750@psf.upfronthosting.co.za>
Message-ID: <1535269395.98.0.56676864532.issue29750@psf.upfronthosting.co.za>


Change by Windson Yang <wiwindson at gmail.com>:


----------
keywords: +patch
pull_requests: +8411
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29750>
_______________________________________

From report at bugs.python.org  Sun Aug 26 03:44:30 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 26 Aug 2018 07:44:30 +0000
Subject: [issue34506] Traceback logged when SSL handshake fails
Message-ID: <1535269470.94.0.56676864532.issue34506@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

When an SSL handshake fails in asyncio, an exception traceback is logged to standard error even if the application code catches the exception. This logging cannot be suppressed, except by providing a custom exception handler for the whole event loop. The question was raised on StackOverflow in https://stackoverflow.com/q/52012488/1600898

To reproduce the issue, run the attached minimal example (taken from the SO question). Expected behavior is for "Error handled" to be printed. Actual behavior is that, in addition to that line, two tracebacks are printed.

It looks like a bug that _fatal_error both logs the exception and calls connection_lost on the protocol (through transport._force_close()). If the idea is for the exception not to get swallowed by protocols that don't implement a sensible connection_lost (e.g. because they've just inherited from BaseProtocol, like the echo server examples), then maybe a protocol that propagates the exception in connection_lost should be able to opt out of the additional logging. That way the stream protocols would avoid spurious output for the suppressed exception by default, and the same opt-out mechanism would be available to user-written protocols.

----------
files: sslerr.py
messages: 324113
nosy: hniksic
priority: normal
severity: normal
status: open
title: Traceback logged when SSL handshake fails
Added file: https://bugs.python.org/file47763/sslerr.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34506>
_______________________________________

From report at bugs.python.org  Sun Aug 26 04:45:04 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 26 Aug 2018 08:45:04 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535273104.31.0.56676864532.issue6700@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 491740f116755e220135e596ec802ea3a0f65596 by Tal Einat in branch '2.7':
[2.7] bpo-6700: Fix inspect.getsourcelines for module level frames/tracebacks (GH-8864)
https://github.com/python/cpython/commit/491740f116755e220135e596ec802ea3a0f65596


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Sun Aug 26 04:47:22 2018
From: report at bugs.python.org (Tal Einat)
Date: Sun, 26 Aug 2018 08:47:22 +0000
Subject: [issue6700] inspect.getsource() returns incorrect source lines at the
 module level
In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za>
Message-ID: <1535273242.2.0.56676864532.issue6700@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for reporting this, Gabriel!

Thanks for the PR, Vladimir!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6700>
_______________________________________

From report at bugs.python.org  Sun Aug 26 07:00:22 2018
From: report at bugs.python.org (Lior Cohen)
Date: Sun, 26 Aug 2018 11:00:22 +0000
Subject: [issue34507] Add path expansion interpolation in pyvenv.cfg home key
Message-ID: <1535281222.0.0.56676864532.issue34507@psf.upfronthosting.co.za>


New submission from Lior Cohen <chnlior at gmail.com>:

When working with venv virtual environment, python.exe finds its base_prefix and base_exec_prefix by the home key in the pyvenv.cfg file.

If one edits this file with $xyz (or %xyz% in windows), it is not not resolved.

The reason of replacing the absolute path generated by venv to path expand tokens, is to be able to port the venv + its base python to different machine, which is part of my company deployment process.

----------
components: Interpreter Core
messages: 324116
nosy: chnlior
priority: normal
severity: normal
status: open
title: Add path expansion interpolation in pyvenv.cfg home key
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34507>
_______________________________________

From report at bugs.python.org  Sun Aug 26 09:11:50 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 26 Aug 2018 13:11:50 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1535289110.52.0.56676864532.issue11193@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Short Version:
root at x065:[/data/prj/python/python3-3.8]./python -m test test_subprocess
Run tests sequentially
0:00:00 [1/1] test_subprocess
test_subprocess passed in 2 min 18 sec

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2 min 18 sec
Tests result: SUCCESS

...
----------------------------------------------------------------------
Ran 285 tests in 136.443s

OK (skipped=33)
test_subprocess passed in 2 min 16 sec

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2 min 16 sec
Tests result: SUCCESS

Posting a PR - tested manually on AIX 5.3, AIX 6.1 and AIX 7.1

imho: being able to remove the special condition for AIX is an improvement.

diff --git a/Lib/test/test_subprocess.py b/Lib/test/test_subprocess.py
index 73b57b21db..4719773b67 100644
--- a/Lib/test/test_subprocess.py
+++ b/Lib/test/test_subprocess.py
@@ -2228,15 +2228,9 @@ class POSIXProcessTestCase(BaseTestCase):
             env = os.environ.copy()
             env[key] = value
             # Use C locale to get ASCII for the locale encoding to force
-            # surrogate-escaping of \xFF in the child process; otherwise it can
-            # be decoded as-is if the default locale is latin-1.
+            # surrogate-escaping of \xFF in the child process
             env['LC_ALL'] = 'C'
-            if sys.platform.startswith("aix"):
-                # On AIX, the C locale uses the Latin1 encoding
-                decoded_value = encoded_value.decode("latin1", "surrogateescape")
-            else:
-                # On other UNIXes, the C locale uses the ASCII encoding
-                decoded_value = value
+            decoded_value = value
             stdout = subprocess.check_output(
                 [sys.executable, "-c", script],
                 env=env)

----------
versions: +Python 3.8 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Sun Aug 26 09:18:20 2018
From: report at bugs.python.org (Michael Felt)
Date: Sun, 26 Aug 2018 13:18:20 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1535289500.71.0.56676864532.issue11193@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8412
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Sun Aug 26 10:25:50 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 26 Aug 2018 14:25:50 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
Message-ID: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

[From https://stackoverflow.com/q/52026406/270986]

The following is valid, and works as expected:

>>> def f():
...     x = *(1, 2), 3
...     return x
... 
>>> f()
(1, 2, 3)

But the tuple expression can't be used directly in a "return" statement:

>>> def f():
...     return *(1, 2), 3
  File "<stdin>", line 2
    return *(1, 2), 3
           ^
SyntaxError: invalid syntax

It's trivial to work around, by adding an extra pair of parentheses around the return target, but it seems a surprising inconsistency. Would it make sense to allow this? In terms of the grammar,

    return_stmt: 'return' [testlist]

would be replaced with:

    return_stmt: 'return' [testlist_star_expr]

There may be other places in the grammar where "testlist" could reasonably be replaced with "testlist_star_expr", for example:

    for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite]

----------
components: Interpreter Core
messages: 324118
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: return of non-parenthesized star-unpacking expression a SyntaxError
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Sun Aug 26 10:43:43 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Sun, 26 Aug 2018 14:43:43 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
In-Reply-To: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>
Message-ID: <1535294623.33.0.56676864532.issue34494@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

That's the documented behavior. Per https://docs.python.org/3/reference/datamodel.html#object.__getitem__ :

>Note: for loops expect that an IndexError will be raised for illegal indexes to allow proper detection of the end of the sequence. 

The need for *only* __getitem__ is also mentioned in the documentation of the iter builtin ( https://docs.python.org/3/library/functions.html#iter ):

>Without a second argument, object must be a collection object which supports the iteration protocol (the __iter__() method), or it must support the sequence protocol (the __getitem__() method with integer arguments starting at 0).

At no point is a dependency on __len__ mentioned.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sun Aug 26 11:10:50 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 26 Aug 2018 15:10:50 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535296250.87.0.56676864532.issue34171@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Can we manually ssh into the buildbots from the buildbot master and delete the file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sun Aug 26 11:22:10 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Aug 2018 15:22:10 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535296930.6.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8413
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sun Aug 26 11:24:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Aug 2018 15:24:15 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535297055.13.0.56676864532.issue34171@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It may be easier to remove "trace.cover" before testing every time than clean up all buildbots once.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sun Aug 26 12:01:53 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 26 Aug 2018 16:01:53 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535299313.93.0.56676864532.issue34508@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +patch
pull_requests: +8414
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Sun Aug 26 12:16:41 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 26 Aug 2018 16:16:41 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535300201.37.0.56676864532.issue34508@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
pull_requests: +8415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Sun Aug 26 12:31:28 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 26 Aug 2018 16:31:28 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535301088.76.0.56676864532.issue34503@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset a2eefa67542c25617a58c03a27c17fd48e2a0856 by Xiang Zhang (Alexey Izbyshev) in branch 'master':
bpo-34503: Fix refleak in PyErr_SetObject() (GH-8934)
https://github.com/python/cpython/commit/a2eefa67542c25617a58c03a27c17fd48e2a0856


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sun Aug 26 12:31:55 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Aug 2018 16:31:55 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535301115.82.0.56676864532.issue34503@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8416

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sun Aug 26 12:32:04 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Aug 2018 16:32:04 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535301124.63.0.56676864532.issue34503@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8417

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:13:49 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Aug 2018 17:13:49 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535303629.7.0.56676864532.issue34503@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 204fb459ca1d77c2eab02a3191ba2d2216ff2d72 by Miss Islington (bot) in branch '3.6':
bpo-34503: Fix refleak in PyErr_SetObject() (GH-8934)
https://github.com/python/cpython/commit/204fb459ca1d77c2eab02a3191ba2d2216ff2d72


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:13:49 2018
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Aug 2018 17:13:49 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535303629.97.0.56676864532.issue34503@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2caf86ff6d72d625f86db78c6e90fdaf09e8f703 by Miss Islington (bot) in branch '3.7':
bpo-34503: Fix refleak in PyErr_SetObject() (GH-8934)
https://github.com/python/cpython/commit/2caf86ff6d72d625f86db78c6e90fdaf09e8f703


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:14:57 2018
From: report at bugs.python.org (Jun Aruga)
Date: Sun, 26 Aug 2018 17:14:57 +0000
Subject: [issue34509] Starting to use gcc-8 on CI
Message-ID: <1535303697.92.0.56676864532.issue34509@psf.upfronthosting.co.za>


New submission from Jun Aruga <happy at oh4u.net>:

This ticket is from below conversation on python-dev mailing list.
https://mail.python.org/pipermail/python-dev/2018-August/155011.html

Right now the Python project Travis CI is running on gcc-4.8.4 for coverage testing.
I want to replace it or add the latest version gcc-8 case.

The benefit to use gcc-8 is,

* It is important to run on the old version 4.8 but, it is also meaningful to follow the latest version and care issues such as warnings on the latest version gcc.
* I am working in Fedora project that is using gcc version 8 as a main c compiler. If the Python project care gcc-8, that might be helpful for people who maintain Python Debian/Fedora package or Installer on Mac/Windows.


The demerit is

* Right now the gcc-4.8 is used for the coverage. The total running time on gcc-8 might be longer than current one.
* To run the latest gcc-8, we can add the repository [1] with the way [2][3], but I am not sure whether the repository is stable.

I would show you 2 cases to use gcc-8 on Linux.

[1] https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test
[2] https://docs.travis-ci.com/user/installing-dependencies/#installing-packages-from-a-custom-apt-repository
[3] https://docs.travis-ci.com/user/languages/c/#gcc-on-os-x
[4] Ruby
   https://travis-ci.org/junaruga/ruby/builds/418242410
   https://github.com/junaruga/ruby/blob/feature/ci-new-gcc/.travis.yml
   https://github.com/ruby/ruby/pull/1937
[5] Trinity
   Example for gcc-8 on both Linux and Mac.
   https://travis-ci.org/trinityrnaseq/trinityrnaseq
   https://github.com/trinityrnaseq/trinityrnaseq/blob/master/.travis.yml

----------
messages: 324125
nosy: junaruga
priority: normal
severity: normal
status: open
title: Starting to use gcc-8 on CI
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34509>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:15:58 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Aug 2018 17:15:58 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535303758.33.0.56676864532.issue34171@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

> Can we manually ssh into the buildbots from the buildbot master and delete the file?

No, there is no access to the workers except for the connection created by each worker for the purpose of buildbot communication (and individually by each worker owner).

> It may be easier to remove "trace.cover" before testing every time than clean up all buildbots once.

I agree.  Alternately, the test could be changed to avoid that assertion; it's strange that the test could fail just because a file could happen to exist outside of the test's control.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:17:39 2018
From: report at bugs.python.org (Jun Aruga)
Date: Sun, 26 Aug 2018 17:17:39 +0000
Subject: [issue34509] Starting to use gcc-8 on CI
In-Reply-To: <1535303697.92.0.56676864532.issue34509@psf.upfronthosting.co.za>
Message-ID: <1535303859.13.0.56676864532.issue34509@psf.upfronthosting.co.za>


Change by Jun Aruga <happy at oh4u.net>:


----------
keywords: +patch
pull_requests: +8418
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34509>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:20:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 26 Aug 2018 17:20:30 +0000
Subject: [issue34503] Reference leak in PyErr_SetObject()
In-Reply-To: <1535227220.49.0.56676864532.issue34503@psf.upfronthosting.co.za>
Message-ID: <1535304030.75.0.56676864532.issue34503@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34503>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:24:49 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Aug 2018 17:24:49 +0000
Subject: [issue34494] simple "sequence" class ignoring __len__
In-Reply-To: <1535174790.07.0.56676864532.issue34494@psf.upfronthosting.co.za>
Message-ID: <1535304289.87.0.56676864532.issue34494@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Josh.  This matches the documented behavior and isn't a bug. Marking as closed.

There are potentially two ways to stop sequence iteration, either by using len or by waiting for IndexError.  Python uses the latter to allow lists to be dynamically resized during iteration and because checking len on every iteration would be expensive.  

If someone doesn't read the docs, and assumes Python uses len, and writes an inconsistent class (one where len doesn't match the point where IndexError is raised), then there is little we can do to prevent that person from being "surprised".

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34494>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:27:55 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Aug 2018 17:27:55 +0000
Subject: [issue34497] Remove needless set operator restriction
In-Reply-To: <1535197046.82.0.56676864532.issue34497@psf.upfronthosting.co.za>
Message-ID: <1535304475.68.0.56676864532.issue34497@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34497>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:31:29 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 26 Aug 2018 17:31:29 +0000
Subject: [issue11193] test_subprocess test_undecodable_env error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1535304689.61.0.56676864532.issue11193@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

someone with modern AIX access reopen if this specific issue still appears to exist after the 3.8 and 3.7 PRs finish merging.

----------
nosy: +gregory.p.smith
stage: patch review -> resolved
status: open -> closed
title: test_subprocess error on AIX -> test_subprocess test_undecodable_env error on AIX
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:33:33 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 26 Aug 2018 17:33:33 +0000
Subject: [issue11193] test_subprocess test_undecodable_env error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1535304813.91.0.56676864532.issue11193@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

https://github.com/python/cpython/pull/8939 and https://github.com/python/cpython/pull/8946

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:33:54 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 26 Aug 2018 17:33:54 +0000
Subject: [issue11193] test_subprocess test_undecodable_env error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1535304834.56.0.56676864532.issue11193@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:46:43 2018
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 26 Aug 2018 17:46:43 +0000
Subject: [issue34509] Starting to use gcc-8 on CI
In-Reply-To: <1535303697.92.0.56676864532.issue34509@psf.upfronthosting.co.za>
Message-ID: <1535305603.51.0.56676864532.issue34509@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I think rather than switching Travis CI (or VSTS) to GCC 8, it would be better to set up a buildbot running GCC 8, or switching one of our existing workers to it.  We want to keep the pre-merge CI as stable as possible, and using a bleeding-edge compiler doesn't strike me as particularly stable.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34509>
_______________________________________

From report at bugs.python.org  Sun Aug 26 13:57:08 2018
From: report at bugs.python.org (Jun Aruga)
Date: Sun, 26 Aug 2018 17:57:08 +0000
Subject: [issue34509] Starting to use gcc-8 on CI
In-Reply-To: <1535303697.92.0.56676864532.issue34509@psf.upfronthosting.co.za>
Message-ID: <1535306228.57.0.56676864532.issue34509@psf.upfronthosting.co.za>


Jun Aruga <happy at oh4u.net> added the comment:

> it would be better to set up a buildbot running GCC 8, or switching one of our existing workers to it.  We want to keep the pre-merge CI as stable as possible, and using a bleeding-edge compiler doesn't strike me as particularly stable.

Oh it seems that we have already had the CI environment as buildbot. I did not know that. Yeah it might be better to add it as a buildbot.

https://buildbot.python.org/all/#/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34509>
_______________________________________

From report at bugs.python.org  Sun Aug 26 14:10:15 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Aug 2018 18:10:15 +0000
Subject: [issue34497] Remove needless set operator restriction
In-Reply-To: <1535197046.82.0.56676864532.issue34497@psf.upfronthosting.co.za>
Message-ID: <1535307015.93.0.56676864532.issue34497@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry Dan, we're going to pass on this one.  The current behavior was an intentional design choice by Guido and reflects a careful balance between some difficult trade-offs.

An early and permanent mistake in Python's design is that list.__iadd__() and list.extend() both accept any input iterable.  For extend(), this proved to be useful.  In contrast, __iadd__() was a recurring bug magnet.  People would routinely type "s=['abc']; s+='def'" expecting to get ['abc', 'def'] rather than ['abc', 'd', 'e', 'f'].   Based on this experience, Guido wisely opined that math operators on other concrete collection classes should be restricted working with members of their own class.

When abstract base classes were introduced, a seemingly inconsistent decision was made.  The Set ABCs allowed the math operators to accept any input iterable and did not provide the spelled-out method names (union, intersection, difference, etc).

IIRC, there were several reasons for this.  It kept the total number of methods to a manageable size (important so as to not unduly burden implementers of concrete classes).  Also, having a same type restriction is at odds with some of the design goals and use cases for collections ABCs.  Additionally, the code for the mixin methods is simpler without the restrictions.

When dict views were implemented, they followed the Set ABCs.  This gave them fewer methods than sets but also gave them fewer restrictions.  For the most part, these design trade-offs have worked out well in practice.  The existing behavior is neither "needless" nor "arbitrary".  It was the result of careful consideration by GvR on what works best for most people, most of the time.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34497>
_______________________________________

From report at bugs.python.org  Sun Aug 26 16:05:27 2018
From: report at bugs.python.org (Collin Anderson)
Date: Sun, 26 Aug 2018 20:05:27 +0000
Subject: [issue34510] Add add HTTPConnection.settimeout()
Message-ID: <1535313927.12.0.56676864532.issue34510@psf.upfronthosting.co.za>


Change by Collin Anderson <cmawebsite at gmail.com>:


----------
components: Library (Lib)
nosy: collinanderson
priority: normal
pull_requests: 8422
severity: normal
status: open
title: Add add HTTPConnection.settimeout()
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34510>
_______________________________________

From report at bugs.python.org  Sun Aug 26 16:49:49 2018
From: report at bugs.python.org (harobed)
Date: Sun, 26 Aug 2018 20:49:49 +0000
Subject: [issue34511] I suggest to add documentation about "method" parameter
 of urllib.request.Request class
Message-ID: <1535316589.49.0.56676864532.issue34511@psf.upfronthosting.co.za>


New submission from harobed <stephane at harobed.org>:

Hi,

I see "method=None" parameter in urllib.request.Request constructor (https://github.com/python/cpython/blob/master/Lib/urllib/request.py#L327) but I don't see "method" parameter in documentation: https://docs.python.org/3.2/library/urllib.request.html#urllib.request.Request

I suggest to add documentation about "method".

Best regards,
St?phane

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 324134
nosy: docs at python, harobed
priority: normal
severity: normal
status: open
title: I suggest to add documentation about "method" parameter of urllib.request.Request class
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34511>
_______________________________________

From report at bugs.python.org  Sun Aug 26 17:03:05 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Aug 2018 21:03:05 +0000
Subject: [issue34510] add HTTPConnection.settimeout()
Message-ID: <1535317385.44.0.56676864532.issue34510@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
title: Add add HTTPConnection.settimeout() -> add HTTPConnection.settimeout()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34510>
_______________________________________

From report at bugs.python.org  Sun Aug 26 17:05:59 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 26 Aug 2018 21:05:59 +0000
Subject: [issue34511] I suggest to add documentation about "method" parameter
 of urllib.request.Request class
In-Reply-To: <1535316589.49.0.56676864532.issue34511@psf.upfronthosting.co.za>
Message-ID: <1535317559.36.0.56676864532.issue34511@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

method is added in Python 3.3. You're referencing documentation of Python 3.2.

The documentation is correct for later Python versions: https://docs.python.org/3.7/library/urllib.request.html#urllib.request.Request

----------
nosy: +Mariatta
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34511>
_______________________________________

From report at bugs.python.org  Sun Aug 26 17:06:22 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 26 Aug 2018 21:06:22 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
Message-ID: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

If a format string contains code points outside of ASCII range, time.strftime() can behave in four different ways depending on the platform, the current locale and the code points:

* raise a UnicodeEncodeError
* return an empty string
* for surrogates in \uDC80-\uDCFF range, replace them with different code points in the output (potentially mangling nearby parts of the output as well)
* round-trip them correctly

Some examples:

* Linux (glibc 2.27):
Python 3.6.4 (default, Jan 03 2018, 13:52:55) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, locale
>>> locale.getlocale()
('en_US', 'UTF-8')
>>> time.strftime('\x80')
'\x80'
>>> time.strftime('\u044f')
'?' # '\u044f'
>>> time.strftime('\ud800')
'\ud800'
>>> time.strftime('\udcff')
'\udcff'
>>> locale.setlocale(locale.LC_CTYPE, 'C')
'C'
>>> time.strftime('\x80')
'\x80'
>>> time.strftime('\u044f')
'?' # '\u044f'
>>> time.strftime('\ud800')
'\ud800'
>>> time.strftime('\udcff')
'\udcff'

* macOS 10.13.6 and FreeBSD 11.1:
Python 3.7.0 (default, Jul 23 2018, 20:22:55)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time, locale
>>> locale.getlocale()
('en_US', 'UTF-8')
>>> time.strftime('\x80')
'\x80'
>>> time.strftime('\u044f')
'?' # '\u044f'
>>> time.strftime('\ud800')
''
>>> time.strftime('\udcff')
''
>>> locale.setlocale(locale.LC_CTYPE, 'C')
'C'
>>> time.strftime('\x80')
'\x80'
>>> time.strftime('\u044f')
''
>>> time.strftime('\ud800')
''
>>> time.strftime('\udcff')
''

* Windows 8.1:
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
>>> import time, locale
>>> locale.getlocale()
(None, None)
>>> time.strftime('\x80')
'\x80'
>>> time.strftime('\u044f')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'locale' codec can't encode character '\u044f' in position 0: encoding error
>>> time.strftime('\ud800')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'locale' codec can't encode character '\ud800' in position 0: encoding error
>>> time.strftime('\udcff')
'y' # '\xff'
>>> locale.setlocale(locale.LC_CTYPE, '')
'Russian_Russia.1251'
>>> time.strftime('\x80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'locale' codec can't encode character '\x80' in position 0: encoding error
>>> time.strftime('\u044f')
'?' # '\u044f'
>>> time.strftime('\ud800')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'locale' codec can't encode character '\ud800' in position 0: encoding error
>>> time.strftime('\udcff')
'?' # '\u044f'

The reasons of such differences are the following:
* Reliance on either wcsftime() or strftime() from the C library depending on the platform.
* For strftime(), the input is encoded into the charset of the current locale with 'surrogateescape' error handler, and the output is decoded back in the same way.
* Different handling of code points which are unrepresentable in the charset of the current locale by glibc and macOS/FreeBSD.

I suggest to at least document that the format string, despite being an 'str', requires special care if it contains non-ASCII code points.

The 'datetime' module docs warn about the locale-dependent output, but only with regard to particular format specifiers [1].

I'll submit a draft PR. Suggestions are welcome.

[1] https://docs.python.org/3.7/library/datetime.html#strftime-and-strptime-behavior

----------
assignee: docs at python
components: Documentation
messages: 324136
nosy: belopolsky, docs at python, izbyshev, p-ganssle, taleinat
priority: normal
severity: normal
status: open
title: Document platform-specific strftime() behavior for non-ASCII format strings
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sun Aug 26 17:09:52 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 26 Aug 2018 21:09:52 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1535317792.65.0.56676864532.issue34512@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +8424
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sun Aug 26 20:19:42 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 00:19:42 +0000
Subject: [issue11193] test_subprocess test_undecodable_env error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1535329182.34.0.56676864532.issue11193@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8425

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Sun Aug 26 20:40:23 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 00:40:23 +0000
Subject: [issue34513] test_multiprocessing_spawn fails on x86 Windows7 3.7
 buildbot
Message-ID: <1535330423.47.0.56676864532.issue34513@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_multiprocessing_spawn fails on x86 Windows7 3.7 buildbot:

https://buildbot.python.org/all/#/builders/111/builds/500

Timeout (0:15:00)!
Thread 0x00000c64 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\connection.py", line 306 in _recv_bytes
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\connection.py", line 250 in recv
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 470 in _handle_results
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 865 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 917 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 885 in _bootstrap
Thread 0x000000b4 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 422 in _handle_tasks
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 865 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 917 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 885 in _bootstrap
Thread 0x000008d4 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 413 in _handle_workers
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 865 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 917 in _bootstrap_inner
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 885 in _bootstrap
Thread 0x00000b88 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 296 in wait
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\threading.py", line 552 in wait
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 648 in wait
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 651 in get
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 261 in apply
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 2224 in test_apply
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\support\__init__.py", line 1882 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\support\__init__.py", line 1972 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 179 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\test\__main__.py", line 2 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
Process SpawnPoolWorker-184:
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 127, in worker
    put((job, i, result))
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\queues.py", line 361, in put
    self._writer.send_bytes(obj)
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\connection.py", line 200, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\connection.py", line 280, in _send_bytes
    ov, err = _winapi.WriteFile(self._handle, buf, overlapped=True)
BrokenPipeError: [WinError 232] The pipe is being closed
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\process.py", line 297, in _bootstrap
    self.run()
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\pool.py", line 132, in worker
    put((job, i, (False, wrapped)))
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\queues.py", line 361, in put
    self._writer.send_bytes(obj)
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\connection.py", line 200, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\multiprocessing\connection.py", line 280, in _send_bytes
    ov, err = _winapi.WriteFile(self._handle, buf, overlapped=True)
BrokenPipeError: [WinError 232] The pipe is being closed
program finished with exit code 1
elapsedTime=4600.317000

----------
components: Tests, Windows
messages: 324137
nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn fails on x86 Windows7 3.7 buildbot
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34513>
_______________________________________

From report at bugs.python.org  Sun Aug 26 21:42:32 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Aug 2018 01:42:32 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1535334152.77.0.56676864532.issue30858@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I just ran into this, and found the existing error message *incredibly* confusing. My immediate reaction was "There's no keyword in that line, what are you complaining about?".

An error message that said "Keyword argument name must be an identifier" would have been *far* more useful, and far less confusing.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Sun Aug 26 21:46:49 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Aug 2018 01:46:49 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1535334409.69.0.56676864532.issue30858@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The current error message is also outright incorrect, since simple names *are* valid expressions - the actual problem being reported is that binary expressions (veky's case) and strings (my case) *aren't* identifiers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Sun Aug 26 22:21:09 2018
From: report at bugs.python.org (Victor Engmark)
Date: Mon, 27 Aug 2018 02:21:09 +0000
Subject: [issue34514] assertEqual doesn't use maxDiff when comparing
 dictionaries
Message-ID: <1535336469.7.0.56676864532.issue34514@psf.upfronthosting.co.za>


New submission from Victor Engmark <victorengmark.catalyst at gmail.com>:

According to the documentation `assertDictEqual()` "will be used by default to compare dictionaries in calls to assertEqual()." Great, since `maxDiff` applies to assertDictEqual(). However, `maxDiff` doesn't apply to `assertEqual()` when comparing dictionaries.

----------
components: Tests
messages: 324140
nosy: Victor Engmark2
priority: normal
severity: normal
status: open
title: assertEqual doesn't use maxDiff when comparing dictionaries
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34514>
_______________________________________

From report at bugs.python.org  Sun Aug 26 22:58:24 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Mon, 27 Aug 2018 02:58:24 +0000
Subject: [issue34514] assertEqual doesn't use maxDiff when comparing
 dictionaries
In-Reply-To: <1535336469.7.0.56676864532.issue34514@psf.upfronthosting.co.za>
Message-ID: <1535338704.66.0.56676864532.issue34514@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

Hello Victor, can you tell me what is 'maxDiff'? Can you give me a simple example of expected output and actual output by taking a simple dictionary?

Thanks

----------
nosy: +prudvinit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34514>
_______________________________________

From report at bugs.python.org  Sun Aug 26 23:16:43 2018
From: report at bugs.python.org (Elias Zamaria)
Date: Mon, 27 Aug 2018 03:16:43 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1535339803.53.0.56676864532.issue32968@psf.upfronthosting.co.za>


Elias Zamaria <mikez302 at gmail.com> added the comment:

I updated my GitHub username. For the record, it used to be mikez302, and now it is elias6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Sun Aug 26 23:45:50 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 27 Aug 2018 03:45:50 +0000
Subject: [issue34361] An error should be returned when there are spaces in
 between function name and parameters
In-Reply-To: <1533752169.63.0.56676864532.issue34361@psf.upfronthosting.co.za>
Message-ID: <1535341550.95.0.56676864532.issue34361@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hi,

I agree that it can break backward compatibility. But maybe we can add some sort of warning message?

The entire motive of this is to get new folks to understand how a function is ideally defined and called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34361>
_______________________________________

From report at bugs.python.org  Mon Aug 27 00:04:59 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 27 Aug 2018 04:04:59 +0000
Subject: [issue15045] Make textwrap.dedent() consistent with
 str.splitlines(True) and str.strip()
In-Reply-To: <1339421358.2.0.611530152115.issue15045@psf.upfronthosting.co.za>
Message-ID: <1535342699.09.0.56676864532.issue15045@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hey Nick, Serhiy

The patch is up for your review. Any updates on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15045>
_______________________________________

From report at bugs.python.org  Mon Aug 27 00:18:01 2018
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 27 Aug 2018 04:18:01 +0000
Subject: [issue34319] Clarify pathlib.Path("filepath").read_text()
In-Reply-To: <1533210753.86.0.56676864532.issue34319@psf.upfronthosting.co.za>
Message-ID: <1535343481.45.0.56676864532.issue34319@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Marking this bug as fixed via https://github.com/python/cpython/pull/8645

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34319>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:37:27 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 27 Aug 2018 06:37:27 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1535351847.07.0.56676864532.issue34410@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I could. But currently I don't have a good idea how to fix it elegantly. If anyone else makes a PR, I'm willing to review it.

----------
stage:  -> needs patch
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:39:18 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Aug 2018 06:39:18 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1535351958.77.0.56676864532.issue34427@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> But a MutableSequence can represents a sequence that doesn't
> fit in memory. It can provide an interface to a linear 
> on-disk store. In this case creating an on-memory copy 
> is not possible.

This case is likely not worth worrying about.  If a user created such a sequence AND wrote "s += s", it is unclear whether any particular unpleasant outcome (including the current behavior) could be avoided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:47:47 2018
From: report at bugs.python.org (monson)
Date: Mon, 27 Aug 2018 06:47:47 +0000
Subject: [issue34515] lib2to3: support non-ASCII identifiers
Message-ID: <1535352467.5.0.56676864532.issue34515@psf.upfronthosting.co.za>


New submission from monson <holymonson at gmail.com>:

Python 3.0 introduces additional characters from outside the ASCII range (see PEP 3131). see https://docs.python.org/3/reference/lexical_analysis.html#identifiers

But lib2to3 can't tokenize them corretly.
```
$ echo '? = 1' | python3.7 -m lib2to3.pgen2.tokenize
1,0-1,1:	ERRORTOKEN	'?'
1,2-1,3:	OP	'='
1,4-1,5:	NUMBER	'1'
1,5-1,6:	NEWLINE	'\n'
2,0-2,0:	ENDMARKER	''
```
'?' should be tokenized as NAME instead of ERRORTOKEN.

----------
components: Library (Lib)
messages: 324148
nosy: monson
priority: normal
severity: normal
status: open
title: lib2to3: support non-ASCII identifiers
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34515>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:52:34 2018
From: report at bugs.python.org (chen wu)
Date: Mon, 27 Aug 2018 06:52:34 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
Message-ID: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>


New submission from chen wu <wuchen12 at huawei.com>:

when I tried to request a url like "https://[fc00:0a08::2]:35357"? I got 400. 
The code is like:
    import requests
    requests.get("https://[fc00:0a08::2]:35357", verify=False)
And the apache logs:
    vhost.c(889): [client fc00:ac1c::9a5:58692] AH00550: Client sent malformed Host header: [[fc00::0a08::2]]:35357
If user no set "Host" in header, httpslib will pase it from url and set it.
The paser function is urllib3.util.url.pase_url. When url is "https://[fc00:0a08::2]:35357", we got host [fc00:0a08::2].
And then httplib sets host in putrequest, "[" and "]" will be added to [fc00:0a08::2], which is not a valid format for host.
The part of codes are:
974                    # Wrap the IPv6 Host Header with [] (RFC 2732)
975                    if host_enc.find(':') >= 0:
976                        host_enc = "[" + host_enc + "]"

maybe the judgement condition for wrap ipv6 host header with [] is not very well?

----------
components: Library (Lib)
messages: 324149
nosy: visionwun
priority: normal
severity: normal
status: open
title: httplib sets unbefitting "Host" in request header when requests an ipv6 format url.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:52:59 2018
From: report at bugs.python.org (AldarisPale)
Date: Mon, 27 Aug 2018 06:52:59 +0000
Subject: [issue34025] SMTP EmailPolicy not using the correct line length for
 RCF 2045 encoded data (is 78, should be 76)
In-Reply-To: <1530548294.1.0.56676864532.issue34025@psf.upfronthosting.co.za>
Message-ID: <1535352779.59.0.56676864532.issue34025@psf.upfronthosting.co.za>


AldarisPale <raul+pythonbugs at majas.org> added the comment:

Hi!

I hit this bug on python 3.4.

For the reference here are two email sources. The first one works while the second one does not. Both were produced using smtplib the only difference being the workaround proposed by Douglas Thor.
I hit this bug when using K-9 mail for reading e-mails.
Relevant github link: https://github.com/k9mail/k-9/issues/1659#issuecomment-416074768

This one works:
---------------

Return-Path: <sender at senderdomain.com>
X-Original-To: receiver at receiverdomain.com
Delivered-To: receiver at receiverdomain.com
Received: from [127.0.0.1] (smtp [127.0.0.1])
        by smtp.receiverdomain.com (Postfix) with ESMTP id 2697F23C0063
        for <receiver at receiverdomain.com>; Mon, 27 Aug 2018 09:20:15 +0300 (EEST)
Subject: Malformed base64
From: sender at senderdomain.com
To: receiver at receiverdomain.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-Id: <20180827062015.2697F23C0063 at smtp.receiverdomain.com>
Date: Mon, 27 Aug 2018 09:20:15 +0300 (EEST)

Q09OVEVOVF9MRU5HVEg6IDEyMzQ1Njc4OTBhYmNkZWYNCkNPTlRFTlRfVFlQRTogMTIzNDU2Nzg5
MGFiY2RlZg0KQ09OVEVYVF9ET0NVTUVOVF9ST09UOiAxMjM0NTY3ODkwYWJjZGVmDQpDT05URVhU
X1BSRUZJWDogMTIzNDU2Nzg5MGFiY2RlZg0KRE9DVU1FTlRfUk9PVDogMTIzNDU2Nzg5MGFiY2Rl
Zg0KR0FURVdBWV9JTlRFUkZBQ0U6IDEyMzQ1Njc4OTBhYmNkZWYNCkhUVFBTOiAxMjM0NTY3ODkw
YWJjZGVmDQpIVFRQX0FDQ0VQVDogMTIzNDU2Nzg5MGFiY2RlZg0KSFRUUF9BQ0NFUFRfRU5DT0RJ
Tkc6IDEyMzQ1Njc4OTBhYmNkZWYNCkhUVFBfQUNDRVBUX0xBTkdVQUdFOiAxMjM0NTY3ODkwYWJj
ZGVmDQpIVFRQX0NBQ0hFX0NPTlRST0w6IDEyMzQ1Njc4OTBhYmNkZWYNCkhUVFBfQ09OTkVDVElP
TjogMTIzNDU2Nzg5MGFiY2RlZg0KSFRUUF9ETlQ6IDEyMzQ1Njc4OTBhYmNkZWYNCkhUVFBfSE9T
VDogMTIzNDU2Nzg5MGFiY2RlZg0KSFRUUF9PUklHSU46IDEyMzQ1Njc4OTBhYmNkZWYNCkhUVFBf
UkVGRVJFUjogMTIzNDU2Nzg5MGFiY2RlZg0KSFRUUF9VUEdSQURFX0lOU0VDVVJFX1JFUVVFU1RT
OiAxMjM0NTY3ODkwYWJjZGVmDQpIVFRQX1VTRVJfQUdFTlQ6IDEyMzQ1Njc4OTBhYmNkZWYNClBB
VEg6IDEyMzQ1Njc4OTBhYmNkZWYNClFVRVJZX1NUUklORzogMTIzNDU2Nzg5MGFiY2RlZg0KUkVE
SVJFQ1RfSFRUUFM6IDEyMzQ1Njc4OTBhYmNkZWYNClJFRElSRUNUX1NTTF9UTFNfU05JOiAxMjM0
NTY3ODkwYWJjZGVmDQpSRURJUkVDVF9TVEFUVVM6IDEyMzQ1Njc4OTBhYmNkZWYNClJFRElSRUNU
X1VOSVFVRV9JRDogMTIzNDU2Nzg5MGFiY2RlZg0KUkVESVJFQ1RfVVJMOiAxMjM0NTY3ODkwYWJj
ZGVmDQpSRU1PVEVfQUREUjogMTIzNDU2Nzg5MGFiY2RlZg0KUkVNT1RFX1BPUlQ6IDEyMzQ1Njc4
OTBhYmNkZWYNClJFUVVFU1RfTUVUSE9EOiAxMjM0NTY3ODkwYWJjZGVmDQpSRVFVRVNUX1NDSEVN
RTogMTIzNDU2Nzg5MGFiY2RlZg0KUkVRVUVTVF9VUkk6IDEyMzQ1Njc4OTBhYmNkZWYNClNDUklQ
VF9GSUxFTkFNRTogMTIzNDU2Nzg5MGFiY2RlZg0KU0NSSVBUX05BTUU6IDEyMzQ1Njc4OTBhYmNk
ZWYNClNFUlZFUl9BRERSOiAxMjM0NTY3ODkwYWJjZGVmDQpTRVJWRVJfQURNSU46IDEyMzQ1Njc4
OTBhYmNkZWYNClNFUlZFUl9OQU1FOiAxMjM0NTY3ODkwYWJjZGVmDQpTRVJWRVJfUE9SVDogMTIz
NDU2Nzg5MGFiY2RlZg0KU0VSVkVSX1BST1RPQ09MOiAxMjM0NTY3ODkwYWJjZGVmDQpTRVJWRVJf
U0lHTkFUVVJFOiAxMjM0NTY3ODkwYWJjZGVmDQpTRVJWRVJfU09GVFdBUkU6IDEyMzQ1Njc4OTBh
YmNkZWYNClNTTF9UTFNfU05JOiAxMjM0NTY3ODkwYWJjZGVmDQpVTklRVUVfSUQ6IDEyMzQ1Njc4
OTBhYmNkZWYNCg==
----------------

This one does not:
------------------

Return-Path: <sender at senderdomain.com>
X-Original-To: receiver at receiverdomain.com
Delivered-To: receiver at receiverdomain.com
Received: from [127.0.0.1] (smtp [127.0.0.1])
        by smtp.receiverdomain.com (Postfix) with ESMTP id 0D25523C0063
        for <receiver at receiverdomain.com>; Mon, 27 Aug 2018 09:21:13 +0300 (EEST)
Subject: Malformed base64
From: sender at senderdomain.com
To: receiver at receiverdomain.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-Id: <20180827062113.0D25523C0063 at smtp.receiverdomain.com>
Date: Mon, 27 Aug 2018 09:21:13 +0300 (EEST)

Q09OVEVOVF9MRU5HVEg6IDEyMzQ1Njc4OTBhYmNkZWYKQ09OVEVOVF9UWVBFOiAxMjM0NTY3ODkwYQ==
YmNkZWYKQ09OVEVYVF9ET0NVTUVOVF9ST09UOiAxMjM0NTY3ODkwYWJjZGVmCkNPTlRFWFRfUFJFRg==
SVg6IDEyMzQ1Njc4OTBhYmNkZWYKRE9DVU1FTlRfUk9PVDogMTIzNDU2Nzg5MGFiY2RlZgpHQVRFVw==
QVlfSU5URVJGQUNFOiAxMjM0NTY3ODkwYWJjZGVmCkhUVFBTOiAxMjM0NTY3ODkwYWJjZGVmCkhUVA==
UF9BQ0NFUFQ6IDEyMzQ1Njc4OTBhYmNkZWYKSFRUUF9BQ0NFUFRfRU5DT0RJTkc6IDEyMzQ1Njc4OQ==
MGFiY2RlZgpIVFRQX0FDQ0VQVF9MQU5HVUFHRTogMTIzNDU2Nzg5MGFiY2RlZgpIVFRQX0NBQ0hFXw==
Q09OVFJPTDogMTIzNDU2Nzg5MGFiY2RlZgpIVFRQX0NPTk5FQ1RJT046IDEyMzQ1Njc4OTBhYmNkZQ==
ZgpIVFRQX0ROVDogMTIzNDU2Nzg5MGFiY2RlZgpIVFRQX0hPU1Q6IDEyMzQ1Njc4OTBhYmNkZWYKSA==
VFRQX09SSUdJTjogMTIzNDU2Nzg5MGFiY2RlZgpIVFRQX1JFRkVSRVI6IDEyMzQ1Njc4OTBhYmNkZQ==
ZgpIVFRQX1VQR1JBREVfSU5TRUNVUkVfUkVRVUVTVFM6IDEyMzQ1Njc4OTBhYmNkZWYKSFRUUF9VUw==
RVJfQUdFTlQ6IDEyMzQ1Njc4OTBhYmNkZWYKUEFUSDogMTIzNDU2Nzg5MGFiY2RlZgpRVUVSWV9TVA==
UklORzogMTIzNDU2Nzg5MGFiY2RlZgpSRURJUkVDVF9IVFRQUzogMTIzNDU2Nzg5MGFiY2RlZgpSRQ==
RElSRUNUX1NTTF9UTFNfU05JOiAxMjM0NTY3ODkwYWJjZGVmClJFRElSRUNUX1NUQVRVUzogMTIzNA==
NTY3ODkwYWJjZGVmClJFRElSRUNUX1VOSVFVRV9JRDogMTIzNDU2Nzg5MGFiY2RlZgpSRURJUkVDVA==
X1VSTDogMTIzNDU2Nzg5MGFiY2RlZgpSRU1PVEVfQUREUjogMTIzNDU2Nzg5MGFiY2RlZgpSRU1PVA==
RV9QT1JUOiAxMjM0NTY3ODkwYWJjZGVmClJFUVVFU1RfTUVUSE9EOiAxMjM0NTY3ODkwYWJjZGVmCg==
UkVRVUVTVF9TQ0hFTUU6IDEyMzQ1Njc4OTBhYmNkZWYKUkVRVUVTVF9VUkk6IDEyMzQ1Njc4OTBhYg==
Y2RlZgpTQ1JJUFRfRklMRU5BTUU6IDEyMzQ1Njc4OTBhYmNkZWYKU0NSSVBUX05BTUU6IDEyMzQ1Ng==
Nzg5MGFiY2RlZgpTRVJWRVJfQUREUjogMTIzNDU2Nzg5MGFiY2RlZgpTRVJWRVJfQURNSU46IDEyMw==
NDU2Nzg5MGFiY2RlZgpTRVJWRVJfTkFNRTogMTIzNDU2Nzg5MGFiY2RlZgpTRVJWRVJfUE9SVDogMQ==
MjM0NTY3ODkwYWJjZGVmClNFUlZFUl9QUk9UT0NPTDogMTIzNDU2Nzg5MGFiY2RlZgpTRVJWRVJfUw==
SUdOQVRVUkU6IDEyMzQ1Njc4OTBhYmNkZWYKU0VSVkVSX1NPRlRXQVJFOiAxMjM0NTY3ODkwYWJjZA==
ZWYKU1NMX1RMU19TTkk6IDEyMzQ1Njc4OTBhYmNkZWYKVU5JUVVFX0lEOiAxMjM0NTY3ODkwYWJjZA==
ZWYK
-----------------

----------
nosy: +AldarisPale

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34025>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:54:19 2018
From: report at bugs.python.org (monson)
Date: Mon, 27 Aug 2018 06:54:19 +0000
Subject: [issue34515] lib2to3: support non-ASCII identifiers
In-Reply-To: <1535352467.5.0.56676864532.issue34515@psf.upfronthosting.co.za>
Message-ID: <1535352859.59.0.56676864532.issue34515@psf.upfronthosting.co.za>


Change by monson <holymonson at gmail.com>:


----------
keywords: +patch
pull_requests: +8426
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34515>
_______________________________________

From report at bugs.python.org  Mon Aug 27 02:59:32 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 06:59:32 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1535353172.71.0.56676864532.issue32968@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:


New changeset 393f1ff62e032f20adaed2613a9e2d2d6bcb1eb3 by Mark Dickinson (Elias Zamaria) in branch 'master':
bpo-32968: Make modulo and floor division involving Fraction and float consistent with other operations (#5956)
https://github.com/python/cpython/commit/393f1ff62e032f20adaed2613a9e2d2d6bcb1eb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Mon Aug 27 03:13:21 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 07:13:21 +0000
Subject: [issue32968] Fraction modulo infinity should behave consistently with
 other numbers
In-Reply-To: <1519787451.54.0.467229070634.issue32968@psf.upfronthosting.co.za>
Message-ID: <1535354001.03.0.56676864532.issue32968@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed for Python 3.8. Thank you!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32968>
_______________________________________

From report at bugs.python.org  Mon Aug 27 03:51:08 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 07:51:08 +0000
Subject: [issue34514] assertEqual doesn't use maxDiff when comparing
 dictionaries
In-Reply-To: <1535336469.7.0.56676864532.issue34514@psf.upfronthosting.co.za>
Message-ID: <1535356268.71.0.56676864532.issue34514@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@prudvinit 

Reference : https://docs.python.org/3.8/library/unittest.html#unittest.TestCase.maxDiff

> This attribute controls the maximum length of diffs output by assert methods that report diffs on failure. It defaults to 80*8 characters. Assert methods affected by this attribute are assertSequenceEqual() (including all the sequence comparison methods that delegate to it), assertDictEqual() and assertMultiLineEqual().

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34514>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:08:54 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 08:08:54 +0000
Subject: [issue34514] assertEqual doesn't use maxDiff when comparing
 dictionaries
In-Reply-To: <1535336469.7.0.56676864532.issue34514@psf.upfronthosting.co.za>
Message-ID: <1535357334.66.0.56676864532.issue34514@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@victor I am little confused over the issue since you have said "`assertDictEqual()` "will be used by default to compare dictionaries in calls to assertEqual()" and "`maxDiff` doesn't apply to `assertEqual()` when comparing dictionaries" . Since assertDictEqual is used for assertEqual calls when they compare dictionaries I can see that maxDiff value is applied to the diffs. A script will be helpful here on the expected and actual output. The attached script I have used to check that the maxDiff value is applied.


$ ./python.exe ../backups/bpo34514.py

FFFF
======================================================================
FAIL: test_assert_dict_equal_large_diff (__main__.Test_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo34514.py", line 59, in test_assert_dict_equal_large_diff
    self.assertDictEqual(original, expected)
AssertionError: {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, [726 chars]: 99} != {101: 101, 102: 102, 103: 103, 104: 104, 10[942 chars] 199}
Diff is 3347 characters long. Set self.maxDiff to None to see it.

======================================================================
FAIL: test_assert_dict_equal_small_diff (__main__.Test_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo34514.py", line 31, in test_assert_dict_equal_small_diff
    self.assertDictEqual(original, expected)
AssertionError: {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} != {101: 101, 102: 102, 103: 103, 104: 104, 10[42 chars] 109}
- {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9}
+ {101: 101,
+  102: 102,
+  103: 103,
+  104: 104,
+  105: 105,
+  106: 106,
+  107: 107,
+  108: 108,
+  109: 109}

======================================================================
FAIL: test_assert_equal_large_diff (__main__.Test_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo34514.py", line 45, in test_assert_equal_large_diff
    self.assertEqual(original, expected)
AssertionError: {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, [726 chars]: 99} != {101: 101, 102: 102, 103: 103, 104: 104, 10[942 chars] 199}
Diff is 3347 characters long. Set self.maxDiff to None to see it.

======================================================================
FAIL: test_assert_equal_small_diff (__main__.Test_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo34514.py", line 17, in test_assert_equal_small_diff
    self.assertEqual(original, expected)
AssertionError: {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9} != {101: 101, 102: 102, 103: 103, 104: 104, 10[42 chars] 109}
- {1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 8, 9: 9}
+ {101: 101,
+  102: 102,
+  103: 103,
+  104: 104,
+  105: 105,
+  106: 106,
+  107: 107,
+  108: 108,
+  109: 109}

----------------------------------------------------------------------
Ran 4 tests in 3.496s

FAILED (failures=4)


Thanks

----------
Added file: https://bugs.python.org/file47764/bpo34514.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34514>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:13:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 08:13:06 +0000
Subject: [issue19217] Calling assertEquals for moderately long list takes too
 long
In-Reply-To: <1381410286.72.0.514206486634.issue19217@psf.upfronthosting.co.za>
Message-ID: <1535357586.82.0.56676864532.issue19217@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19217>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:19:47 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 08:19:47 +0000
Subject: [issue34334] QueueHandler logs exc_info twice
In-Reply-To: <1533377293.21.0.56676864532.issue34334@psf.upfronthosting.co.za>
Message-ID: <1535357987.21.0.56676864532.issue34334@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34334>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:28:33 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 08:28:33 +0000
Subject: [issue34487] enum _sunder_ names mix metaclass and enum class
 attributes
In-Reply-To: <1535121871.11.0.56676864532.issue34487@psf.upfronthosting.co.za>
Message-ID: <1535358513.54.0.56676864532.issue34487@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34487>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:38:24 2018
From: report at bugs.python.org (monson)
Date: Mon, 27 Aug 2018 08:38:24 +0000
Subject: [issue34219] distutils: build_ext -D wrongly assume defining a symbol
 with no value
In-Reply-To: <1532509080.28.0.56676864532.issue34219@psf.upfronthosting.co.za>
Message-ID: <1535359104.19.0.56676864532.issue34219@psf.upfronthosting.co.za>


Change by monson <holymonson at gmail.com>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34219>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:39:07 2018
From: report at bugs.python.org (monson)
Date: Mon, 27 Aug 2018 08:39:07 +0000
Subject: [issue34515] lib2to3: support non-ASCII identifiers
In-Reply-To: <1535352467.5.0.56676864532.issue34515@psf.upfronthosting.co.za>
Message-ID: <1535359147.78.0.56676864532.issue34515@psf.upfronthosting.co.za>


Change by monson <holymonson at gmail.com>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34515>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:39:46 2018
From: report at bugs.python.org (harobed)
Date: Mon, 27 Aug 2018 08:39:46 +0000
Subject: [issue34511] I suggest to add documentation about "method" parameter
 of urllib.request.Request class
In-Reply-To: <1535316589.49.0.56676864532.issue34511@psf.upfronthosting.co.za>
Message-ID: <1535359186.59.0.56676864532.issue34511@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

? Mariatta Wijaya

Thanks.

Sorry for my bad issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34511>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:42:26 2018
From: report at bugs.python.org (Alex Mashianov)
Date: Mon, 27 Aug 2018 08:42:26 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
Message-ID: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>


New submission from Alex Mashianov <mashianov at gmail.com>:

This code:
class A:
    a = 1
    b = {str(x): x for x in range(5) if x != a}

Produces following error:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "<input>", line 3, in A
  File "<input>", line 3, in <dictcomp>
NameError: name 'a' is not defined


Which i think it shouldn't produce. Issue occurs only in dict comprehensions inside class definitions referencing class attributes(which are in local scope during definition).

----------
components: Interpreter Core
messages: 324156
nosy: Alex Mashianov
priority: normal
severity: normal
status: open
title: Error referencing local variables in dict comprehensions inside class definitions
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:44:48 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 27 Aug 2018 08:44:48 +0000
Subject: [issue34518] Documentation for coroutine objects
Message-ID: <1535359488.51.0.56676864532.issue34518@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

Coroutine objects have public methods such as send, close, and throw, which do not appear to be documented. For example, at https://stackoverflow.com/q/51975658/1600898 a StackOverflow user asks how to abort an already created (but not submitted) coroutine without a RuntimeWarning, with the answer being to use the close() method. The user asked where does one find the close method.

Currently methods only appear to be documented in PEP 492, referring to generator documentation for details. The glossary entry for coroutine (object) links to PEP 492 and to the async def statement. Various places in the documentation, e.g. the index, link to https://docs.python.org/3/library/asyncio-task.html#coroutine but that page is mostly concerned with the usage of coroutines within asyncio, where the methods on individual coroutine objects should not be used.

I would expect to find documentation on coroutine objects under built-in types, https://docs.python.org/3/library/stdtypes.html .

In comparison, generator-iterator methods are documented in the language reference:

https://docs.python.org/3/reference/expressions.html#generator-iterator-methods

----------
assignee: docs at python
components: Documentation
messages: 324157
nosy: docs at python, hniksic
priority: normal
severity: normal
status: open
title: Documentation for coroutine objects
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34518>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:45:44 2018
From: report at bugs.python.org (Alex Mashianov)
Date: Mon, 27 Aug 2018 08:45:44 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535359544.08.0.56676864532.issue34517@psf.upfronthosting.co.za>


Alex Mashianov <mashianov at gmail.com> added the comment:

Update: any class definition comprehension referencing local variables inside filtering block produces this error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 04:46:06 2018
From: report at bugs.python.org (Alex Mashianov)
Date: Mon, 27 Aug 2018 08:46:06 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535359566.56.0.56676864532.issue34517@psf.upfronthosting.co.za>


Change by Alex Mashianov <mashianov at gmail.com>:


----------
versions: +Python 3.6 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 05:30:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2018 09:30:55 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535362255.3.0.56676864532.issue34517@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue3692.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> improper scope in list comprehension, when used in class declaration

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 05:45:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2018 09:45:57 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1535363157.94.0.56676864532.issue34427@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Agreed. Appending >2**31 items one by one to the collection with external storage is not very efficient, so such collection likely has specialized extend().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Mon Aug 27 05:55:02 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2018 09:55:02 +0000
Subject: [issue32836] Symbol table for comprehensions (list, dict,
 set) still includes temporary _[1] variable
In-Reply-To: <1518471231.56.0.467229070634.issue32836@psf.upfronthosting.co.za>
Message-ID: <1535363702.08.0.56676864532.issue32836@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32836>
_______________________________________

From report at bugs.python.org  Mon Aug 27 05:59:16 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2018 09:59:16 +0000
Subject: [issue26694] Disasembler fall with Key Error while disassemble
 obfuscated code.
In-Reply-To: <1459849877.74.0.679437404849.issue26694@psf.upfronthosting.co.za>
Message-ID: <1535363956.42.0.56676864532.issue26694@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The dis module is not supposed to support invalid bytecode. This is a new feature, and 2.7 can give only bug fixes.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26694>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:00:14 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 10:00:14 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535364014.92.0.56676864532.issue34517@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[I wrote this before Serhiy posted his reply; sending it anyway, in case the doc links are useful.]

This is documented, by-design behaviour. Essentially name resolution skips class scopes.

See https://docs.python.org/3/reference/executionmodel.html#resolution-of-names, and particularly the example at the end of that section, which is very similar to your example.

See also: https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries, and in particular this part:

> However, aside from the iterable expression in the leftmost for clause,
> the comprehension is executed in a separate implicitly nested scope.
> This ensures that names assigned to in the target list don?t ?leak? into
> the enclosing scope.

That "leftmost for clause" bit explains why, in the following example, the first comprehension is evaluated successfully, but the second raises a `NameError`.

>>> class A:
...     a = 3
...     b = [x+y for x in range(a) for y in range(3)]  # okay
...     c = [x+y for x in range(3) for y in range(a)]  # raises

----------
nosy: +mark.dickinson -serhiy.storchaka
resolution: duplicate -> not a bug
stage: resolved -> 
superseder: improper scope in list comprehension, when used in class declaration -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:00:55 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 10:00:55 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535364055.33.0.56676864532.issue34517@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution: not a bug -> duplicate
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:01:25 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 10:01:25 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535364085.51.0.56676864532.issue34517@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
superseder:  -> improper scope in list comprehension, when used in class declaration

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:01:47 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 10:01:47 +0000
Subject: [issue34517] Error referencing local variables in dict comprehensions
 inside class definitions
In-Reply-To: <1535359346.38.0.56676864532.issue34517@psf.upfronthosting.co.za>
Message-ID: <1535364107.44.0.56676864532.issue34517@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34517>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:10:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2018 10:10:46 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535364646.43.0.56676864532.issue34171@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b44a1d4f71daf4edb948b9878f82a60891e4a2e1 by Serhiy Storchaka in branch 'master':
bpo-34171: Fix test_trace. (GH-8940)
https://github.com/python/cpython/commit/b44a1d4f71daf4edb948b9878f82a60891e4a2e1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:11:00 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 10:11:00 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535364660.6.0.56676864532.issue34171@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8427

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:29:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2018 10:29:56 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1535365796.41.0.56676864532.issue26544@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7d81e8f5995df6980a1a02923e224a481375f130 by Serhiy Storchaka in branch 'master':
bpo-26544: Get rid of dependence from distutils in platform. (GH-8356)
https://github.com/python/cpython/commit/7d81e8f5995df6980a1a02923e224a481375f130


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:30:13 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 10:30:13 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1535365813.5.0.56676864532.issue26544@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8428

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:39:40 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 27 Aug 2018 10:39:40 +0000
Subject: [issue34487] enum _sunder_ names mix metaclass and enum class
 attributes
In-Reply-To: <1535121871.11.0.56676864532.issue34487@psf.upfronthosting.co.za>
Message-ID: <1535366380.35.0.56676864532.issue34487@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Is it really need to be documented?
How is it important when using enum?

If there are no problem, I prefer keeping it implementation detail and don't make document fatter.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34487>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:45:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 27 Aug 2018 10:45:30 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1535366730.01.0.56676864532.issue34434@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:


New changeset 3fe89dac42809a7741d50ebf595be98833b79b97 by Xiang Zhang (Louis Sautier) in branch 'master':
bpo-34434: Update doc for bool(), float() and int() arguments (GH-8834)
https://github.com/python/cpython/commit/3fe89dac42809a7741d50ebf595be98833b79b97


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:45:36 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 10:45:36 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1535366736.77.0.56676864532.issue34434@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8429

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:46:41 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 27 Aug 2018 10:46:41 +0000
Subject: [issue3692] improper scope in list comprehension,
 when used in class declaration
In-Reply-To: <1219792814.12.0.663300668565.issue3692@psf.upfronthosting.co.za>
Message-ID: <1535366801.18.0.56676864532.issue3692@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3692>
_______________________________________

From report at bugs.python.org  Mon Aug 27 06:59:00 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 10:59:00 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1535367540.49.0.56676864532.issue34434@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fa3fd4cb181120007aefc408366c0cef6fb62f9d by Miss Islington (bot) in branch '3.7':
bpo-34434: Update doc for bool(), float() and int() arguments (GH-8834)
https://github.com/python/cpython/commit/fa3fd4cb181120007aefc408366c0cef6fb62f9d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Mon Aug 27 07:00:42 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 27 Aug 2018 11:00:42 +0000
Subject: [issue34434] Removal of kwargs for built-in types not covered with
 "changed in Python" note in documentation
In-Reply-To: <1534685830.81.0.56676864532.issue34434@psf.upfronthosting.co.za>
Message-ID: <1535367642.19.0.56676864532.issue34434@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34434>
_______________________________________

From report at bugs.python.org  Mon Aug 27 07:03:32 2018
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 27 Aug 2018 11:03:32 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1535367812.88.0.56676864532.issue30858@psf.upfronthosting.co.za>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Nick, thanks for validating my pain. :-|

In the meantime, I found out Python already knows more finely what kind of expression something is, and uses that knowledge in the error messages. Look:

    >>> a + b = 4
    SyntaxError: can't assign to operator
    >>> a(b) = 4
    SyntaxError: can't assign to function call
    >>> 'a' = 4
    SyntaxError: can't assign to literal

So, how about "keyword argument name cannot be an operator / function call / literal"? (Of course, if you ask me, "operator" is also unfortunate, but at least there is a precedent.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Mon Aug 27 07:42:54 2018
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 27 Aug 2018 11:42:54 +0000
Subject: [issue34355] SIGSEGV (Address boundary error)
In-Reply-To: <1533710842.16.0.56676864532.issue34355@psf.upfronthosting.co.za>
Message-ID: <1535370174.14.0.56676864532.issue34355@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I think so.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> int(s), float(s) and others may cause segmentation fault

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34355>
_______________________________________

From report at bugs.python.org  Mon Aug 27 07:50:35 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 27 Aug 2018 11:50:35 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1535370635.42.0.56676864532.issue11192@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8430
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Mon Aug 27 08:31:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 12:31:41 +0000
Subject: [issue34486] "RuntimeError: release unlocked lock" when starting a
 thread
In-Reply-To: <1535119355.34.0.56676864532.issue34486@psf.upfronthosting.co.za>
Message-ID: <1535373101.9.0.56676864532.issue34486@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

cond_race.py: simplified example using threading.Lock and threading.Condition: the issue seems to be related to threading.Event which doesn't handle properly signals.

----------
nosy: +pitrou, serhiy.storchaka
Added file: https://bugs.python.org/file47765/cond_race.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34486>
_______________________________________

From report at bugs.python.org  Mon Aug 27 08:58:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 12:58:06 +0000
Subject: [issue34518] Documentation for coroutine objects
In-Reply-To: <1535359488.51.0.56676864532.issue34518@psf.upfronthosting.co.za>
Message-ID: <1535374686.43.0.56676864532.issue34518@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34518>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:06:53 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 13:06:53 +0000
Subject: [issue34518] Documentation for coroutine objects
In-Reply-To: <1535359488.51.0.56676864532.issue34518@psf.upfronthosting.co.za>
Message-ID: <1535375213.84.0.56676864532.issue34518@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this what you are referring to that has docs for send, close and throw in coroutine objects ? 
Coroutine object docs : https://docs.python.org/3/reference/datamodel.html#coroutine-objects

If the above is the one then I think we can improve on the visibility by linking it from other pages since it doesn't show up with Google for 'coroutine close'. I had to use Docs folder in source code and sphinx search in docs.python.org with 'coroutine close' to get there.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34518>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:10:46 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Aug 2018 13:10:46 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1535375446.23.0.56676864532.issue34516@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:22:08 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 13:22:08 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535376128.65.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

So I changed the test code to:

diff --git a/Lib/test/test_utf8_mode.py b/Lib/test/test_utf8_mode.py
index 26e2e13ec5..d9f8a3ed8b 100644
--- a/Lib/test/test_utf8_mode.py
+++ b/Lib/test/test_utf8_mode.py
@@ -208,7 +208,7 @@ class UTF8ModeTests(unittest.TestCase):
     def test_cmd_line(self):
         arg = 'h\xe9\u20ac'.encode('utf-8')
         arg_utf8 = arg.decode('utf-8')
-        arg_ascii = arg.decode('ascii', 'surrogateescape')
+        arg_ascii = arg.decode('roman8', 'surrogateescape')
         code = 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))'

         def check(utf8_opt, expected, **kw):

and the output is:
======================================================================
FAIL: test_cmd_line (test.test_utf8_mode.UTF8ModeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 224, in test_cmd_line
    check('utf8=0', [c_arg], LC_ALL='C')
  File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 217, in check
    self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\xfb\\u02cb\\xe3\\x82\\u02dc']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\xfb\u02cb\xe3\x82\u02dc']
 : roman8:['h\xc3\xa9\xe2\x82\xac']

I still don't understand that.

I believe that surrogate escape only works for ASCII and nothing else. If so, this test must be skipped on HP-UX and AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:22:24 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Mon, 27 Aug 2018 13:22:24 +0000
Subject: [issue34518] Documentation for coroutine objects
In-Reply-To: <1535359488.51.0.56676864532.issue34518@psf.upfronthosting.co.za>
Message-ID: <1535376144.86.0.56676864532.issue34518@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

That's exactly it, thanks! I have no idea how I missed it, despite looking (I thought) carefully.

But yes, they should be linked from https://docs.python.org/3/library/stdtypes.html . Just as currently there is https://docs.python.org/3/library/stdtypes.html#generator-types that links to https://docs.python.org/3/reference/expressions.html#yieldexpr , there could be a #coroutine-types that links to https://docs.python.org/3/reference/datamodel.html#coroutine-objects

Another place to link is https://docs.python.org/3/glossary.html#term-coroutine - it currently does link to the reference, but only to the "async def" syntax.

Since https://docs.python.org/3/reference/compound_stmts.html#async-def is linked from many places, it might make sense to mention that *calling* a coroutine immediately returns a coroutine object, with a link to https://docs.python.org/3/reference/datamodel.html#coroutine-objects

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34518>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:32:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 13:32:34 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535376754.9.0.56676864532.issue34502@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Yes, it's a note for sys.flags. Can you please add it back to sys.flags?

Sorry, I added the note at the wrong place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:32:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 13:32:45 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535376765.0.0.56676864532.issue34502@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:34:00 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 13:34:00 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535376840.65.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Maybe skipping the test is the best thing:
diff --git a/Lib/test/test_utf8_mode.py b/Lib/test/test_utf8_mode.py
index 26e2e13ec5..d6c4b321be 100644
--- a/Lib/test/test_utf8_mode.py
+++ b/Lib/test/test_utf8_mode.py
@@ -12,7 +12,7 @@ from test.support.script_helper import assert_python_ok, assert_python_failure


 MS_WINDOWS = (sys.platform == 'win32')
-
+HPUX = (sys.platform.startswith('hp-ux'))

 class UTF8ModeTests(unittest.TestCase):
     DEFAULT_ENV = {
@@ -205,6 +205,7 @@ class UTF8ModeTests(unittest.TestCase):
         self.assertEqual(out, 'UTF-8 UTF-8')

     @unittest.skipIf(MS_WINDOWS, 'test specific to Unix')
+    @unittest.skipIf(HPUX, 'test specific to Unix with ASCII default locale')
     def test_cmd_line(self):
         arg = 'h\xe9\u20ac'.encode('utf-8')
         arg_utf8 = arg.decode('utf-8')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:35:08 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 13:35:08 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535376908.95.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Maybe Victor Stinner has some insights here.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:38:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 13:38:03 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1535377083.34.0.56676864532.issue13312@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Note for myself: Python 2.7 is not affected by this bug because it doesn't accept year < 1900.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13312>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:39:51 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 13:39:51 +0000
Subject: [issue34519] Add additional aliases for HP Roman 8
Message-ID: <1535377191.85.0.56676864532.issue34519@psf.upfronthosting.co.za>


New submission from Michael Osipov <1983-01-06 at gmx.net>:

HP Roman 8 is also known as 'hp-roman8', 'cp1051' and 'ibm1051'. They are missing from the aliases.py.

----------
components: Library (Lib)
messages: 324178
nosy: michael-o
priority: normal
severity: normal
status: open
title: Add additional aliases for HP Roman 8
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34519>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:40:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 13:40:21 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535377221.86.0.56676864532.issue34347@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7ef1697be54a74314d5214d9ba0580d4e620694c by Victor Stinner (Michael Felt) in branch 'master':
bpo-34347: Fix test_utf8_mode.test_cmd_line for AIX (GH-8923)
https://github.com/python/cpython/commit/7ef1697be54a74314d5214d9ba0580d4e620694c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:47:31 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 13:47:31 +0000
Subject: [issue34519] Add additional aliases for HP Roman 8
In-Reply-To: <1535377191.85.0.56676864532.issue34519@psf.upfronthosting.co.za>
Message-ID: <1535377651.46.0.56676864532.issue34519@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8431
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34519>
_______________________________________

From report at bugs.python.org  Mon Aug 27 09:49:38 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 13:49:38 +0000
Subject: [issue14568] HP-UX local libraries not included
In-Reply-To: <1334265845.44.0.154291439069.issue14568@psf.upfronthosting.co.za>
Message-ID: <1535377778.72.0.56676864532.issue14568@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Can someone review the PR for this?

----------
nosy: +michael-o
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14568>
_______________________________________

From report at bugs.python.org  Mon Aug 27 10:24:43 2018
From: report at bugs.python.org (Michael Osipov)
Date: Mon, 27 Aug 2018 14:24:43 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535379883.69.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Interesting is that the very same approach does not work for HP-UX even if I swap out the params for HP-UX:

$ ./python -m test test_utf8_mode
Run tests sequentially
0:00:00 [1/1] test_utf8_mode
test test_utf8_mode failed -- Traceback (most recent call last):
  File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 226, in test_cmd_line
    check('utf8=0', [c_arg], LC_ALL='C')
  File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 217, in check
    self.assertEqual(args, ascii(expected), out)
AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\xfb\\u02cb\\xe3\\x82\\u02dc']"
- ['h\xc3\xa9\xe2\x82\xac']
+ ['h\xfb\u02cb\xe3\x82\u02dc']
 : roman8:['h\xc3\xa9\xe2\x82\xac']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Mon Aug 27 10:51:31 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 27 Aug 2018 14:51:31 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535381491.39.0.56676864532.issue34502@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Victor, but sys.flags docs *do* contain the note[1]:

Changed in version 3.7: Added dev_mode attribute for the new -X dev flag and utf8_mode attribute for the new -X utf8 flag.

I've tried to express that in msg324086, but obviously failed.

[1] https://docs.python.org/3/library/sys.html#sys.flags

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Mon Aug 27 10:55:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 14:55:36 +0000
Subject: [issue34502] Docs of sys.exit() mention utf8_mode for an unclear
 reason
In-Reply-To: <1535219668.13.0.56676864532.issue34502@psf.upfronthosting.co.za>
Message-ID: <1535381736.38.0.56676864532.issue34502@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Ah ok, in this case, everything is fine :-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34502>
_______________________________________

From report at bugs.python.org  Mon Aug 27 12:06:06 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Aug 2018 16:06:06 +0000
Subject: [issue34470] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534996213.68.0.56676864532.issue34470@psf.upfronthosting.co.za>
Message-ID: <1535385966.74.0.56676864532.issue34470@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Can you please provide the full set of logs for the Python 3.7 install? (They'll be in %TEMP%, and there will be quite a number of them.)

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34470>
_______________________________________

From report at bugs.python.org  Mon Aug 27 12:07:31 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Aug 2018 16:07:31 +0000
Subject: [issue34470] windows msi in headless mode fails to install Script
 directory on reinstall if the python folder was deleted but not uninstalled
In-Reply-To: <1534996213.68.0.56676864532.issue34470@psf.upfronthosting.co.za>
Message-ID: <1535386051.38.0.56676864532.issue34470@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Also, if you could provide some instructions on how to validate the issue you are reporting. Right now, I'm not even sure what you are seeing that is the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34470>
_______________________________________

From report at bugs.python.org  Mon Aug 27 12:11:21 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Aug 2018 16:11:21 +0000
Subject: [issue34489] subprocess: execution of batch-files (.cmd/.bat) is
 vulnerable in python for windows / insufficient escape
In-Reply-To: <1535139850.17.0.56676864532.issue34489@psf.upfronthosting.co.za>
Message-ID: <1535386281.01.0.56676864532.issue34489@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Would you consider adding your test suite into the regression tests as well?

Right now, this is a well known issue on all platforms, but there is no clear universal solution. If your approach works well for all platforms and does not adversely impact any of them, it could be considered. But otherwise, we would prefer to keep our advice to not use subprocess with untrusted data while still allowing it in circumstances where the developer chooses otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34489>
_______________________________________

From report at bugs.python.org  Mon Aug 27 12:22:27 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 16:22:27 +0000
Subject: [issue34520] test_asyncio leaked [2, 2, 2] references,
 sum=6 in AMD64 Windows8.1 Refleaks 3.7
Message-ID: <1535386947.0.0.56676864532.issue34520@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_asyncio is potentially leaking resources in AMD64 Windows8.1 Refleaks 3.7:

https://buildbot.python.org/all/#/builders/132/builds/241

----------------------------------------------------------------------
Ran 1782 tests in 115.342s
OK (skipped=78)
.
test_asyncio leaked [2, 2, 2] references, sum=6
test_asyncio leaked [2, 3, 2] memory blocks, sum=7
3 tests failed again:
    test_asyncio test_smtplib test_trace
== Tests result: FAILURE then FAILURE ==
383 tests OK.

----------
components: Tests, Windows, asyncio
messages: 324187
nosy: asvetlov, pablogsal, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: test_asyncio leaked [2, 2, 2] references, sum=6 in AMD64 Windows8.1 Refleaks 3.7
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34520>
_______________________________________

From report at bugs.python.org  Mon Aug 27 13:12:58 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 17:12:58 +0000
Subject: [issue34521] test_socket.RecvmsgIntoSCMRightsStreamTest fails on
 AMD64 FreeBSD CURRENT Debug 3.x
Message-ID: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_socket.RecvmsgIntoSCMRightsStreamTest fails on AMD64 FreeBSD CURRENT Debug 3.x:

https://buildbot.python.org/all/#/builders/60/builds/248


======================================================================
FAIL: testFDPassSeparateMinSpace (test.test_socket.RecvmsgIntoSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/pablo/cpython/Lib/test/test_socket.py", line 2881, in testFDPassSeparateMinSpace
    maxcmsgs=2, ignoreflags=socket.MSG_CTRUNC)
  File "/usr/home/pablo/cpython/Lib/test/test_socket.py", line 2798, in checkRecvmsgFDs
    self.assertEqual(len(fds), numfds)
AssertionError: 1 != 2

----------------------------------------------------------------------
Ran 18 tests in 0.084s

FAILED (failures=1)
test test_socket failed
test_socket failed

== Tests result: FAILURE ==

1 test failed:
    test_socket


I was able to reproduce the bug in the buildbot but this same test fails in 3.6 and 3.5 in the buildbot so it can be some configuration in the buildbot or some regression in FreeBSD.

----------
components: FreeBSD, Tests
messages: 324188
nosy: koobs, pablogsal
priority: normal
severity: normal
status: open
title: test_socket.RecvmsgIntoSCMRightsStreamTest fails on AMD64 FreeBSD CURRENT Debug 3.x
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Mon Aug 27 13:36:54 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Mon, 27 Aug 2018 17:36:54 +0000
Subject: [issue34514] assertEqual doesn't use maxDiff when comparing
 dictionaries
In-Reply-To: <1535336469.7.0.56676864532.issue34514@psf.upfronthosting.co.za>
Message-ID: <1535391414.96.0.56676864532.issue34514@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

I see that maxDiff is applied correctly when comparing dictionaries. I don't think that's an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34514>
_______________________________________

From report at bugs.python.org  Mon Aug 27 14:12:44 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Mon, 27 Aug 2018 18:12:44 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1535393563.99.0.56676864532.issue34516@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

I don't think urllib module is part of core python library. It's a 3rd party library which we usually install using pip

----------
nosy: +prudvinit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Mon Aug 27 14:45:05 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 27 Aug 2018 18:45:05 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
 path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1535395505.71.0.56676864532.issue17102@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I suggest marking this as a duplicate of #21109, which is more general and includes most of the relevant discussion and patches.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17102>
_______________________________________

From report at bugs.python.org  Mon Aug 27 14:45:09 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 27 Aug 2018 18:45:09 +0000
Subject: [issue1044] tarfile insecure pathname extraction
In-Reply-To: <1188295764.62.0.164889561412.issue1044@psf.upfronthosting.co.za>
Message-ID: <1535395509.89.0.56676864532.issue1044@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I suggest marking this as a duplicate of #21109, which is more general and includes most of the relevant discussion and patches.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1044>
_______________________________________

From report at bugs.python.org  Mon Aug 27 14:45:41 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 27 Aug 2018 18:45:41 +0000
Subject: [issue1044] tarfile insecure pathname extraction
In-Reply-To: <1188295764.62.0.164889561412.issue1044@psf.upfronthosting.co.za>
Message-ID: <1535395541.06.0.56676864532.issue1044@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
Removed message: https://bugs.python.org/msg324192

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1044>
_______________________________________

From report at bugs.python.org  Mon Aug 27 15:09:47 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 27 Aug 2018 19:09:47 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1535396987.74.0.56676864532.issue21109@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Lars, a huge +1 from me for your suggested approach and patch.  I'd like to work this into a review-ready PR.

The patch is a great step forward but still a ways from being ready for a PR: It is missing tests entirely and there are still several important methods of SafeTarFile which don't use the safety logic, e.g. next() and getmemebers().

Lars, would you be interested in continuing to work on this?

----------
nosy: +taleinat
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Mon Aug 27 15:50:50 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Aug 2018 19:50:50 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1535399450.92.0.56676864532.issue34498@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Mon Aug 27 16:21:23 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 20:21:23 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535401283.55.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I requested a SLES VM in https://linuxone20.cloud.marist.edu as indicated by @David Edelsohn (the builtbot maintainer) and I can reproduce the issue on master, 3.7, 3.6 and 3.5. So it seems that a change in gdb itself caused this. Interestingly, in Python 3.5 the error is different:

======================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/linux1/cpython/Lib/test/test_gdb.py", line 771, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 at 0x11751d8: file Python/bltinmodule.c, line 1093.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n[New Thread 0x3fffd2ff910 (LWP 33928)]\n[New Thread 0x3fffcaff910 (LWP 33929)]\n'

----------------------------------------------------------------------
Ran 45 tests in 19.522s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Mon Aug 27 16:25:41 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 27 Aug 2018 20:25:41 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
Message-ID: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

>From the documentation, it says that PyType_Ready should be called on `ALL` type objects to finish their initialization (https://docs.python.org/3/c-api/type.html#c.PyType_Ready). This means that a PyTypeObject's ob_type should always be set by PyType_Ready.

It turns out that this is not actually followed by all the core types in CPython. This leads to the usage of types that were not initialized through PyType_Ready.

This fix modifies PyVarObject_HEAD_INIT to default the type to NULL so that all objects have to be fully initialized through PyType_Ready.

Plus:
* It initializes all the objects that were not being initialized through PyType_Ready.
* Modifies PyType_Ready to special case the ob_type initialization of PyType_Type and PyBaseObject_Type.
* It modifies the edge case of _Py_FalseStruct and _Py_TrueStruct.

Read more: https://mail.python.org/pipermail/python-dev/2018-August/154946.html

----------
components: Interpreter Core
messages: 324195
nosy: eelizondo
priority: normal
severity: normal
status: open
title: PyTypeObject's tp_base initialization bug
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Mon Aug 27 16:27:26 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 27 Aug 2018 20:27:26 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535401646.15.0.56676864532.issue34522@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch
pull_requests: +8432
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Mon Aug 27 16:58:46 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 27 Aug 2018 20:58:46 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1535376128.65.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <77b3d8a0-5304-cd3e-fab8-fb2af52359af@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 27/08/2018 15:22, Michael Osipov wrote:
> Michael Osipov <1983-01-06 at gmx.net> added the comment:
>
> So I changed the test code to:
>
> diff --git a/Lib/test/test_utf8_mode.py b/Lib/test/test_utf8_mode.py
> index 26e2e13ec5..d9f8a3ed8b 100644
> --- a/Lib/test/test_utf8_mode.py
> +++ b/Lib/test/test_utf8_mode.py
> @@ -208,7 +208,7 @@ class UTF8ModeTests(unittest.TestCase):
>      def test_cmd_line(self):
>          arg = 'h\xe9\u20ac'.encode('utf-8')
>          arg_utf8 = arg.decode('utf-8')
> -        arg_ascii = arg.decode('ascii', 'surrogateescape')
> +        arg_ascii = arg.decode('roman8', 'surrogateescape')
>          code = 'import locale, sys; print("%s:%s" % (locale.getpreferredencoding(), ascii(sys.argv[1:])))'
>
>          def check(utf8_opt, expected, **kw):
>
> and the output is:
> ======================================================================
> FAIL: test_cmd_line (test.test_utf8_mode.UTF8ModeTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 224, in test_cmd_line
>     check('utf8=0', [c_arg], LC_ALL='C')
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 217, in check
>     self.assertEqual(args, ascii(expected), out)
> AssertionError: "['h\\xc3\\xa9\\xe2\\x82\\xac']" != "['h\\xfb\\u02cb\\xe3\\x82\\u02dc']"
> - ['h\xc3\xa9\xe2\x82\xac']
> + ['h\xfb\u02cb\xe3\x82\u02dc']
>  : roman8:['h\xc3\xa9\xe2\x82\xac']
>
> I still don't understand that.
Something I found helpful was to change:

??????? check('utf8=0', [c_arg], LC_ALL='C')

to
??????? check('utf8=0', [c_arg], LC_ALL='C', failure=True )

This also fails, but it shows what is being executed.

Further, my 'understanding' is that ascii(whatever) is much smarter than
whatever.decode('ascii', ...) does. Also, ascii() tends to use the \x
shorthand, while decode('ascii', 'surrogateescape') uses the \udc prefix.

And, while you might still consider it a 'bug', did you try using c_arg
= arg.decode('iso-88859-1') ?

Michael (F)

>
> I believe that surrogate escape only works for ASCII and nothing else. If so, this test must be skipped on HP-UX and AIX.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34403>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:04:35 2018
From: report at bugs.python.org (Vladimir Matveev)
Date: Mon, 27 Aug 2018 21:04:35 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535403875.98.0.56676864532.issue34200@psf.upfronthosting.co.za>


Vladimir Matveev <desco.by at gmail.com> added the comment:

I've tried to repro this on Mac, Windows box and Windows VM - works fine for all cases.

----------
nosy: +v2m

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:08:07 2018
From: report at bugs.python.org (Philippe Godbout)
Date: Mon, 27 Aug 2018 21:08:07 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1535404087.98.0.56676864532.issue21109@psf.upfronthosting.co.za>


Philippe Godbout <psyker156 at gmail.com> added the comment:

Lars, I think the suggested approach is great. Documentation for the tarfile class should be changed in order to direct user to the "safe" version with an relevant warning. A bit like what is done for PRNG safety.
As stated by Eduardo an optional "safe" parameter to opt into safe mode could also be an interesting approach.

----------
nosy: +Philippe Godbout

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:22:12 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 27 Aug 2018 21:22:12 +0000
Subject: [issue34454] datetime: NULL dereference in fromisoformat() on
 PyUnicode_AsUTF8AndSize() failure
In-Reply-To: <1534887509.78.0.56676864532.issue34454@psf.upfronthosting.co.za>
Message-ID: <1535404932.02.0.56676864532.issue34454@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
pull_requests: +8434

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34454>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:33:58 2018
From: report at bugs.python.org (Steve Dower)
Date: Mon, 27 Aug 2018 21:33:58 +0000
Subject: [issue33635] OSError when using pathlib.Path.rglob() to list device
 files
In-Reply-To: <1527164127.59.0.682650639539.issue33635@psf.upfronthosting.co.za>
Message-ID: <1535405638.55.0.56676864532.issue33635@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 216b745eafa7cd4a683a8405dcfbd7f5567f504c by Steve Dower (Przemys?aw Spodymek) in branch 'master':
bpo-33635: Handling Bad file descriptor in Path.is_file and related. (GH-8542)
https://github.com/python/cpython/commit/216b745eafa7cd4a683a8405dcfbd7f5567f504c


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33635>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:33:58 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 21:33:58 +0000
Subject: [issue33635] OSError when using pathlib.Path.rglob() to list device
 files
In-Reply-To: <1527164127.59.0.682650639539.issue33635@psf.upfronthosting.co.za>
Message-ID: <1535405638.75.0.56676864532.issue33635@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8435

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33635>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:48:40 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 21:48:40 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535406520.52.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think I understand what is happening. The SLES buildbots do not have debugging symbols for glibc:

(gdb) set verbose on
(gdb) break builtin_id
Reading in symbols for Python/bltinmodule.c...done.
Breakpoint 1 at 0x139403c: file Python/bltinmodule.c, line 1182.
(gdb) r
Starting program: /home/linux1/cpython/python tester.py
Reading symbols from /lib/ld64.so.1...(no debugging symbols found)...done.
Reading symbols from system-supplied DSO at 0x3fffdffe000...(no debugging symbols found)...done.
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.22-62.13.2.s390x
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Reading symbols from /lib64/libutil.so.1...(no debugging symbols found)...done.
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.

And when requesting the stacktrace of a thread it cannot go into libc because the program counter is not available:

(gdb) thread apply 2 where

#19 0x0000000001324f02 in method_call (method=<method at remote 0x3fffdeee258>, args=(), kwargs=0x0) at Objects/classobject.c:306
#20 0x0000000001047396 in PyObject_Call (callable=<method at remote 0x3fffdeee258>, args=(), kwargs=0x0) at Objects/call.c:245
#21 0x00000000012b91be in t_bootstrap (boot_raw=0x3fffd9fb118) at ./Modules/_threadmodule.c:992
#22 0x000003fffde88b22 in start_thread () from /lib64/libpthread.so.0
#23 0x000003fffdb7164a in thread_start () from /lib64/libc.so.6
PC not saved

This get triggered when printing the python stack trace with py-bt and the exception is getting printed on stderr and this fails the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Mon Aug 27 17:54:55 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 27 Aug 2018 21:54:55 +0000
Subject: [issue34482] datetime: Tests for potential crashes due to
 non-UTF-8-encodable strings
In-Reply-To: <1535046110.83.0.56676864532.issue34482@psf.upfronthosting.co.za>
Message-ID: <1535406895.79.0.56676864532.issue34482@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Somewhat related: #6697.

Turns out there are already some tests here for this, specifically for the C version only: https://github.com/python/cpython/blob/master/Lib/test/datetimetester.py#L3328

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34482>
_______________________________________

From report at bugs.python.org  Mon Aug 27 18:27:19 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Aug 2018 22:27:19 +0000
Subject: [issue34487] enum _sunder_ names mix metaclass and enum class
 attributes
In-Reply-To: <1535121871.11.0.56676864532.issue34487@psf.upfronthosting.co.za>
Message-ID: <1535408839.79.0.56676864532.issue34487@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

All those attributes live in the Enum class.  If you use a non-existent attribute, such as _name, then the metaclass will be called to check if that name is actually an Enum member.

----------
assignee: docs at python -> ethan.furman
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34487>
_______________________________________

From report at bugs.python.org  Mon Aug 27 18:37:22 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Aug 2018 22:37:22 +0000
Subject: [issue33635] OSError when using pathlib.Path.rglob() to list device
 files
In-Reply-To: <1527164127.59.0.682650639539.issue33635@psf.upfronthosting.co.za>
Message-ID: <1535409442.36.0.56676864532.issue33635@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2cf33161f7cb4ca726c74fcfa2d6db27073953d8 by Miss Islington (bot) in branch '3.7':
bpo-33635: Handling Bad file descriptor in Path.is_file and related. (GH-8542)
https://github.com/python/cpython/commit/2cf33161f7cb4ca726c74fcfa2d6db27073953d8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33635>
_______________________________________

From report at bugs.python.org  Mon Aug 27 19:03:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 23:03:41 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535411021.78.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I need to do some more experimenting because those symbols are not available on other systems with the test passing. Something is corrupting/not saving the program counter but I do not know what.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Mon Aug 27 19:08:56 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Aug 2018 23:08:56 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535411336.3.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Walking the stack up one by one only triggers the "PC not saved" when the stack goes into libc:

(gdb) break builtin_id
Breakpoint 1 at 0x139403c: file Python/bltinmodule.c, line 1182.
(gdb) r
Starting program: /home/linux1/cpython/python tester.py
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.22-62.13.2.s390x
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x3fffd2ff910 (LWP 9951)]
[New Thread 0x3fffcaff910 (LWP 9952)]
[New Thread 0x3fff7fff910 (LWP 9953)]
[New Thread 0x3fff77ff910 (LWP 9954)]

Thread 1 "python" hit Breakpoint 1, builtin_id (self=0x3fffdf5c0c8, v=0x14f7690 <small_ints+2256>) at Python/bltinmodule.c:1182
1182        return PyLong_FromVoidPtr(v);
(gdb) thread 2
[Switching to thread 2 (Thread 0x3fffd2ff910 (LWP 9951))]
#0  0x000003fffde8da0a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
(gdb) up
#1  0x0000000001186a2e in PyCOND_TIMEDWAIT (cond=0x15139b0 <_PyRuntime+1192>, mut=0x15139e0 <_PyRuntime+1240>, us=5000) at Python/condvar.h:90
90          r = pthread_cond_timedwait((cond), (mut), &ts);
(gdb)
#2  0x0000000001186f3a in take_gil (tstate=0x1538620) at Python/ceval_gil.h:208
208             COND_TIMED_WAIT(_PyRuntime.ceval.gil.cond, _PyRuntime.ceval.gil.mutex,
(gdb)
#3  0x00000000011884a6 in _PyEval_EvalFrameDefault (f=0x3fffd844d00, throwflag=0) at Python/ceval.c:980
980                     take_gil(tstate);
(gdb)
#4  0x0000000001187db8 in PyEval_EvalFrameEx (f=0x3fffd844d00, throwflag=0) at Python/ceval.c:536
536         return interp->eval_frame(f, throwflag);
(gdb)
#5  0x0000000001047596 in function_code_fastcall (co=0x3fffdd76640, args=0x3fff8000a98, nargs=1, globals=0x3fffddcff30) at Objects/call.c:283
283         result = PyEval_EvalFrameEx(f,0);
(gdb)
#6  0x0000000001048144 in _PyFunction_FastCallKeywords (func=0x3fffd7d8680, stack=0x3fff8000a90, nargs=1, kwnames=0x0) at Objects/call.c:408
408                 return function_code_fastcall(co, stack, nargs, globals);
(gdb)
#7  0x00000000011a48b6 in call_function (pp_stack=0x3fffd2fb5f8, oparg=1, kwnames=0x0) at Python/ceval.c:4623
4623                x = _PyFunction_FastCallKeywords(func, stack, nargs, kwnames);
(gdb)
#8  0x000000000119c088 in _PyEval_EvalFrameDefault (f=0x3fff80008f0, throwflag=0) at Python/ceval.c:3186
3186                    res = call_function(&sp, oparg + 1, NULL);
(gdb)
#9  0x0000000001187db8 in PyEval_EvalFrameEx (f=0x3fff80008f0, throwflag=0) at Python/ceval.c:536
536         return interp->eval_frame(f, throwflag);
(gdb)
#10 0x0000000001047596 in function_code_fastcall (co=0x3fffda6e580, args=0x3fffd87e980, nargs=1, globals=0x3fffdd717c0) at Objects/call.c:283
283         result = PyEval_EvalFrameEx(f,0);
(gdb)
#11 0x0000000001048144 in _PyFunction_FastCallKeywords (func=0x3fffd7d61b0, stack=0x3fffd87e978, nargs=1, kwnames=0x0) at Objects/call.c:408
408                 return function_code_fastcall(co, stack, nargs, globals);
(gdb)
#12 0x00000000011a48b6 in call_function (pp_stack=0x3fffd2fd1b8, oparg=1, kwnames=0x0) at Python/ceval.c:4623
4623                x = _PyFunction_FastCallKeywords(func, stack, nargs, kwnames);
(gdb)
#13 0x000000000119c088 in _PyEval_EvalFrameDefault (f=0x3fffd87e7f0, throwflag=0) at Python/ceval.c:3186
3186                    res = call_function(&sp, oparg + 1, NULL);
(gdb)
#14 0x0000000001187db8 in PyEval_EvalFrameEx (f=0x3fffd87e7f0, throwflag=0) at Python/ceval.c:536
536         return interp->eval_frame(f, throwflag);
(gdb)
#15 0x0000000001047596 in function_code_fastcall (co=0x3fffda6e340, args=0x3fffd2fed28, nargs=1, globals=0x3fffdd717c0) at Objects/call.c:283
283         result = PyEval_EvalFrameEx(f,0);
(gdb)
#16 0x0000000001047a2e in _PyFunction_FastCallDict (func=0x3fffd7d3f70, args=0x3fffd2fed20, nargs=1, kwargs=0x0) at Objects/call.c:322
322                 return function_code_fastcall(co, args, nargs, globals);
(gdb)
#17 0x00000000010467d6 in _PyObject_FastCallDict (callable=0x3fffd7d3f70, args=0x3fffd2fed20, nargs=1, kwargs=0x0) at Objects/call.c:98
98              return _PyFunction_FastCallDict(callable, args, nargs, kwargs);
(gdb)
#18 0x0000000001049c5c in _PyObject_Call_Prepend (callable=0x3fffd7d3f70, obj=0x3fffdc70650, args=0x3fffdfb9050, kwargs=0x0)
    at Objects/call.c:904
904         result = _PyObject_FastCallDict(callable,
(gdb)
#19 0x0000000001324f02 in method_call (method=0x3fffdeee258, args=0x3fffdfb9050, kwargs=0x0) at Objects/classobject.c:306
306         return _PyObject_Call_Prepend(func, self, args, kwargs);
(gdb)
#20 0x0000000001047396 in PyObject_Call (callable=0x3fffdeee258, args=0x3fffdfb9050, kwargs=0x0) at Objects/call.c:245
245             result = (*call)(callable, args, kwargs);
(gdb)
#21 0x00000000012b91be in t_bootstrap (boot_raw=0x3fffd9fb118) at ./Modules/_threadmodule.c:992
992         res = PyObject_Call(boot->func, boot->args, boot->keyw);
(gdb)
#22 0x000003fffde88b22 in start_thread () from /lib64/libpthread.so.0
(gdb)
#23 0x000003fffdb7164a in thread_start () from /lib64/libc.so.6
(gdb)
PC not saved

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Mon Aug 27 19:44:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Aug 2018 23:44:03 +0000
Subject: [issue34523] Choose the filesystem encoding earlier in Python
 initialization (add _PyCoreConfig.filesystem_encoding)
Message-ID: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Currently, the Python filesystem encoding is get in the middle of the Python initialization. initfsencoding() is only called when the import machinery is ready. Technically, only getting the Python codec name requires a working import machinery.

We can get the locale encoding even before Py_Initialize(), but update the encoding to the Python codec name (ex: replace "ANSI_X3.4-1968" with "ascii") once the import machinery is ready.

With my change, for an application embedding Python, the filesystem encoding can now be forced using _PyCoreConfig.filesystem_encoding. If it's set, Python will use it (and ignore the locale encoding).

Attached PR implements this idea and adds _PyCoreConfig.filesystem_encoding.


The change move all code to select encoding and error handler inside config_init_fs_encoding(), rather than relying on Py_FileSystemDefaultEncoding constant (its default value is set using #ifdef) and initfsencoding() (to get the locale encoding at runtime).


With this change, it becomes more obvious than the interpreter core configuration is mutable. initfsencoding() modify the encoding/errors during Python initialization, and sys._enablelegacywindowsfsencoding() even modify it at runtime. Previously, I wanted to expose the full core_config at the Python level, as something like sys.flags. But since it's mutable, I'm not longer sure that it's a good idea. To *get* the filesystem encoding/errors, they are already sys.getfilesystemencoding() and sys.getfilesystemencodeerrors(). Modifying the filesystem encoding at runtime is a very bad idea tried in the past and it caused many issues.


For the long term, I would like to remove Py_HasFileSystemDefaultEncoding, since it's really an implementation detail and there is no need to expose it. More generally, I don't see the purpose of exposing directly the encoding and error handler at the C level: Py_FileSystemDefaultEncoding and Py_FileSystemDefaultEncodeErrors. These symbols are constant constant, they cannot be modified when Python is embedded. But well, it's just a remark, technically, these 3 symbols don't cause any kind of trouble.


Commit message:
---
bpo-34485: Add _PyCoreConfig.filesystem_encoding

_PyCoreConfig_Read() is now responsible to choose the filesystem
encoding and error handler. Using Py_Main(), the encoding is now
selected even before calling Py_Initialize().

_PyCoreConfig.filesystem_encoding is now the reference instead of
Py_FileSystemDefaultEncoding for the Python filesystem encoding.

Changes:

* Add filesystem_encoding and filesystem_errors to _PyCoreConfig
* _PyCoreConfig_Read() now reads the locale encoding for the file
  system encoding. Coerce temporarly the locale or set temporarly the
  LC_CTYPE locale to the user preferred locale.
* PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()
  now use the interpreter configuration rather than
  Py_FileSystemDefaultEncoding and Py_FileSystemDefaultEncodeErrors
  global configuration variables.
* Add _Py_SetFileSystemEncoding() and _Py_ClearFileSystemEncoding()
  private functions to only modify Py_FileSystemDefaultEncoding and
  Py_FileSystemDefaultEncodeErrors in coreconfig.c.
---

----------
components: Interpreter Core
messages: 324206
nosy: eric.snow, inada.naoki, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: Choose the filesystem encoding earlier in Python initialization (add _PyCoreConfig.filesystem_encoding)
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Mon Aug 27 20:12:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 00:12:53 +0000
Subject: [issue34523] Choose the filesystem encoding earlier in Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535415173.97.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8436
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Mon Aug 27 20:13:07 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 00:13:07 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535415187.64.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: Choose the filesystem encoding earlier in Python initialization (add _PyCoreConfig.filesystem_encoding) -> Choose the filesystem encoding before Python initialization (add _PyCoreConfig.filesystem_encoding)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Mon Aug 27 20:35:58 2018
From: report at bugs.python.org (Richard Evans)
Date: Tue, 28 Aug 2018 00:35:58 +0000
Subject: [issue34524] Format conversion documentation example don't match
 comment
Message-ID: <1535416558.65.0.56676864532.issue34524@psf.upfronthosting.co.za>


New submission from Richard Evans <rarevans at hotmail.com>:

When reading the documentation for string formats I found that the conversion examples had comments that didn't match the example.

----------
assignee: docs at python
components: Documentation
messages: 324207
nosy: Richard Evans, docs at python
priority: normal
severity: normal
status: open
title: Format conversion documentation example don't match comment
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34524>
_______________________________________

From report at bugs.python.org  Mon Aug 27 20:37:31 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Aug 2018 00:37:31 +0000
Subject: [issue34524] Format conversion documentation example don't match
 comment
In-Reply-To: <1535416558.65.0.56676864532.issue34524@psf.upfronthosting.co.za>
Message-ID: <1535416650.98.0.56676864532.issue34524@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Can you be more specific?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34524>
_______________________________________

From report at bugs.python.org  Mon Aug 27 20:44:53 2018
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 28 Aug 2018 00:44:53 +0000
Subject: [issue34524] Format conversion documentation example don't match
 comment
In-Reply-To: <1535416558.65.0.56676864532.issue34524@psf.upfronthosting.co.za>
Message-ID: <1535417093.38.0.56676864532.issue34524@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8437
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34524>
_______________________________________

From report at bugs.python.org  Mon Aug 27 21:09:10 2018
From: report at bugs.python.org (Richard Evans)
Date: Tue, 28 Aug 2018 01:09:10 +0000
Subject: [issue34524] Format conversion documentation example don't match
 comment
In-Reply-To: <1535416558.65.0.56676864532.issue34524@psf.upfronthosting.co.za>
Message-ID: <1535418550.14.0.56676864532.issue34524@psf.upfronthosting.co.za>


Change by Richard Evans <rarevans at hotmail.com>:


----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34524>
_______________________________________

From report at bugs.python.org  Mon Aug 27 22:10:42 2018
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 28 Aug 2018 02:10:42 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
Message-ID: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at rittau.biz>:

smtplib's authobject() callback is supposed to return bytes, according to both the documentation at https://docs.python.org/3/library/smtplib.html as well as the docstring of SMTP.auth(). This does neither match the implementation of auth(), which immediately calls encode() on the return value, nor that of the auth_cram_md5() et al, which return str.

----------
assignee: docs at python
components: Documentation
messages: 324209
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: smtplib's authobject return value wrongly documented
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Aug 27 22:15:52 2018
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 28 Aug 2018 02:15:52 +0000
Subject: [issue34525] smtplib's authobject return value wrongly documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1535422552.53.0.56676864532.issue34525@psf.upfronthosting.co.za>


Change by Sebastian Rittau <srittau at rittau.biz>:


----------
keywords: +patch
pull_requests: +8438
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34525>
_______________________________________

From report at bugs.python.org  Mon Aug 27 22:18:14 2018
From: report at bugs.python.org (chen wu)
Date: Tue, 28 Aug 2018 02:18:14 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1535422694.29.0.56676864532.issue34516@psf.upfronthosting.co.za>


chen wu <wuchen12 at huawei.com> added the comment:

Thanks so much for your reply. 

when httplib.HTTPConnection is inited with host [fc00::0a08::2] and port 35357, we can make a request normally. only the 'Host' set in header is wrong. I think the most simple way to fix this is adding judgement condition, maybe like this:
974                    # Wrap the IPv6 Host Header with [] (RFC 2732)
975                    if host_enc.find(':') >= 0 and host_enc.find(']') < 0:
976                        host_enc = "[" + host_enc + "]"

or rules should be given, because when port is not default, only (host=[aaa:bbb]:123, port=None) and (host=aaa:bbb, port=123) are valid for httplib now.

so sorry for my poor English. hope you can understand what im saying. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Tue Aug 28 01:42:43 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 28 Aug 2018 05:42:43 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
 path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1535434963.19.0.56676864532.issue17102@psf.upfronthosting.co.za>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> tarfile: Traversal attack vulnerability

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17102>
_______________________________________

From report at bugs.python.org  Tue Aug 28 02:52:56 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 06:52:56 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535439176.57.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Wow, this is pretty surprising. The very same patch for AIX works on HP-UX flawlessly:

$ ./python -m test test_utf8_mode
Run tests sequentially
0:00:00 [1/1] test_utf8_mode

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2 sec 769 ms
Tests result: SUCCESS


I still don't really understand why because decode() and ascii() are comparing apples and oranges to me.

Michael, since you provided a decent solution would you mind to extend your patch for HP-UX? You deserve the credits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:12:00 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Aug 2018 07:12:00 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1535440320.01.0.56676864532.issue21145@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset d658deac6060ee92b449a3bf424b460eafd99f3e by Nick Coghlan (Carl Meyer) in branch 'master':
bpo-21145: Add cached_property decorator in functools (#6982)
https://github.com/python/cpython/commit/d658deac6060ee92b449a3bf424b460eafd99f3e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:18:21 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 07:18:21 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535440701.06.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Now I know why this cannot with Roman 8: it contains chars which are multibyte in Unicode (UTF-8) which cannot be mapped into a 7-bit/8-bit encoding. Therefore CP1252 does not work because it has Unicode chars too. ISO-8859-1 solely consists of single byte chars.

This test needs to be skipped on HP-UX. I will provide a patch for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:34:04 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 07:34:04 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535441644.87.0.56676864532.issue34403@psf.upfronthosting.co.za>


Change by Michael Osipov <1983-01-06 at gmx.net>:


----------
keywords: +patch
pull_requests: +8440
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:37:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 07:37:43 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535441863.89.0.56676864532.issue34403@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8441

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:40:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 07:40:22 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535442022.3.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Hi, I'm the author of the UTF-8 Mode PEP (PEP 540) and its implementation. I wrote test_utf8_mode. I wasn't sure that it was a good idea to hardcode the locale encoding depending on the platform. The fact that AIX and HP-UX use different locale encoding confirms that it was a bad choice. My PR 8967 gets the locale encoding at runtime instead of hardcoding it. It should fix the test on AIX and HP-UX.

To fix the test on HP-UX, I also removed the euro sign (U+20AC: ?) from the test string. There is no need to test large code point: a single non-ASCII character is enough to validate the code.

Michael Osipov: would you mind to test my PR on HP-UX please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:42:32 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 07:42:32 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535442152.78.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Victor, looking to...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:49:02 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 07:49:02 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535442542.92.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

It unfortunately does not:
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ git branch
>   3.6
>   3.7
>   bpo-14568
>   bpo-34401
>   bpo-34403
>   bpo-34412
>   bpo-34448
>   bpo-34449
>   bpo-34519
>   master
>   test_c_locale_coercion_hpux
> * utf8_cmd_line
> $ ./python -m test test_utf8_mode
> Run tests sequentially
> 0:00:00 [1/1] test_utf8_mode
> test test_utf8_mode failed -- Traceback (most recent call last):
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 231, in test_cmd_line
>     check('utf8=0', [c_arg], LC_ALL='C')
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 218, in check
>     self.assertEqual(args, ascii(expected), out)
> AssertionError: "['h\\xc2\\xa7\\xc3\\xa9']" != "['h\\xf4\\xcf\\xfb\\u02cb']"
> - ['h\xc2\xa7\xc3\xa9']
> + ['h\xf4\xcf\xfb\u02cb']
>  : roman8:['h\xc2\xa7\xc3\xa9']
> 
> test_utf8_mode failed
> 
> == Tests result: FAILURE ==
> 
> 1 test failed:
>     test_utf8_mode
> 
> Total duration: 2 sec 921 ms
> Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:53:57 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 07:53:57 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535442837.9.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Running off: 217af1d38db3e1e875180c6fa160f0fc80e46003

> $ ./python -m test test_utf8_mode
> Run tests sequentially
> 0:00:00 [1/1] test_utf8_mode
> test test_utf8_mode failed -- Traceback (most recent call last):
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 235, in test_cmd_line
>     LC_ALL='C')
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 214, in check
>     self.assertEqual(args, ascii(expected), out)
> AssertionError: "['h\\xa7\\xe9']" != "['h\\xcf\\xd5']"
> - ['h\xa7\xe9']
> + ['h\xcf\xd5']
>  : roman8:['h\xa7\xe9']
> 
> test_utf8_mode failed
> 
> == Tests result: FAILURE ==
> 
> 1 test failed:
>     test_utf8_mode
> 
> Total duration: 2 sec 997 ms
> Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 03:58:50 2018
From: report at bugs.python.org (Carlos Velasco)
Date: Tue, 28 Aug 2018 07:58:50 +0000
Subject: [issue34032] Add platlibdir to allow distinction between /usr/lib and
 /usr/lib64 for Linux
In-Reply-To: <1530630040.09.0.56676864532.issue34032@psf.upfronthosting.co.za>
Message-ID: <1535443130.55.0.56676864532.issue34032@psf.upfronthosting.co.za>


Carlos Velasco <carlos.velasco at nimastelecom.com> added the comment:

This updated patch fix two missing lib/lib64
It works for me.

# python3-32 -c "import sys; print('\n'.join(sys.path))"
/usr/lib/python37.zip
/usr/lib/python3.7
/usr/lib/python3.7/lib-dynload
/root/.local/lib/python3.7/site-packages
/usr/lib/python3.7/site-packages


# python3-64 -c "import sys; print('\n'.join(sys.path))"  
/usr/lib64/python37.zip
/usr/lib64/python3.7
/usr/lib64/python3.7/lib-dynload
/root/.local/lib64/python3.7/site-packages
/usr/lib64/python3.7/site-packages

----------
nosy: +carlos.velasco
Added file: https://bugs.python.org/file47766/python-3.6.0-multilib-new-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34032>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:11:02 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 08:11:02 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535443862.67.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 214, in check
>     self.assertEqual(args, ascii(expected), out)
> AssertionError: "['h\\xa7\\xe9']" != "['h\\xcf\\xd5']"
> - ['h\xa7\xe9']
> + ['h\xcf\xd5']
>  : roman8:['h\xa7\xe9']

Hum, it looks like a bug in the C library of HP-UX. It announces that the locale encoding is "roman8", but the mbstowcs() function decodes from the Latin1 encoding. The updated test uses the byte string: b'h\xa7\xe9'. The OS announces the encoding roman8, so the test expects the Unicode string: b'h\xa7\xe9'.decode('roman8') == 'h\xcf\xd5'.... but it gets 'h\xa7\xe9' which looks more like the byte string has been decoded from Latin1: b'h\xa7\xe9'.decode('latin1') == 'h\xa7\xe9'.

Michael: would you mind to compile and run the attached c_locale.c test program? It sets the LC_ALL locale to C, dump locales (LC_ALL, LC_CTYPE, nl_langinfo(CODESET)), and then decode all bytes from the locale encoding (LC_CTYPE). The output should help me to understand what is the *effective* encoding of HP-UX for the C locale.

You may modify the c_locale.c to replace "C" with "POSIX", to see if the behaviour is different.

----------
Added file: https://bugs.python.org/file47767/c_locale.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:15:15 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Aug 2018 08:15:15 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1535444115.88.0.56676864532.issue34516@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

urrlib3 seems to handle this case at https://github.com/urllib3/urllib3/blob/c41fa8c7ed8cb7315195dc15e67958754ea276d5/src/urllib3/util/url.py#L184 . 

Test cases : https://github.com/urllib3/urllib3/blob/0f85e05af9ef2ded671a7b47506dfd24b32decf0/test/test_util.py#L80

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:20:21 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 08:20:21 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535444421.91.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Please see here:
> osipovmi at blnn724x:~ []
> $ uname -a
> HP-UX blnn724x B.11.31 U ia64 HP-UX
> osipovmi at blnn724x:~ []
> $ locale
> LANG=de_DE.utf8
> LC_CTYPE="de_DE.utf8"
> LC_COLLATE="de_DE.utf8"
> LC_MONETARY="de_DE.utf8"
> LC_NUMERIC="de_DE.utf8"
> LC_TIME="de_DE.utf8"
> LC_MESSAGES="de_DE.utf8"
> LC_ALL=
> osipovmi at blnn724x:~ []
> $ cc -o c_locale c_locale.c
> osipovmi at blnn724x:~ []
> $ file c_locale
> c_locale:       ELF-32 executable object file - IA64
> osipovmi at blnn724x:~ []
> $ ./c_locale
> LC_ALL: C C C C C C
> LC_CTYPE: C C C C C C
> nl_langinfo(CODESET): roman8
> byte 0x00 decoded to Unicode character U+0000
> byte 0x01 decoded to Unicode character U+0001
> byte 0x02 decoded to Unicode character U+0002
> byte 0x03 decoded to Unicode character U+0003
> byte 0x04 decoded to Unicode character U+0004
> byte 0x05 decoded to Unicode character U+0005
> byte 0x06 decoded to Unicode character U+0006
> byte 0x07 decoded to Unicode character U+0007
> byte 0x08 decoded to Unicode character U+0008
> byte 0x09 decoded to Unicode character U+0009
> byte 0x0A decoded to Unicode character U+000A
> byte 0x0B decoded to Unicode character U+000B
> byte 0x0C decoded to Unicode character U+000C
> byte 0x0D decoded to Unicode character U+000D
> byte 0x0E decoded to Unicode character U+000E
> byte 0x0F decoded to Unicode character U+000F
> byte 0x10 decoded to Unicode character U+0010
> byte 0x11 decoded to Unicode character U+0011
> byte 0x12 decoded to Unicode character U+0012
> byte 0x13 decoded to Unicode character U+0013
> byte 0x14 decoded to Unicode character U+0014
> byte 0x15 decoded to Unicode character U+0015
> byte 0x16 decoded to Unicode character U+0016
> byte 0x17 decoded to Unicode character U+0017
> byte 0x18 decoded to Unicode character U+0018
> byte 0x19 decoded to Unicode character U+0019
> byte 0x1A decoded to Unicode character U+001A
> byte 0x1B decoded to Unicode character U+001B
> byte 0x1C decoded to Unicode character U+001C
> byte 0x1D decoded to Unicode character U+001D
> byte 0x1E decoded to Unicode character U+001E
> byte 0x1F decoded to Unicode character U+001F
> byte 0x20 decoded to Unicode character U+0020
> byte 0x21 decoded to Unicode character U+0021
> byte 0x22 decoded to Unicode character U+0022
> byte 0x23 decoded to Unicode character U+0023
> byte 0x24 decoded to Unicode character U+0024
> byte 0x25 decoded to Unicode character U+0025
> byte 0x26 decoded to Unicode character U+0026
> byte 0x27 decoded to Unicode character U+0027
> byte 0x28 decoded to Unicode character U+0028
> byte 0x29 decoded to Unicode character U+0029
> byte 0x2A decoded to Unicode character U+002A
> byte 0x2B decoded to Unicode character U+002B
> byte 0x2C decoded to Unicode character U+002C
> byte 0x2D decoded to Unicode character U+002D
> byte 0x2E decoded to Unicode character U+002E
> byte 0x2F decoded to Unicode character U+002F
> byte 0x30 decoded to Unicode character U+0030
> byte 0x31 decoded to Unicode character U+0031
> byte 0x32 decoded to Unicode character U+0032
> byte 0x33 decoded to Unicode character U+0033
> byte 0x34 decoded to Unicode character U+0034
> byte 0x35 decoded to Unicode character U+0035
> byte 0x36 decoded to Unicode character U+0036
> byte 0x37 decoded to Unicode character U+0037
> byte 0x38 decoded to Unicode character U+0038
> byte 0x39 decoded to Unicode character U+0039
> byte 0x3A decoded to Unicode character U+003A
> byte 0x3B decoded to Unicode character U+003B
> byte 0x3C decoded to Unicode character U+003C
> byte 0x3D decoded to Unicode character U+003D
> byte 0x3E decoded to Unicode character U+003E
> byte 0x3F decoded to Unicode character U+003F
> byte 0x40 decoded to Unicode character U+0040
> byte 0x41 decoded to Unicode character U+0041
> byte 0x42 decoded to Unicode character U+0042
> byte 0x43 decoded to Unicode character U+0043
> byte 0x44 decoded to Unicode character U+0044
> byte 0x45 decoded to Unicode character U+0045
> byte 0x46 decoded to Unicode character U+0046
> byte 0x47 decoded to Unicode character U+0047
> byte 0x48 decoded to Unicode character U+0048
> byte 0x49 decoded to Unicode character U+0049
> byte 0x4A decoded to Unicode character U+004A
> byte 0x4B decoded to Unicode character U+004B
> byte 0x4C decoded to Unicode character U+004C
> byte 0x4D decoded to Unicode character U+004D
> byte 0x4E decoded to Unicode character U+004E
> byte 0x4F decoded to Unicode character U+004F
> byte 0x50 decoded to Unicode character U+0050
> byte 0x51 decoded to Unicode character U+0051
> byte 0x52 decoded to Unicode character U+0052
> byte 0x53 decoded to Unicode character U+0053
> byte 0x54 decoded to Unicode character U+0054
> byte 0x55 decoded to Unicode character U+0055
> byte 0x56 decoded to Unicode character U+0056
> byte 0x57 decoded to Unicode character U+0057
> byte 0x58 decoded to Unicode character U+0058
> byte 0x59 decoded to Unicode character U+0059
> byte 0x5A decoded to Unicode character U+005A
> byte 0x5B decoded to Unicode character U+005B
> byte 0x5C decoded to Unicode character U+005C
> byte 0x5D decoded to Unicode character U+005D
> byte 0x5E decoded to Unicode character U+005E
> byte 0x5F decoded to Unicode character U+005F
> byte 0x60 decoded to Unicode character U+0060
> byte 0x61 decoded to Unicode character U+0061
> byte 0x62 decoded to Unicode character U+0062
> byte 0x63 decoded to Unicode character U+0063
> byte 0x64 decoded to Unicode character U+0064
> byte 0x65 decoded to Unicode character U+0065
> byte 0x66 decoded to Unicode character U+0066
> byte 0x67 decoded to Unicode character U+0067
> byte 0x68 decoded to Unicode character U+0068
> byte 0x69 decoded to Unicode character U+0069
> byte 0x6A decoded to Unicode character U+006A
> byte 0x6B decoded to Unicode character U+006B
> byte 0x6C decoded to Unicode character U+006C
> byte 0x6D decoded to Unicode character U+006D
> byte 0x6E decoded to Unicode character U+006E
> byte 0x6F decoded to Unicode character U+006F
> byte 0x70 decoded to Unicode character U+0070
> byte 0x71 decoded to Unicode character U+0071
> byte 0x72 decoded to Unicode character U+0072
> byte 0x73 decoded to Unicode character U+0073
> byte 0x74 decoded to Unicode character U+0074
> byte 0x75 decoded to Unicode character U+0075
> byte 0x76 decoded to Unicode character U+0076
> byte 0x77 decoded to Unicode character U+0077
> byte 0x78 decoded to Unicode character U+0078
> byte 0x79 decoded to Unicode character U+0079
> byte 0x7A decoded to Unicode character U+007A
> byte 0x7B decoded to Unicode character U+007B
> byte 0x7C decoded to Unicode character U+007C
> byte 0x7D decoded to Unicode character U+007D
> byte 0x7E decoded to Unicode character U+007E
> byte 0x7F decoded to Unicode character U+007F
> byte 0x80 decoded to Unicode character U+0080
> byte 0x81 decoded to Unicode character U+0081
> byte 0x82 decoded to Unicode character U+0082
> byte 0x83 decoded to Unicode character U+0083
> byte 0x84 decoded to Unicode character U+0084
> byte 0x85 decoded to Unicode character U+0085
> byte 0x86 decoded to Unicode character U+0086
> byte 0x87 decoded to Unicode character U+0087
> byte 0x88 decoded to Unicode character U+0088
> byte 0x89 decoded to Unicode character U+0089
> byte 0x8A decoded to Unicode character U+008A
> byte 0x8B decoded to Unicode character U+008B
> byte 0x8C decoded to Unicode character U+008C
> byte 0x8D decoded to Unicode character U+008D
> byte 0x8E decoded to Unicode character U+008E
> byte 0x8F decoded to Unicode character U+008F
> byte 0x90 decoded to Unicode character U+0090
> byte 0x91 decoded to Unicode character U+0091
> byte 0x92 decoded to Unicode character U+0092
> byte 0x93 decoded to Unicode character U+0093
> byte 0x94 decoded to Unicode character U+0094
> byte 0x95 decoded to Unicode character U+0095
> byte 0x96 decoded to Unicode character U+0096
> byte 0x97 decoded to Unicode character U+0097
> byte 0x98 decoded to Unicode character U+0098
> byte 0x99 decoded to Unicode character U+0099
> byte 0x9A decoded to Unicode character U+009A
> byte 0x9B decoded to Unicode character U+009B
> byte 0x9C decoded to Unicode character U+009C
> byte 0x9D decoded to Unicode character U+009D
> byte 0x9E decoded to Unicode character U+009E
> byte 0x9F decoded to Unicode character U+009F
> byte 0xA0 decoded to Unicode character U+00A0
> byte 0xA1 decoded to Unicode character U+00A1
> byte 0xA2 decoded to Unicode character U+00A2
> byte 0xA3 decoded to Unicode character U+00A3
> byte 0xA4 decoded to Unicode character U+00A4
> byte 0xA5 decoded to Unicode character U+00A5
> byte 0xA6 decoded to Unicode character U+00A6
> byte 0xA7 decoded to Unicode character U+00A7
> byte 0xA8 decoded to Unicode character U+00A8
> byte 0xA9 decoded to Unicode character U+00A9
> byte 0xAA decoded to Unicode character U+00AA
> byte 0xAB decoded to Unicode character U+00AB
> byte 0xAC decoded to Unicode character U+00AC
> byte 0xAD decoded to Unicode character U+00AD
> byte 0xAE decoded to Unicode character U+00AE
> byte 0xAF decoded to Unicode character U+00AF
> byte 0xB0 decoded to Unicode character U+00B0
> byte 0xB1 decoded to Unicode character U+00B1
> byte 0xB2 decoded to Unicode character U+00B2
> byte 0xB3 decoded to Unicode character U+00B3
> byte 0xB4 decoded to Unicode character U+00B4
> byte 0xB5 decoded to Unicode character U+00B5
> byte 0xB6 decoded to Unicode character U+00B6
> byte 0xB7 decoded to Unicode character U+00B7
> byte 0xB8 decoded to Unicode character U+00B8
> byte 0xB9 decoded to Unicode character U+00B9
> byte 0xBA decoded to Unicode character U+00BA
> byte 0xBB decoded to Unicode character U+00BB
> byte 0xBC decoded to Unicode character U+00BC
> byte 0xBD decoded to Unicode character U+00BD
> byte 0xBE decoded to Unicode character U+00BE
> byte 0xBF decoded to Unicode character U+00BF
> byte 0xC0 decoded to Unicode character U+00C0
> byte 0xC1 decoded to Unicode character U+00C1
> byte 0xC2 decoded to Unicode character U+00C2
> byte 0xC3 decoded to Unicode character U+00C3
> byte 0xC4 decoded to Unicode character U+00C4
> byte 0xC5 decoded to Unicode character U+00C5
> byte 0xC6 decoded to Unicode character U+00C6
> byte 0xC7 decoded to Unicode character U+00C7
> byte 0xC8 decoded to Unicode character U+00C8
> byte 0xC9 decoded to Unicode character U+00C9
> byte 0xCA decoded to Unicode character U+00CA
> byte 0xCB decoded to Unicode character U+00CB
> byte 0xCC decoded to Unicode character U+00CC
> byte 0xCD decoded to Unicode character U+00CD
> byte 0xCE decoded to Unicode character U+00CE
> byte 0xCF decoded to Unicode character U+00CF
> byte 0xD0 decoded to Unicode character U+00D0
> byte 0xD1 decoded to Unicode character U+00D1
> byte 0xD2 decoded to Unicode character U+00D2
> byte 0xD3 decoded to Unicode character U+00D3
> byte 0xD4 decoded to Unicode character U+00D4
> byte 0xD5 decoded to Unicode character U+00D5
> byte 0xD6 decoded to Unicode character U+00D6
> byte 0xD7 decoded to Unicode character U+00D7
> byte 0xD8 decoded to Unicode character U+00D8
> byte 0xD9 decoded to Unicode character U+00D9
> byte 0xDA decoded to Unicode character U+00DA
> byte 0xDB decoded to Unicode character U+00DB
> byte 0xDC decoded to Unicode character U+00DC
> byte 0xDD decoded to Unicode character U+00DD
> byte 0xDE decoded to Unicode character U+00DE
> byte 0xDF decoded to Unicode character U+00DF
> byte 0xE0 decoded to Unicode character U+00E0
> byte 0xE1 decoded to Unicode character U+00E1
> byte 0xE2 decoded to Unicode character U+00E2
> byte 0xE3 decoded to Unicode character U+00E3
> byte 0xE4 decoded to Unicode character U+00E4
> byte 0xE5 decoded to Unicode character U+00E5
> byte 0xE6 decoded to Unicode character U+00E6
> byte 0xE7 decoded to Unicode character U+00E7
> byte 0xE8 decoded to Unicode character U+00E8
> byte 0xE9 decoded to Unicode character U+00E9
> byte 0xEA decoded to Unicode character U+00EA
> byte 0xEB decoded to Unicode character U+00EB
> byte 0xEC decoded to Unicode character U+00EC
> byte 0xED decoded to Unicode character U+00ED
> byte 0xEE decoded to Unicode character U+00EE
> byte 0xEF decoded to Unicode character U+00EF
> byte 0xF0 decoded to Unicode character U+00F0
> byte 0xF1 decoded to Unicode character U+00F1
> byte 0xF2 decoded to Unicode character U+00F2
> byte 0xF3 decoded to Unicode character U+00F3
> byte 0xF4 decoded to Unicode character U+00F4
> byte 0xF5 decoded to Unicode character U+00F5
> byte 0xF6 decoded to Unicode character U+00F6
> byte 0xF7 decoded to Unicode character U+00F7
> byte 0xF8 decoded to Unicode character U+00F8
> byte 0xF9 decoded to Unicode character U+00F9
> byte 0xFA decoded to Unicode character U+00FA
> byte 0xFB decoded to Unicode character U+00FB
> byte 0xFC decoded to Unicode character U+00FC
> byte 0xFD decoded to Unicode character U+00FD
> byte 0xFE decoded to Unicode character U+00FE
> $ vim c_locale.c
> ...
> "c_locale.c" 26L, 747C geschrieben
> osipovmi at blnn724x:~ []
> $ cc -o c_locale c_locale.c
> osipovmi at blnn724x:~ []
> $ file c_locale
> c_locale:       ELF-32 executable object file - IA64
> osipovmi at blnn724x:~ []
> $ ./c_locale
> LC_ALL: POSIX POSIX POSIX POSIX POSIX POSIX
> LC_CTYPE: POSIX POSIX POSIX POSIX POSIX POSIX
> nl_langinfo(CODESET): roman8
> byte 0x00 decoded to Unicode character U+0000
> byte 0x01 decoded to Unicode character U+0001
> byte 0x02 decoded to Unicode character U+0002
> byte 0x03 decoded to Unicode character U+0003
> byte 0x04 decoded to Unicode character U+0004
> byte 0x05 decoded to Unicode character U+0005
> byte 0x06 decoded to Unicode character U+0006
> byte 0x07 decoded to Unicode character U+0007
> byte 0x08 decoded to Unicode character U+0008
> byte 0x09 decoded to Unicode character U+0009
> byte 0x0A decoded to Unicode character U+000A
> byte 0x0B decoded to Unicode character U+000B
> byte 0x0C decoded to Unicode character U+000C
> byte 0x0D decoded to Unicode character U+000D
> byte 0x0E decoded to Unicode character U+000E
> byte 0x0F decoded to Unicode character U+000F
> byte 0x10 decoded to Unicode character U+0010
> byte 0x11 decoded to Unicode character U+0011
> byte 0x12 decoded to Unicode character U+0012
> byte 0x13 decoded to Unicode character U+0013
> byte 0x14 decoded to Unicode character U+0014
> byte 0x15 decoded to Unicode character U+0015
> byte 0x16 decoded to Unicode character U+0016
> byte 0x17 decoded to Unicode character U+0017
> byte 0x18 decoded to Unicode character U+0018
> byte 0x19 decoded to Unicode character U+0019
> byte 0x1A decoded to Unicode character U+001A
> byte 0x1B decoded to Unicode character U+001B
> byte 0x1C decoded to Unicode character U+001C
> byte 0x1D decoded to Unicode character U+001D
> byte 0x1E decoded to Unicode character U+001E
> byte 0x1F decoded to Unicode character U+001F
> byte 0x20 decoded to Unicode character U+0020
> byte 0x21 decoded to Unicode character U+0021
> byte 0x22 decoded to Unicode character U+0022
> byte 0x23 decoded to Unicode character U+0023
> byte 0x24 decoded to Unicode character U+0024
> byte 0x25 decoded to Unicode character U+0025
> byte 0x26 decoded to Unicode character U+0026
> byte 0x27 decoded to Unicode character U+0027
> byte 0x28 decoded to Unicode character U+0028
> byte 0x29 decoded to Unicode character U+0029
> byte 0x2A decoded to Unicode character U+002A
> byte 0x2B decoded to Unicode character U+002B
> byte 0x2C decoded to Unicode character U+002C
> byte 0x2D decoded to Unicode character U+002D
> byte 0x2E decoded to Unicode character U+002E
> byte 0x2F decoded to Unicode character U+002F
> byte 0x30 decoded to Unicode character U+0030
> byte 0x31 decoded to Unicode character U+0031
> byte 0x32 decoded to Unicode character U+0032
> byte 0x33 decoded to Unicode character U+0033
> byte 0x34 decoded to Unicode character U+0034
> byte 0x35 decoded to Unicode character U+0035
> byte 0x36 decoded to Unicode character U+0036
> byte 0x37 decoded to Unicode character U+0037
> byte 0x38 decoded to Unicode character U+0038
> byte 0x39 decoded to Unicode character U+0039
> byte 0x3A decoded to Unicode character U+003A
> byte 0x3B decoded to Unicode character U+003B
> byte 0x3C decoded to Unicode character U+003C
> byte 0x3D decoded to Unicode character U+003D
> byte 0x3E decoded to Unicode character U+003E
> byte 0x3F decoded to Unicode character U+003F
> byte 0x40 decoded to Unicode character U+0040
> byte 0x41 decoded to Unicode character U+0041
> byte 0x42 decoded to Unicode character U+0042
> byte 0x43 decoded to Unicode character U+0043
> byte 0x44 decoded to Unicode character U+0044
> byte 0x45 decoded to Unicode character U+0045
> byte 0x46 decoded to Unicode character U+0046
> byte 0x47 decoded to Unicode character U+0047
> byte 0x48 decoded to Unicode character U+0048
> byte 0x49 decoded to Unicode character U+0049
> byte 0x4A decoded to Unicode character U+004A
> byte 0x4B decoded to Unicode character U+004B
> byte 0x4C decoded to Unicode character U+004C
> byte 0x4D decoded to Unicode character U+004D
> byte 0x4E decoded to Unicode character U+004E
> byte 0x4F decoded to Unicode character U+004F
> byte 0x50 decoded to Unicode character U+0050
> byte 0x51 decoded to Unicode character U+0051
> byte 0x52 decoded to Unicode character U+0052
> byte 0x53 decoded to Unicode character U+0053
> byte 0x54 decoded to Unicode character U+0054
> byte 0x55 decoded to Unicode character U+0055
> byte 0x56 decoded to Unicode character U+0056
> byte 0x57 decoded to Unicode character U+0057
> byte 0x58 decoded to Unicode character U+0058
> byte 0x59 decoded to Unicode character U+0059
> byte 0x5A decoded to Unicode character U+005A
> byte 0x5B decoded to Unicode character U+005B
> byte 0x5C decoded to Unicode character U+005C
> byte 0x5D decoded to Unicode character U+005D
> byte 0x5E decoded to Unicode character U+005E
> byte 0x5F decoded to Unicode character U+005F
> byte 0x60 decoded to Unicode character U+0060
> byte 0x61 decoded to Unicode character U+0061
> byte 0x62 decoded to Unicode character U+0062
> byte 0x63 decoded to Unicode character U+0063
> byte 0x64 decoded to Unicode character U+0064
> byte 0x65 decoded to Unicode character U+0065
> byte 0x66 decoded to Unicode character U+0066
> byte 0x67 decoded to Unicode character U+0067
> byte 0x68 decoded to Unicode character U+0068
> byte 0x69 decoded to Unicode character U+0069
> byte 0x6A decoded to Unicode character U+006A
> byte 0x6B decoded to Unicode character U+006B
> byte 0x6C decoded to Unicode character U+006C
> byte 0x6D decoded to Unicode character U+006D
> byte 0x6E decoded to Unicode character U+006E
> byte 0x6F decoded to Unicode character U+006F
> byte 0x70 decoded to Unicode character U+0070
> byte 0x71 decoded to Unicode character U+0071
> byte 0x72 decoded to Unicode character U+0072
> byte 0x73 decoded to Unicode character U+0073
> byte 0x74 decoded to Unicode character U+0074
> byte 0x75 decoded to Unicode character U+0075
> byte 0x76 decoded to Unicode character U+0076
> byte 0x77 decoded to Unicode character U+0077
> byte 0x78 decoded to Unicode character U+0078
> byte 0x79 decoded to Unicode character U+0079
> byte 0x7A decoded to Unicode character U+007A
> byte 0x7B decoded to Unicode character U+007B
> byte 0x7C decoded to Unicode character U+007C
> byte 0x7D decoded to Unicode character U+007D
> byte 0x7E decoded to Unicode character U+007E
> byte 0x7F decoded to Unicode character U+007F
> byte 0x80 decoded to Unicode character U+0080
> byte 0x81 decoded to Unicode character U+0081
> byte 0x82 decoded to Unicode character U+0082
> byte 0x83 decoded to Unicode character U+0083
> byte 0x84 decoded to Unicode character U+0084
> byte 0x85 decoded to Unicode character U+0085
> byte 0x86 decoded to Unicode character U+0086
> byte 0x87 decoded to Unicode character U+0087
> byte 0x88 decoded to Unicode character U+0088
> byte 0x89 decoded to Unicode character U+0089
> byte 0x8A decoded to Unicode character U+008A
> byte 0x8B decoded to Unicode character U+008B
> byte 0x8C decoded to Unicode character U+008C
> byte 0x8D decoded to Unicode character U+008D
> byte 0x8E decoded to Unicode character U+008E
> byte 0x8F decoded to Unicode character U+008F
> byte 0x90 decoded to Unicode character U+0090
> byte 0x91 decoded to Unicode character U+0091
> byte 0x92 decoded to Unicode character U+0092
> byte 0x93 decoded to Unicode character U+0093
> byte 0x94 decoded to Unicode character U+0094
> byte 0x95 decoded to Unicode character U+0095
> byte 0x96 decoded to Unicode character U+0096
> byte 0x97 decoded to Unicode character U+0097
> byte 0x98 decoded to Unicode character U+0098
> byte 0x99 decoded to Unicode character U+0099
> byte 0x9A decoded to Unicode character U+009A
> byte 0x9B decoded to Unicode character U+009B
> byte 0x9C decoded to Unicode character U+009C
> byte 0x9D decoded to Unicode character U+009D
> byte 0x9E decoded to Unicode character U+009E
> byte 0x9F decoded to Unicode character U+009F
> byte 0xA0 decoded to Unicode character U+00A0
> byte 0xA1 decoded to Unicode character U+00A1
> byte 0xA2 decoded to Unicode character U+00A2
> byte 0xA3 decoded to Unicode character U+00A3
> byte 0xA4 decoded to Unicode character U+00A4
> byte 0xA5 decoded to Unicode character U+00A5
> byte 0xA6 decoded to Unicode character U+00A6
> byte 0xA7 decoded to Unicode character U+00A7
> byte 0xA8 decoded to Unicode character U+00A8
> byte 0xA9 decoded to Unicode character U+00A9
> byte 0xAA decoded to Unicode character U+00AA
> byte 0xAB decoded to Unicode character U+00AB
> byte 0xAC decoded to Unicode character U+00AC
> byte 0xAD decoded to Unicode character U+00AD
> byte 0xAE decoded to Unicode character U+00AE
> byte 0xAF decoded to Unicode character U+00AF
> byte 0xB0 decoded to Unicode character U+00B0
> byte 0xB1 decoded to Unicode character U+00B1
> byte 0xB2 decoded to Unicode character U+00B2
> byte 0xB3 decoded to Unicode character U+00B3
> byte 0xB4 decoded to Unicode character U+00B4
> byte 0xB5 decoded to Unicode character U+00B5
> byte 0xB6 decoded to Unicode character U+00B6
> byte 0xB7 decoded to Unicode character U+00B7
> byte 0xB8 decoded to Unicode character U+00B8
> byte 0xB9 decoded to Unicode character U+00B9
> byte 0xBA decoded to Unicode character U+00BA
> byte 0xBB decoded to Unicode character U+00BB
> byte 0xBC decoded to Unicode character U+00BC
> byte 0xBD decoded to Unicode character U+00BD
> byte 0xBE decoded to Unicode character U+00BE
> byte 0xBF decoded to Unicode character U+00BF
> byte 0xC0 decoded to Unicode character U+00C0
> byte 0xC1 decoded to Unicode character U+00C1
> byte 0xC2 decoded to Unicode character U+00C2
> byte 0xC3 decoded to Unicode character U+00C3
> byte 0xC4 decoded to Unicode character U+00C4
> byte 0xC5 decoded to Unicode character U+00C5
> byte 0xC6 decoded to Unicode character U+00C6
> byte 0xC7 decoded to Unicode character U+00C7
> byte 0xC8 decoded to Unicode character U+00C8
> byte 0xC9 decoded to Unicode character U+00C9
> byte 0xCA decoded to Unicode character U+00CA
> byte 0xCB decoded to Unicode character U+00CB
> byte 0xCC decoded to Unicode character U+00CC
> byte 0xCD decoded to Unicode character U+00CD
> byte 0xCE decoded to Unicode character U+00CE
> byte 0xCF decoded to Unicode character U+00CF
> byte 0xD0 decoded to Unicode character U+00D0
> byte 0xD1 decoded to Unicode character U+00D1
> byte 0xD2 decoded to Unicode character U+00D2
> byte 0xD3 decoded to Unicode character U+00D3
> byte 0xD4 decoded to Unicode character U+00D4
> byte 0xD5 decoded to Unicode character U+00D5
> byte 0xD6 decoded to Unicode character U+00D6
> byte 0xD7 decoded to Unicode character U+00D7
> byte 0xD8 decoded to Unicode character U+00D8
> byte 0xD9 decoded to Unicode character U+00D9
> byte 0xDA decoded to Unicode character U+00DA
> byte 0xDB decoded to Unicode character U+00DB
> byte 0xDC decoded to Unicode character U+00DC
> byte 0xDD decoded to Unicode character U+00DD
> byte 0xDE decoded to Unicode character U+00DE
> byte 0xDF decoded to Unicode character U+00DF
> byte 0xE0 decoded to Unicode character U+00E0
> byte 0xE1 decoded to Unicode character U+00E1
> byte 0xE2 decoded to Unicode character U+00E2
> byte 0xE3 decoded to Unicode character U+00E3
> byte 0xE4 decoded to Unicode character U+00E4
> byte 0xE5 decoded to Unicode character U+00E5
> byte 0xE6 decoded to Unicode character U+00E6
> byte 0xE7 decoded to Unicode character U+00E7
> byte 0xE8 decoded to Unicode character U+00E8
> byte 0xE9 decoded to Unicode character U+00E9
> byte 0xEA decoded to Unicode character U+00EA
> byte 0xEB decoded to Unicode character U+00EB
> byte 0xEC decoded to Unicode character U+00EC
> byte 0xED decoded to Unicode character U+00ED
> byte 0xEE decoded to Unicode character U+00EE
> byte 0xEF decoded to Unicode character U+00EF
> byte 0xF0 decoded to Unicode character U+00F0
> byte 0xF1 decoded to Unicode character U+00F1
> byte 0xF2 decoded to Unicode character U+00F2
> byte 0xF3 decoded to Unicode character U+00F3
> byte 0xF4 decoded to Unicode character U+00F4
> byte 0xF5 decoded to Unicode character U+00F5
> byte 0xF6 decoded to Unicode character U+00F6
> byte 0xF7 decoded to Unicode character U+00F7
> byte 0xF8 decoded to Unicode character U+00F8
> byte 0xF9 decoded to Unicode character U+00F9
> byte 0xFA decoded to Unicode character U+00FA
> byte 0xFB decoded to Unicode character U+00FB
> byte 0xFC decoded to Unicode character U+00FC
> byte 0xFD decoded to Unicode character U+00FD
> byte 0xFE decoded to Unicode character U+00FE

If you think this is a bug, I can happily report this to HPE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:39:17 2018
From: report at bugs.python.org (chen wu)
Date: Tue, 28 Aug 2018 08:39:17 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1535445557.72.0.56676864532.issue34516@psf.upfronthosting.co.za>


chen wu <wuchen12 at huawei.com> added the comment:

yeah, i noticed that. but this function also return host with '[]'.

183    # IPv6
184    if url and url[0] == '[':
185        host, url = url.split(']', 1)
186        host += ']'

if url is [aaa:bbb]:123, host is [aaa:bbb] and url is ':123'after this process.

when host=[aaa:bbb] passed to httplib.HTTPConnection, its function 'putrequest' will put 'Host:[[aaa:bbb]]:123' in headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:41:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 08:41:52 +0000
Subject: [issue34171] Lib/trace.cover not removed by the clean target
In-Reply-To: <1532102937.62.0.56676864532.issue34171@psf.upfronthosting.co.za>
Message-ID: <1535445712.09.0.56676864532.issue34171@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e3f20828f6b7f59baa2d25437176ee32ae7700b0 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.7':
bpo-34171: Fix test_trace. (GH-8940) (GH-8951)
https://github.com/python/cpython/commit/e3f20828f6b7f59baa2d25437176ee32ae7700b0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34171>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:42:29 2018
From: report at bugs.python.org (Antony Lee)
Date: Tue, 28 Aug 2018 08:42:29 +0000
Subject: [issue34526] Path.relative_to() taking multiple arguments could be
 better documented
Message-ID: <1535445749.23.0.56676864532.issue34526@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

Currently, the docs for Path.relative_to read

    PurePath.relative_to(*other)
    Compute a version of this path relative to the path represented by other. If it?s impossible, ValueError is raised: (examples follow)

It's a bit confusing why other is a star-args, especially as no example actually passes more than one argument to relative_to.

The docstring is a tiny bit clearer:

    Return the relative path to another path identified by the passed
    arguments.  If the operation is not possible (because this is not
    a subpath of the other path), raise ValueError.

Effectively, a Path is constructed from all *other args and used as base for the computation of the relative path.  It looks a bit like a misfeature to me, but at least it could be better documented (e.g. by adding `Path("/tmp/foo/bar").relative_to("/tmp", "foo") == Path("bar")` as example in the docs).

----------
assignee: docs at python
components: Documentation
messages: 324224
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Path.relative_to() taking multiple arguments could be better documented
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34526>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:47:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 08:47:24 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535446044.34.0.56676864532.issue34403@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 04:59:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 08:59:06 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535446746.19.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

...
> byte 0xA7 decoded to Unicode character U+00A7
...

Well, it confirms what I expected: nl_langinfo(CODESET) announces "roman8", but mbstowcs() uses Latin1 encoding in practice.

So I wrote the PR 8969 which forces the ASCII encoding in that case. I'm not sure how test_utf8_mode is supposed to be fixed in that case.

Michael: you can try to apply PR 8969, and then apply manually PR 8967 patch:
https://patch-diff.githubusercontent.com/raw/python/cpython/pull/8967.patch

But I expect that with both patches, test_utf8_mode will still fail on test_cmd_line(). You can try to modify test_cmd_line() to force encoding to "ascii".

What are the values of sys.getfilesystemencoding() and locale.getpreferredencoding() with the C locale with PR 8969? I expect "roman8" which can cause issue in os.fsencode()/os.fsdecode(). Maybe Python should also force ASCII here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:02:20 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 28 Aug 2018 09:02:20 +0000
Subject: [issue11190] test_locale error on AIX
In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>
Message-ID: <1535446940.13.0.56676864532.issue11190@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Ok - testing other Python3 versions:

3.4.9 - failed
3.5.5 - failed

3.7.0 - passes - ah - but due to skip tests!
test_strcoll (test.test_locale.TestEnUSCollation) ... testing with 'en_US.ISO8859-1'... ok
test_strcoll_with_diacritic (test.test_locale.TestEnUSCollation) ... skipped 'bpo-29972: broken test on AIX'
test_strxfrm (test.test_locale.TestEnUSCollation) ... testing with 'en_US.ISO8859-1'... ok
test_strxfrm_with_diacritic (test.test_locale.TestEnUSCollation) ... skipped 'bpo-29972: broken test on AIX'

So, I guess it is still an issue to be examined, just not urgently.

----------
versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11190>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:04:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 09:04:33 +0000
Subject: [issue11190] test_locale error on AIX
In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>
Message-ID: <1535447073.53.0.56676864532.issue11190@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> So, I guess it is still an issue to be examined, just not urgently.

The test pass in the master branch, so I close the issue.

If you want to do something, discuss with the maintainers of AIX C library to ask them if strcoll() work as expected according to them.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11190>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:20:13 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 09:20:13 +0000
Subject: [issue34519] Add additional aliases for HP Roman 8
In-Reply-To: <1535377191.85.0.56676864532.issue34519@psf.upfronthosting.co.za>
Message-ID: <1535448013.58.0.56676864532.issue34519@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please provide references for the definition of 'cp1051' and 'ibm1051'.

----------
nosy: +lemburg, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34519>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:27:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 09:27:15 +0000
Subject: [issue34519] Add additional aliases for HP Roman 8
In-Reply-To: <1535377191.85.0.56676864532.issue34519@psf.upfronthosting.co.za>
Message-ID: <1535448435.82.0.56676864532.issue34519@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The hp-roman8 codec was added in issue996067. The link to the original data (ftp://dkuug.dk/i18n/charmaps/HP-ROMAN8) is dead now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34519>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:35:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 09:35:24 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
Message-ID: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

vstinner at freebsd$ env -i LC_ALL=POSIX ./python -m test -v test_cmd_line_script  -m test_non_ascii
== CPython 3.8.0a0 (heads/master:096329f0b2, Aug 28 2018, 09:30:55) [Clang 4.0.0 (tags/RELEASE_400/final 297347)]
== FreeBSD-11.1-RELEASE-amd64-64bit-ELF little-endian
== cwd: /usr/home/vstinner/prog/python/master/build/test_python_13073
== CPU count: 2
== encodings: locale=US-ASCII, FS=ascii
Run tests sequentially
0:00:00 load avg: 0.48 [1/1] test_cmd_line_script
test_non_ascii (test.test_cmd_line_script.CmdLineTest) ... FAIL

======================================================================
FAIL: test_non_ascii (test.test_cmd_line_script.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/vstinner/prog/python/master/Lib/test/test_cmd_line_script.py", line 512, in test_non_ascii
    'stdout=%r stderr=%r' % (stdout, stderr))
AssertionError: "'./@test_13073_tmp\\udce7w\\udcf0.py'" != "'<filename encoding error>'"
- './@test_13073_tmp\udce7w\udcf0.py'
+ '<filename encoding error>'
 : stdout=b"'<filename encoding error>'\n" stderr=b"Failed checking if argv[0] is an import path entry\nUnicodeEncodeError: 'ascii' codec can't encode character '\\xe7' in position 17: ordinal not in range(128)"

----------------------------------------------------------------------
Ran 1 test in 0.093s

FAILED (failures=1)
test test_cmd_line_script failed
test_cmd_line_script failed

== Tests result: FAILURE ==

1 test failed:
    test_cmd_line_script

Total duration: 170 ms
Tests result: FAILURE


By the way, the UTF-8 Mode is not enabled by the POSIX locale:

vstinner at freebsd$ env -i LC_ALL=POSIX ./python -c 'import sys; print(sys.flags.utf8_mode)'
0

It contradicts the PEP 540 which says the the UTF-8 Mode is enabled by the POSIX locale:

https://www.python.org/dev/peps/pep-0540/#abstract

> This mode is off by default, but is automatically activated when using the "POSIX" locale.

----------
components: Interpreter Core
messages: 324230
nosy: ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: On FreeBSD, Python 3 doesn't support support the POSIX locale
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:36:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 09:36:15 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1535448975.83.0.56676864532.issue26544@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8443

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:37:46 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 09:37:46 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1535449066.29.0.56676864532.issue26544@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8444

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:51:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 09:51:01 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1535449861.85.0.56676864532.issue26544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Would it be possible to add a few tests on platform._comparable_version()? It would make me more confortable for backports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:51:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 09:51:17 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535449877.65.0.56676864532.issue34527@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8445
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 05:54:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 09:54:28 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535450068.04.0.56676864532.issue34508@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Other examples:

    eval('*(1, 2), 3')

    a = []; a += *(1, 2), 3

    for i in *(1, 2), 3: pass

    def g(): yield *(1, 2), 3

----------
nosy: +benjamin.peterson, gvanrossum, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 06:20:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 10:20:11 +0000
Subject: [issue26544] platform.libc_ver() returns incorrect version number
In-Reply-To: <1457742963.17.0.0403505576154.issue26544@psf.upfronthosting.co.za>
Message-ID: <1535451611.8.0.56676864532.issue26544@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +8446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26544>
_______________________________________

From report at bugs.python.org  Tue Aug 28 06:21:43 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 10:21:43 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535451703.68.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

The compilation failed on my PR when running PCbuild\amd64\_freeze_importlib.exe:

ValueError: only 'strict' and 'surrogateescape' error handlers are supported, not 'surrogatepass'

The error comes from locale_error_handler(). Before my change, PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefault() used Py_FileSystemDefaultEncodeErrors which is initialized to "surrogateescape", but only set to "surrogatepass" by initfsencoding().

With my change, the error handler is directly set to "surrogatepass", but currently, unicode_encode_locale() and unicode_decode_locale() don't accept this error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Tue Aug 28 06:35:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 10:35:46 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535452546.95.0.56676864532.issue34527@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5cb258950ce9b69b1f65646431c464c0c17b1510 by Victor Stinner in branch 'master':
bpo-34527: POSIX locale enables the UTF-8 Mode (GH-8972)
https://github.com/python/cpython/commit/5cb258950ce9b69b1f65646431c464c0c17b1510


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 06:49:59 2018
From: report at bugs.python.org (Cabu)
Date: Tue, 28 Aug 2018 10:49:59 +0000
Subject: [issue34528] Windows installer: Failed to run untrusted mode.
Message-ID: <1535453399.16.0.56676864532.issue34528@psf.upfronthosting.co.za>


New submission from Cabu <cabuzelth at yahoo.com>:

At work, we are using Windows 7 Enterprise. I have local admin rights on a separate account.

When trying to install Python 3.6.3 or 3.7.0 for amd64, the installer stop after a couple of seconds without any message/popup. But, I have found the attched log in a temp folder.

It seems that the installer try to run a copy of itself in a folder where even the local admin can't run executables by company policy.

I didn't find any issue with the same error code in the tracker.

----------
components: Installation
files: Setup_20180828111438_Failed.txt
messages: 324235
nosy: Cabu, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer: Failed to run untrusted mode.
type: crash
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47768/Setup_20180828111438_Failed.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34528>
_______________________________________

From report at bugs.python.org  Tue Aug 28 06:50:44 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 10:50:44 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535453444.78.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Here is the output to your questions:
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ git checkout hpux_force_ascii
> Branch 'hpux_force_ascii' set up to track remote branch 'hpux_force_ascii' from 'vstinner'.
> Switched to a new branch 'hpux_force_ascii'
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ git cherry-pick 217af1d38db3e1e875180c6fa160f0fc80e46003
> [hpux_force_ascii 7ce2927185] bpo-34403, bpo-34207: Fix test_utf8_mode.test_cmd_line()
>  Author: Victor Stinner <vstinner at redhat.com>
>  Date: Tue Aug 28 09:35:25 2018 +0200
>  1 file changed, 20 insertions(+), 11 deletions(-)
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ export CC=/opt/aCC/bin/cc ; \
>  export CXX=/opt/aCC/bin/aCC ; \
>  export LDFLAGS=-L/usr/local/lib/hpux32 ; \
>  export UNIX_STD=1998 ; \
> ./configure --prefix=/var/osipovmi/python37-testing --without-gcc --with-system-expat --with-pydebug --with-openssl=/opt/openssl
> ...
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ gmake -j 8
> ...
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ ./python -m test test_utf8_mode
> Run tests sequentially
> 0:00:00 [1/1] test_utf8_mode
> test test_utf8_mode failed -- Traceback (most recent call last):
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 235, in test_cmd_line
>     LC_ALL='C')
>   File "/var/osipovmi/cpython/Lib/test/test_utf8_mode.py", line 214, in check
>     self.assertEqual(args, ascii(expected), out)
> AssertionError: "['h\\udca7\\udce9']" != "['h\\xcf\\xd5']"
> - ['h\udca7\udce9']
> + ['h\xcf\xd5']
>  : roman8:['h\udca7\udce9']
> 
> test_utf8_mode failed
> 
> == Tests result: FAILURE ==
> 
> 1 test failed:
>     test_utf8_mode
> 
> Total duration: 3 sec 58 ms
> Tests result: FAILURE
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ git diff
> diff --git a/Lib/test/test_utf8_mode.py b/Lib/test/test_utf8_mode.py
> index 5af35aed61..89c1f92615 100644
> --- a/Lib/test/test_utf8_mode.py
> +++ b/Lib/test/test_utf8_mode.py
> @@ -231,7 +231,7 @@ class UTF8ModeTests(unittest.TestCase):
> 
>          # Check that the command line is decoded from the locale encoding
>          with self.subTest(encoding=encoding):
> -            check('utf8=0', [arg.decode(encoding, 'surrogateescape')],
> +            check('utf8=0', [arg.decode('ascii', 'surrogateescape')],
>                    LC_ALL='C')
> 
>      def test_optim_level(self):
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ ./python -m test test_utf8_mode
> Run tests sequentially
> 0:00:00 [1/1] test_utf8_mode
> 
> == Tests result: SUCCESS ==
> 
> 1 test OK.
> 
> Total duration: 3 sec 65 ms
> Tests result: SUCCESS
> 
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ LC_ALL=C ./python -X utf8=0
> Python 3.8.0a0 (heads/hpux_force_ascii:7ce2927185, Aug 28 2018, 12:43:04) [C] on hp-ux11
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import locale ; import sys
> >>> sys.getfilesystemencoding() ; locale.getpreferredencoding()
> 'hp-roman8'
> 'roman8'
> >>>
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $

I cannot give a qualified answer on
> Maybe Python should also force ASCII here?
but since you have figured out that the conversion is broken, one must treat is as such or use ASCII only and UTF-8 for the rest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 07:00:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Aug 2018 11:00:13 +0000
Subject: [issue34410] itertools.tee not thread-safe;
 can segfault interpreter when wrapped iterator releases GIL
In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za>
Message-ID: <1535454013.96.0.56676864532.issue34410@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This might be redundant but I googled 'itertools tee thread safe' and came across a detailed SO answer from 2017 that explains the issue along with a similar example that causes segfault in the compiler but it was not reported here it seems. It also proposes a possible solution to fix the iterator but not tee itself. 

SO answer : https://stackoverflow.com/a/44638570/2610955

Similar open issue that could be a duplicate 

https://bugs.python.org/issue24482


Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34410>
_______________________________________

From report at bugs.python.org  Tue Aug 28 07:12:47 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 28 Aug 2018 11:12:47 +0000
Subject: [issue24482] itertools.tee causes segfault in a multithreading
 environment, while the equivalent implementation doesn't
In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za>
Message-ID: <1535454767.25.0.56676864532.issue24482@psf.upfronthosting.co.za>


Change by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24482>
_______________________________________

From report at bugs.python.org  Tue Aug 28 07:20:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 11:20:06 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535455206.96.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> -            check('utf8=0', [arg.decode(encoding, 'surrogateescape')],
> +            check('utf8=0', [arg.decode('ascii', 'surrogateescape')],
>                    LC_ALL='C')
>  (...)
> == Tests result: SUCCESS ==

Good, it works.

I updated my PR 8969 to implement properly my idea. With this PR, on HP-UX with C or POSIX locale, Python now uses ASCII for its "filesystem encoding": sys.getfilesystemencoding() returns "ascii".

Michael: can you please try my updated PR 8969?

* apply the updated change
* recompile Python
* run the test suite using: LC_ALL=C ./python -m test -j0 -r

You may also test with the current locale: ./python -m test -j0 -r

If everything is good on your side, I will merge my PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 07:20:10 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Aug 2018 11:20:10 +0000
Subject: [issue24482] itertools.tee causes segfault in a multithreading
 environment, while the equivalent implementation doesn't
In-Reply-To: <1434884360.87.0.819783838298.issue24482@psf.upfronthosting.co.za>
Message-ID: <1535455210.31.0.56676864532.issue24482@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I can also reproduce the original script's segfault in 2.7 but not in master. There is a related bug as per the original description by Dmitry that itertools.tee is not thread safe in https://bugs.python.org/msg323817 and a related SO answer to this that will add some context https://stackoverflow.com/a/44638570/2610955

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24482>
_______________________________________

From report at bugs.python.org  Tue Aug 28 07:24:59 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 11:24:59 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535455499.54.0.56676864532.issue34527@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8447

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 07:51:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 11:51:24 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535457084.98.0.56676864532.issue34527@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 65ef7425a32ee411d8047a4fad0fc6bb9ff733b1 by Victor Stinner in branch '3.7':
bpo-34527: POSIX locale enables the UTF-8 Mode (GH-8972) (GH-8974)
https://github.com/python/cpython/commit/65ef7425a32ee411d8047a4fad0fc6bb9ff733b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:07:05 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:07:05 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535458025.19.0.56676864532.issue34527@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8448

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:09:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:09:09 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535458149.66.0.56676864532.issue34527@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Note: Python 2.7 is not affected: it doesn't have "force_ascii" and "LC_ALL=POSIX ./python -m test test_cmd_line_script" pass successfully.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:10:53 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 28 Aug 2018 12:10:53 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1535455206.96.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <B9A96C79-C727-48E7-B725-AB66F40AF2D6@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

No time to compile for a couple of days. Stress from others wins instead. 

Maybe on Friday. 

Sent from my iPhone

> On 28 Aug 2018, at 13:20, STINNER Victor <report at bugs.python.org> wrote:
> 
> 
> STINNER Victor <vstinner at redhat.com> added the comment:
> 
>> -            check('utf8=0', [arg.decode(encoding, 'surrogateescape')],
>> +            check('utf8=0', [arg.decode('ascii', 'surrogateescape')],
>>                   LC_ALL='C')
>> (...)
>> == Tests result: SUCCESS ==
> 
> Good, it works.
> 
> I updated my PR 8969 to implement properly my idea. With this PR, on HP-UX with C or POSIX locale, Python now uses ASCII for its "filesystem encoding": sys.getfilesystemencoding() returns "ascii".
> 
> Michael: can you please try my updated PR 8969?
> 
> * apply the updated change
> * recompile Python
> * run the test suite using: LC_ALL=C ./python -m test -j0 -r
> 
> You may also test with the current locale: ./python -m test -j0 -r
> 
> If everything is good on your side, I will merge my PR.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34403>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:36:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:36:10 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535459770.19.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> The compilation failed on my PR when running PCbuild\amd64\_freeze_importlib.exe: (...)

This issue should now be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:47:12 2018
From: report at bugs.python.org (ron)
Date: Tue, 28 Aug 2018 12:47:12 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
Message-ID: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>


New submission from ron <ron at mailinator.com>:

Many service providers such as Google BigQuery do not accept Json.
They accept newline delimited Json.

https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-json#limitations

please allow to receive this format directly from the dump.

----------
messages: 324244
nosy: ronron
priority: normal
severity: normal
status: open
title: add the option for json.dumps to return newline delimited json
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:47:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:47:31 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
Message-ID: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Example:

$ env -i ./python -c 'import distutils.spawn; print(distutils.spawn.find_executable("true"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/vstinner/prog/python/master/Lib/distutils/spawn.py", line 176, in find_executable
    path = os.environ['PATH']
  File "/home/vstinner/prog/python/master/Lib/os.py", line 672, in __getitem__
    raise KeyError(key) from None
KeyError: 'PATH'


Attached PR fixes the issue for the master branch.

----------
components: Library (Lib)
messages: 324245
nosy: vstinner
priority: normal
severity: normal
status: open
title: distutils: find_executable() fails if the PATH environment variable is not set
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34530>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:51:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:51:53 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1535460713.16.0.56676864532.issue34530@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +8449
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34530>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:52:57 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:52:57 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1535460777.72.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm not sure that it's worth it to modify Python 3.7 and older. distutils changes are now well welcomed (breaking setuptools or pip is unpopular :-)).

----------
nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore
versions:  -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34530>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:53:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 12:53:34 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535460814.97.0.56676864532.issue34527@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 4ff38870b1de8a3add5357edf125c2866bc42b54 by Victor Stinner in branch '3.6':
bpo-34527: Fix FreeBSD with POSIX locale (GH-8975)
https://github.com/python/cpython/commit/4ff38870b1de8a3add5357edf125c2866bc42b54


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 08:58:02 2018
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 28 Aug 2018 12:58:02 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1535461082.32.0.56676864532.issue34498@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

> I would say we could update the check in `functools` to accept more things.

Could we revert abstract types in `typing` to respond True to `isinstance(..., type)` again?  I don't want singledispatch, or any other library like it, to have to special-case typing.   Especially for *non-generic* variants, responding True to `isinstance()` seems reasonable to me.  We cannot dispatch by `Sequence[int]` and some such so it makes sense for *those* to keep failing going forward.

The current suggested workaround of using abc.Sequence instead will work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Tue Aug 28 09:01:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 13:01:29 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535461289.85.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-34485 which allows to select (using _PyCoreConfig) the encoding and error handlers of standard streams like sys.stdout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Tue Aug 28 09:06:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 13:06:41 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535461601.19.0.56676864532.issue34527@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I wanted to quickly fix this issue since I'm working on 3 different issues where I got conflicts with these changes, and the other issues were impacted by this bug.

I sent an email to python-dev about this issue:
https://mail.python.org/pipermail/python-dev/2018-August/155052.html

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Tue Aug 28 09:20:27 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 28 Aug 2018 13:20:27 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1535462427.44.0.56676864532.issue34498@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Could we revert abstract types in `typing` to respond True to `isinstance(..., type)` again?

No, making them classes will cause significant performance penalty (I don't remember numbers now, but importing `typing` may be twice slower). Plus this will re-introduce some bugs and inconsistencies.

> I don't want singledispatch, or any other library like it, to have to special-case typing.

I didn't propose this. I proposed to allow all objects that pretend to be types but are not actually instances of `type`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Tue Aug 28 09:42:34 2018
From: report at bugs.python.org (Martin Panter)
Date: Tue, 28 Aug 2018 13:42:34 +0000
Subject: [issue34516] httplib sets unbefitting "Host" in request header when
 requests an ipv6 format url.
In-Reply-To: <1535352754.06.0.56676864532.issue34516@psf.upfronthosting.co.za>
Message-ID: <1535463754.11.0.56676864532.issue34516@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

This sounds like a duplicate of Issue 28539. My understanding of that report is that Urllib3 half parses the URL by splitting out the port number, but returns a hostname with square brackets intact. Requests then passes the hostname (string with brackets) and port number (integer) to Python?s HTTPConnection constructor.

I think this is a bug in how Requests or ?urllib3? is using Python?s HTTPConnection class. Requests should either leave the port number with the hostname in the string, or extract the raw hostname by removing the brackets.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> pending
superseder:  -> httplib/http.client HTTPConnection._set_hostport() regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34516>
_______________________________________

From report at bugs.python.org  Tue Aug 28 10:11:41 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 14:11:41 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535465501.14.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Victor,

this looks good to me:
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ git fetch vstinner
> remote: Counting objects: 65, done.
> remote: Compressing objects: 100% (18/18), done.
> remote: Total 65 (delta 41), reused 43 (delta 37), pack-reused 10
> Unpacking objects: 100% (65/65), done.
> From https://github.com/vstinner/cpython
>  + 6171da5569...559de620d7 hpux_force_ascii -> vstinner/hpux_force_ascii  (forced update)
>  * [new branch]            posix_locale37   -> vstinner/posix_locale37
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ git reset --hard  vstinner/hpux_force_ascii
> HEAD is now at 559de620d7 bpo-34403: On HP-UX, force ASCII for C locale
> $ gmake -j 8
> ...
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ LC_ALL=C ./python -m test -j0 -r -uall,-network
> ...
> == Tests result: FAILURE ==
> 
> 357 tests OK.
> 
> 35 tests failed:
>     test_asyncio test_asyncore test_bytes test_c_locale_coercion
>     test_code test_concurrent_futures test_ctypes test_devpoll
>     test_distutils test_embed test_faulthandler test_fileio test_gdb
>     test_httpservers test_importlib test_io test_mmap
>     test_multiprocessing_fork test_multiprocessing_forkserver
>     test_multiprocessing_main_handling test_multiprocessing_spawn
>     test_normalization test_os test_pkg test_posix test_pty test_re
>     test_signal test_socket test_subprocess test_support
>     test_threading test_time test_unicode test_zlib
> 
> 26 tests skipped:
>     test_curses test_dbm_gnu test_epoll test_idle test_kqueue
>     test_lzma test_msilib test_ossaudiodev test_smtpnet
>     test_socketserver test_spwd test_startfile test_tcl test_timeout
>     test_tix test_tk test_ttk_guionly test_ttk_textonly test_turtle
>     test_urllib2net test_urllibnet test_winconsoleio test_winreg
>     test_winsound test_xmlrpc_net test_zipfile64
> osipovmi at blnn724x:/var/osipovmi/cpython []
> $ ./python -m test -j0 -r -uall,-network
> ...
> == Tests result: FAILURE ==
> 
> 357 tests OK.
> 
> 35 tests failed:
>     test_asyncio test_asyncore test_bytes test_c_locale_coercion
>     test_code test_concurrent_futures test_ctypes test_devpoll
>     test_distutils test_embed test_faulthandler test_fileio test_gdb
>     test_httpservers test_importlib test_io test_mmap
>     test_multiprocessing_fork test_multiprocessing_forkserver
>     test_multiprocessing_main_handling test_multiprocessing_spawn
>     test_normalization test_os test_posix test_pty test_re
>     test_readline test_signal test_socket test_subprocess test_support
>     test_threading test_time test_unicode test_zlib
> 
> 26 tests skipped:
>     test_curses test_dbm_gnu test_epoll test_idle test_kqueue
>     test_lzma test_msilib test_ossaudiodev test_smtpnet
>     test_socketserver test_spwd test_startfile test_tcl test_timeout
>     test_tix test_tk test_ttk_guionly test_ttk_textonly test_turtle
>     test_urllib2net test_urllibnet test_winconsoleio test_winreg
>     test_winsound test_xmlrpc_net test_zipfile64
> 
> Total duration: 14 min 23 sec
> Tests result: FAILURE

The test_utf8_mode passes. Some other tests likely fail due to this Roman8 stuff: test_re and friends. I am analyzing the failures step by step and have already a few fixes around. Waiting for other PRs to be merged first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 10:28:17 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 28 Aug 2018 14:28:17 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535466497.84.0.56676864532.issue34508@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Serhiy. I'm happy to extend my PR to cover those cases, if there's general agreement that it's worth doing so. (*I* personally think this is worth doing, since it smooths some currently rough edges and removes a few surprises, but I'm not comfortable with pushing this forward just on that single data point.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:00:13 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 28 Aug 2018 15:00:13 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1535468413.45.0.56676864532.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I've gone ahead and addressed all of the significant issues raised here:

* Squeezer is no longer an extension
* Expanding problematically large outputs prompts the user for confirmation
* "copy" and "view" moved to a right-click context menu
* use IDLE's TextView for viewing squeezed outputs
  * I added the ability to set the text wrapping
* default minimum # lines for auto-squeezing increased to 50

I've also updated all of the tests accordingly and added a few.

There a several tweaks to consider, including those mentioned in my previous message, plus colors and key bindings.

This is now ready for another review!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:05:27 2018
From: report at bugs.python.org (Mitch Gann)
Date: Tue, 28 Aug 2018 15:05:27 +0000
Subject: [issue24632] Improve documentation about __main__.py
In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za>
Message-ID: <1535468727.29.0.56676864532.issue24632@psf.upfronthosting.co.za>


Mitch Gann <mgann85 at gmail.com> added the comment:

Can someone please update the Docs on this?  Its been over 3 years since the issue was raised and seems fairly straightforward to address.  Also considering its a fairly important feature of the language which deals with the entry point for packages/modules to be executed, I know many Engineers/Developers using and learning the language would benefit from official documentation on this aspect.

----------
nosy: +MGann85

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24632>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:08:50 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBSYWR3YcWEc2tp?=)
Date: Tue, 28 Aug 2018 15:08:50 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535468930.0.0.56676864532.issue34529@psf.upfronthosting.co.za>


Micha? Radwa?ski <lisklusownik at gmail.com> added the comment:

So this format is just a series of JSON, delimited by a newline. 
Instead of changing API, you might consider this piece of code:

def ndjsondump(objects):
    return '\n'.join(json.dumps(obj) for obj in objects)

Conversely, first you `str.splitlines`, then `json.loads` each line separately.

Does it satisfy your needs?

----------
nosy: +enedil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:25:17 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Aug 2018 15:25:17 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535469917.28.0.56676864532.issue34508@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think all of these are good.

Perhaps with a small change the for-loop example can allow an elegant way of iterating over multiple iterables. It would need a special case so that `for x in *a, *b:` doesn't first construct a tuple of all elements in a and b. Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:31:27 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 28 Aug 2018 15:31:27 +0000
Subject: [issue34531] doc Move comment about list sorting behavour outside
 impl-detail directive
Message-ID: <1535470287.16.0.56676864532.issue34531@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

As this text is phrased:

CPython implementation detail: While a list is being sorted, the effect of attempting to mutate, or even inspect, the list is undefined. The C implementation of Python makes the list appear empty for the duration, and raises ValueError if it can detect that the list has been mutated during a sort.

I take it that the first sentence is a general comment for all implementations, as the second sentence does define a specific behavior in CPython, so it's not undefined there.

I propose taking the first sentence out of the impl-detail directive.

----------
assignee: docs at python
components: Documentation
messages: 324259
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc Move comment about list sorting behavour outside impl-detail directive
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34531>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:33:39 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 28 Aug 2018 15:33:39 +0000
Subject: [issue34531] doc Move comment about list sorting behavour outside
 impl-detail directive
In-Reply-To: <1535470287.16.0.56676864532.issue34531@psf.upfronthosting.co.za>
Message-ID: <1535470419.93.0.56676864532.issue34531@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
keywords: +patch
pull_requests: +8450
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34531>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:40:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 15:40:38 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535470838.84.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d500e5307aec9c5d535f66d567fadb9c587a9a36 by Victor Stinner in branch 'master':
bpo-34403: On HP-UX, force ASCII for C locale (GH-8969)
https://github.com/python/cpython/commit/d500e5307aec9c5d535f66d567fadb9c587a9a36


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 11:57:25 2018
From: report at bugs.python.org (Michael Osipov)
Date: Tue, 28 Aug 2018 15:57:25 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535471845.11.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Can we backport this to 3.7 at least?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 12:14:47 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 28 Aug 2018 16:14:47 +0000
Subject: [issue21109] tarfile: Traversal attack vulnerability
In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za>
Message-ID: <1535472887.04.0.56676864532.issue21109@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

I've tested Lars's patch against my collection of sly tarballs:
https://github.com/jwilk/path-traversal-samples

SafeTarFile defeated most, but not all attacks.
It still allows directory traversal for these two tarfile:

1) https://github.com/jwilk/path-traversal-samples/releases/download/0/dirsymlink2a.tar

lrwxrwxrwx  cur -> .
lrwxrwxrwx  par -> cur/..
-rw-r--r--  par/moo

2) https://github.com/jwilk/path-traversal-samples/releases/download/0/dirsymlink2b.tar

lrwxrwxrwx  cur -> .
lrwxrwxrwx  cur/par -> ..
-rw-r--r--  par/moo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21109>
_______________________________________

From report at bugs.python.org  Tue Aug 28 12:42:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 16:42:08 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535474528.37.0.56676864532.issue34508@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> It would need a special case so that `for x in *a, *b:` doesn't first construct a tuple of all elements in a and b. Thoughts?

It may be surprising that `for x in *a, *b:` behave differently from `for x in (*a, *b):`.

It is idiomatic to create a list of keys and iterate it if you want to modify the dict during iterating:

    for key in list(d):
        # modify d

This can be written in a form

    for key in [*d]:
        # modify d

or

    for key in (*d,):
        # modify d

(although the latter variant is slightly slower).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:09:07 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 28 Aug 2018 17:09:07 +0000
Subject: [issue34482] datetime: Tests for potential crashes due to
 non-UTF-8-encodable strings
In-Reply-To: <1535046110.83.0.56676864532.issue34482@psf.upfronthosting.co.za>
Message-ID: <1535476147.34.0.56676864532.issue34482@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Yes, I've referenced the relevant message from #6697 in #34454.

The specific test you've referenced should be changed after #34481 is fixed -- it highlights inconsistency between C and Python implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34482>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:12:38 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Tue, 28 Aug 2018 17:12:38 +0000
Subject: [issue34532] Python launcher on Windows exits with error when
 requesting list of available versions
Message-ID: <1535476358.72.0.56676864532.issue34532@psf.upfronthosting.co.za>


New submission from Brendan Gerrity <bgerrity at ucdavis.edu>:

When any of the list available pythons arguments is used (e.g. `py -0`), the launcher exits with the error code 103 `RC_NO_PYTHON`.

This is inconsistent with the launcher's `-h` help argument, which exits with a 0.

----------
components: Windows
messages: 324265
nosy: bgerrity, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python launcher on Windows exits with error when requesting list of available versions
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34532>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:18:20 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Aug 2018 17:18:20 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535476700.37.0.56676864532.issue34508@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

That's fair. Maybe we shouldn't support `for x in *a, *b:` at all then, until we've got a BDFL decision? (Because once you support it one way you can't easily change the semantics without breaking backwards compatibility.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:33:09 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2018 17:33:09 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535477589.91.0.56676864532.issue34508@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I understand why non-parenthesized tuples are supported in assignments, in return statements and yield expressions and in for loops, but I'm surprised that they are supported in augmented assignments: `a += 1, 2, 3`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:45:04 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 28 Aug 2018 17:45:04 +0000
Subject: [issue34533] Apply PEP384 to _csv module
Message-ID: <1535478304.23.0.56676864532.issue34533@psf.upfronthosting.co.za>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

This applies the heap type refactoring from PEP 384 to the _csv module.

----------
components: Extension Modules
messages: 324268
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Apply PEP384 to _csv module
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34533>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:45:41 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 28 Aug 2018 17:45:41 +0000
Subject: [issue34533] Apply PEP384 to _csv module
In-Reply-To: <1535478304.23.0.56676864532.issue34533@psf.upfronthosting.co.za>
Message-ID: <1535478341.01.0.56676864532.issue34533@psf.upfronthosting.co.za>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch
pull_requests: +8451
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34533>
_______________________________________

From report at bugs.python.org  Tue Aug 28 13:59:34 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Aug 2018 17:59:34 +0000
Subject: [issue34508] return of non-parenthesized star-unpacking expression a
 SyntaxError
In-Reply-To: <1535293550.9.0.56676864532.issue34508@psf.upfronthosting.co.za>
Message-ID: <1535479174.83.0.56676864532.issue34508@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> I'm surprised that they are supported in augmented assignments: `a += 1, 2, 3`.

I guess at the time it was felt that it was better to support it everywhere it *could* be supported -- and if a is a list it even makes some amount of sense. In any case it's too late to change. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34508>
_______________________________________

From report at bugs.python.org  Tue Aug 28 14:12:08 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Aug 2018 18:12:08 +0000
Subject: [issue34531] doc Move comment about list sorting behavour outside
 impl-detail directive
In-Reply-To: <1535470287.16.0.56676864532.issue34531@psf.upfronthosting.co.za>
Message-ID: <1535479928.54.0.56676864532.issue34531@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The sentence should be left as-is.  It is there to make the following two sentences more intelligible.

The docs otherwise make no promises about other implementations and this is as it should be.

----------
nosy: +rhettinger
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34531>
_______________________________________

From report at bugs.python.org  Tue Aug 28 14:18:42 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Aug 2018 18:18:42 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535480322.21.0.56676864532.issue34529@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Would this need be fulfilled by the *separators* option?

    >>> from json import dumps
    >>> query = dict(system='primary', action='load')
    >>> print(dumps(query, separators=(',\n', ': ')))
    {"system": "primary",
    "action": "load"}

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Tue Aug 28 14:21:06 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Tue, 28 Aug 2018 18:21:06 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1535480466.77.0.56676864532.issue34062@psf.upfronthosting.co.za>


Change by Brendan Gerrity <bgerrity at ucdavis.edu>:


----------
nosy: +bgerrity

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Tue Aug 28 14:25:07 2018
From: report at bugs.python.org (Elliot Edmunds)
Date: Tue, 28 Aug 2018 18:25:07 +0000
Subject: [issue25433] whitespace in strip()/lstrip()/rstrip()
In-Reply-To: <1445170536.34.0.94220475409.issue25433@psf.upfronthosting.co.za>
Message-ID: <1535480707.66.0.56676864532.issue25433@psf.upfronthosting.co.za>


Elliot Edmunds <edmundselliot at gmail.com> added the comment:

Not sure how helpful it would be to have the re.sub expressions for lstrip and rstrip, but I think it would look like:

l_stripped = re.sub(r'^\s*', '', foo)
r_stripped = re.sub(r'\s*$', '', foo)

----------
nosy: +Elliot Edmunds
Added file: https://bugs.python.org/file47769/whitespace_regex.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25433>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:00:56 2018
From: report at bugs.python.org (Girts Folkmanis)
Date: Tue, 28 Aug 2018 19:00:56 +0000
Subject: [issue34534] importlib.resources does not work with packages that
 have no __init__.py
Message-ID: <1535482856.6.0.56676864532.issue34534@psf.upfronthosting.co.za>


New submission from Girts Folkmanis <opensource at girts.me>:

importlib.resources does not seem to work with packages that don't have __init__.py present. Since 3.3+ generally there is no need to create empty __init__.py, as directories are automatically treated as packages even without the file present. So my expectation would be that importlib.resources would follow the same suit. 

Repro, where I expect that both "mod1" and "mod2" would return the files when contents() is called:

$ find .
.
./mod2
./mod2/data.txt
./test.py
./mod1
./mod1/__init__.py
./mod1/data.txt

$ cat test.py
import importlib.resources

print('mod1:', list(importlib.resources.contents('mod1')))
print('mod2:', list(importlib.resources.contents('mod2')))

$ python3.7 test.py
mod1: ['__init__.py', '__pycache__', 'data.txt']
mod2: []    # <---- here I would expect to see files too


Looking at the source of Lib/importlib/resources.py, there is the following code in contents():

    [..]
    # Is the package a namespace package?  By definition, namespace packages
    # cannot have resources.  We could use _check_location() and catch the
    # exception, but that's extra work, so just inline the check.
    elif package.__spec__.origin is None or not package.__spec__.has_location:
        return ()
    [..]

This is the branch that is taken - but it's not necessarily a namespace package here, at least to my understanding. Is there a way to make the code here distinguish between namespace packages and implicit non-namespace packages here, and allow contents() (and other functions) to work?

----------
components: Library (Lib)
messages: 324275
nosy: girtsf
priority: normal
severity: normal
status: open
title: importlib.resources does not work with packages that have no __init__.py
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34534>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:08:39 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 28 Aug 2018 19:08:39 +0000
Subject: [issue34534] importlib.resources does not work with packages that
 have no __init__.py
In-Reply-To: <1535482856.6.0.56676864532.issue34534@psf.upfronthosting.co.za>
Message-ID: <1535483319.58.0.56676864532.issue34534@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

What's the difference between "namespace packages and implicit non-namespace packages"? I think those are the same thing, aren't they?

----------
nosy: +barry, brett.cannon, eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34534>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:20:21 2018
From: report at bugs.python.org (Paul Overing)
Date: Tue, 28 Aug 2018 19:20:21 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
Message-ID: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>


New submission from Paul Overing <paulovering at gmail.com>:

I have found that using timeout with a python queue.Queue() results in an average delay of  14.5ms in Windows over Ubuntu in python 3.6.5/3.7, I subtracted the 1 ms timeout.

I have also tried datetime.datetime.now() to measure the time, with similar results. 

Does that make sense?


import queue
import time

max=0
min=10000
num = 10000
sum = 0
for x in range(10000):
    q = queue.Queue()
    start = time.perf_counter()
    try:
        msg = q.get(block=True, timeout=.001)
    except:
        end = time.perf_counter()

    chng = end-start -.001

    if chng > max:
        max = chng
    if chng < min:
        min = chng
    sum = sum + chng

print(f"Avg: {sum/num}")
print(f"Min: {min}")
print(f"Max: {max}")

Results:

Window 10, Python 3.6.5/3.7
Avg: 0.014549868429997701
Min: 0.001674142000000046
Max: 0.13890251500000284

Ubuntu 16.04, Python 3.6.5/3.7
Avg: 6.275181290839012e-05
Min: 4.89290034456644e-05
Max: 8.690999695681965e-05

----------
components: Windows
messages: 324277
nosy: Gammaguy, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms
type: performance
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:27:23 2018
From: report at bugs.python.org (Girts Folkmanis)
Date: Tue, 28 Aug 2018 19:27:23 +0000
Subject: [issue34534] importlib.resources does not work with packages that
 have no __init__.py
In-Reply-To: <1535482856.6.0.56676864532.issue34534@psf.upfronthosting.co.za>
Message-ID: <1535484443.33.0.56676864532.issue34534@psf.upfronthosting.co.za>


Girts Folkmanis <opensource at girts.me> added the comment:

> What's the difference between "namespace packages and implicit non-namespace packages"? 

To me, the semantic difference is that "namespace packages" are what is used when you have "foo.bar" and "foo.baz" come from different distributions (https://packaging.python.org/guides/packaging-namespace-packages/). They get mentioned in "setup(packages=[...])" in distribution package's setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34534>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:29:45 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Aug 2018 19:29:45 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535484585.06.0.56676864532.issue34522@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't agree with "This means that a PyTypeObject's ob_type should always be set by PyType_Ready.", and therefore don't agree with the change to PyVarObject_HEAD_INIT.

In particular this is not correct when the type has a custom metatype (e.g. ob_type != &PyType_Type). 

BTW. I don't understand why changing the invocation of PyVarObject_HEAD_INIT is needed at all.  Adding calls to PyType_Ready can be don without that change (and I agree with explicitly initialising all types).

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:30:15 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Aug 2018 19:30:15 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535484615.69.0.56676864532.issue34522@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

(added "object model" reviewers to the nosy list)

----------
nosy: +benjamin.peterson, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:35:43 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 28 Aug 2018 19:35:43 +0000
Subject: [issue34534] importlib.resources does not work with packages that
 have no __init__.py
In-Reply-To: <1535482856.6.0.56676864532.issue34534@psf.upfronthosting.co.za>
Message-ID: <1535484943.31.0.56676864532.issue34534@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

https://docs.python.org/3/reference/import.html#regular-packages

Regular packages have __init__.py files and namespace packages do not.  "Implicit non-namespace packages" aren't really A Thing.

This design choice is deliberate; namespace packages themselves have no physical location so there's no place to put resources within them.  Is there a problem with adding empty __init__.py files to regular packages with resources?

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34534>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:37:44 2018
From: report at bugs.python.org (Paul Pinterits)
Date: Tue, 28 Aug 2018 19:37:44 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
Message-ID: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>


New submission from Paul Pinterits <rawing7 at gmail.com>:

In a conversation with Ethan Furman (the author of the enum module) I've been informed that Enum automatically checks whether the _missing_ method has returned an instance of the correct class, and raises a TypeError if not. (Link: https://stackoverflow.com/a/52064774/1222951)

However, this simply does not happen.

```
import enum

class MyEnum(enum.Enum):
    FOO = "foo"

    @classmethod
    def _missing_(cls, value):
        return 5

print(MyEnum('bar'))  # output: 5
```

----------
components: Library (Lib)
messages: 324282
nosy: Paul Pinterits
priority: normal
severity: normal
status: open
title: Enum._missing_ doesn't raise TypeError when a non-Enum object is a returned
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:44:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Aug 2018 19:44:30 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535485470.88.0.56676864532.issue34535@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:47:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Aug 2018 19:47:24 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1535485644.71.0.56676864532.issue22872@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Tue Aug 28 15:59:12 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 28 Aug 2018 19:59:12 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535486352.44.0.56676864532.issue34522@psf.upfronthosting.co.za>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

@ronaldoussoren Please read the complete analysis from the mailing list: https://mail.python.org/pipermail/python-dev/2018-August/154946.html. The description here was just a rehash and I probably missed some context. 

Particularly, when I said: "PyTypeObject's ob_type should always be set by PyType_Ready" I was referring to the PyTypeObject's that are statically set in C code. Metatypes explicitly have to set the ob_type and that's already handled.

In the current state of things, you have static PyTypeObjects that are being used before calling PyType_Ready due to this macro. This change just standardizes the header of static PyTypeObject throughout the entire codebase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Tue Aug 28 16:05:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 20:05:29 +0000
Subject: [issue34537] test_gdb fails with LC_ALL=C
Message-ID: <1535486729.44.0.56676864532.issue34537@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

On Python 3.7 and master, test_strings() of test_gdb fails if gdb uses Python 3.6 (before UTF-8 Mode and C locale coercion):

* gdb uses ASCII encoding for stdout
* tested Python uses UTF-8 thanks to the UTF-8 Mode and/or C locale coercion


vstinner at apu$ LC_ALL=C ./python -m test -v test_gdb -m test_strings
== CPython 3.7.0+ (heads/3.7:65ef7425a3, Aug 28 2018, 16:29:30) [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)]
== Linux-4.17.6-200.fc28.x86_64-x86_64-with-fedora-28-Twenty_Eight little-endian
== cwd: /home/vstinner/prog/python/3.7/build/test_python_21689
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.35 [1/1] test_gdb
GDB version 8.1:
    GNU gdb (GDB) Fedora 8.1.1-3.fc28
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-redhat-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings ... FAIL

======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/3.7/Lib/test/test_gdb.py", line 331, in test_strings
    check_repr('\u2620')
  File "/home/vstinner/prog/python/3.7/Lib/test/test_gdb.py", line 323, in check_repr
    self.assertGdbRepr(text)
  File "/home/vstinner/prog/python/3.7/Lib/test/test_gdb.py", line 271, in assertGdbRepr
    % (gdb_repr, exp_repr, gdb_output)))
AssertionError: "'\\u2620'" != "'?'"
- '\u2620'
+ '?'
 : "'\\u2620'" did not equal expected "'?'"; full output was:
Breakpoint 1 at 0x52fc1b: file Python/bltinmodule.c, line 1216.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, builtin_id (self=, v='\u2620') at Python/bltinmodule.c:1216
1216	    return PyLong_FromVoidPtr(v);
#0  builtin_id (self=, v='\u2620') at Python/bltinmodule.c:1216


----------------------------------------------------------------------
Ran 1 test in 1.030s

FAILED (failures=1)
test test_gdb failed
test_gdb failed

== Tests result: FAILURE ==

1 test failed:
    test_gdb

Total duration: 1 sec 422 ms
Tests result: FAILURE

----------
components: Tests, Unicode
messages: 324284
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: test_gdb fails with LC_ALL=C
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34537>
_______________________________________

From report at bugs.python.org  Tue Aug 28 16:10:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 20:10:28 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535487028.8.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8452

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 16:27:06 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 28 Aug 2018 20:27:06 +0000
Subject: [issue34479] ArgumentParser subparser error display at the wrong level
In-Reply-To: <1535038332.48.0.56676864532.issue34479@psf.upfronthosting.co.za>
Message-ID: <1535488026.8.0.56676864532.issue34479@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

The subparser is called with `parse_known_args` which just puts unknown args in a _UNRECOGNIZED_ARGS_ATTR attribute slot in the namespace, which is then passed back to the main parser.

(this occurs in _SubParsersAction.__call__)

If `parser.parse_known_args` is used, then these arguments will appear in the `extras` list.  Otherwise `parser.parse_args` issues the 'unrecognized arguments' error message (with the main parser usage).

I suspect this issue has been raised previously.  And I don't see any easy way of altering the behavior.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34479>
_______________________________________

From report at bugs.python.org  Tue Aug 28 16:40:51 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Tue, 28 Aug 2018 20:40:51 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
Message-ID: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

https://docs.python.org/3.8/tutorial/errors.html (and all other versions of that page back at least as far as 2.7) currently contain the guidance "When creating a module that can raise several distinct errors, a common practice is to create a base class for exceptions defined by that module, and subclass that to create specific exception classes for different error conditions: <code example>".

It may have seemed like a good idea at the time, but we now know from years of experience that this is an experiment that didn't pan out and we can consider this guidance a Now-Contraindicated Best Practice Of Yesteryear?.

Modules define subclasses of Exception for lots of reasons. Some of those subclasses have no relation to one another except that they are subclasses of Exception. Some of those subclasses define Exception instances that are never raised by code in the module, but that are expected to be raised by code passed to and called by the module.

Yes, there are times when a common base class may be appropriate - such as when an inheritance hierarchy and polymorphism that satisfy the Liskov Substitution Principle make sense for the Exception subclasses, and when the base class itself is used (such as when the base class is an item in the Raises: section of a function's doc string). But these cases aren't so common as to justify the advice being offered generally about all Exception subclass definitions.

Exception subclasses are just classes. Advising that authors may wish to define a common base class for all Exception subclasses in a module is like advising authors that they may wish to define a common base class for all object subclasses in a module - it's very, very, very occasionally a good idea in the particular circumstances of a particular module's implementation, but very generally not.

----------
assignee: docs at python
components: Documentation
messages: 324286
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: Remove encouragement to author a base class for all Exception subclasses in a module
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:04:27 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Aug 2018 21:04:27 +0000
Subject: [issue34520] test_asyncio leaked [2, 2, 2] references,
 sum=6 in AMD64 Windows8.1 Refleaks 3.7
In-Reply-To: <1535386947.0.0.56676864532.issue34520@psf.upfronthosting.co.za>
Message-ID: <1535490267.25.0.56676864532.issue34520@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If it isn't leaking in 3.8 then it's possibly not disposing of the event loop (I added a check for that in https://github.com/python/cpython/commit/8425de4147eb8d83befbb8ea77516fc764bb4309#diff-226dcee10b9d2f379e54d4415489236f ).

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34520>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:05:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:05:30 +0000
Subject: [issue34520] test_asyncio leaked [2, 2, 2] references,
 sum=6 in AMD64 Windows8.1 Refleaks 3.7
In-Reply-To: <1535386947.0.0.56676864532.issue34520@psf.upfronthosting.co.za>
Message-ID: <1535490330.81.0.56676864532.issue34520@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-32710.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34520>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:10:39 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:10:39 +0000
Subject: [issue34207] test_cmd_line test_utf8_mode test_warnings fail in all
 FreeBSD 3.x (3.8) buildbots
In-Reply-To: <1532441315.45.0.56676864532.issue34207@psf.upfronthosting.co.za>
Message-ID: <1535490639.5.0.56676864532.issue34207@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34207>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:14:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:14:20 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535490860.43.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Can we backport this to 3.7 at least?

My policy is to focus on the master branch to support a new platform. Then add a buildbot and find a core developer to maintain this platform. See the PEP 11 for details.

I would prefer to see a full test suite passing before discussing which changes should or should not be backported.

I would also prefer to first see a more general discussion about who is going to support HP-UX.

IMHO HP-UX is not officially supported today. My list of supported platforms:
https://pythondev.readthedocs.io/cpython.html#supported-platforms

See the test_utf8_mode now pass on HP-UX, I close the issue. Please open more specific issues for other failures. You might open a meta issue to track all HP-UX issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:26:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:26:36 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535491596.4.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 9e4994d410970fb4e75168401d159ba47a8f7108 by Victor Stinner in branch 'master':
bpo-34485: Enhance init_sys_streams() (GH-8978)
https://github.com/python/cpython/commit/9e4994d410970fb4e75168401d159ba47a8f7108


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:57:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:57:26 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535493446.35.0.56676864532.issue34200@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Recent failure on AMD64 Debian root 3.x:

https://buildbot.python.org/all/#/builders/27/builds/1433

0:07:40 load avg: 2.19 [278/418/1] test_pkg failed -- running: test_tools (1 min 18 sec)
test_1 (test.test_pkg.TestPkg) ... ok
test_2 (test.test_pkg.TestPkg) ... ok
test_3 (test.test_pkg.TestPkg) ... ok
test_4 (test.test_pkg.TestPkg) ... ERROR
test_5 (test.test_pkg.TestPkg) ... ok
test_6 (test.test_pkg.TestPkg) ... ok
test_7 (test.test_pkg.TestPkg) ... FAIL
test_8 (test.test_pkg.TestPkg) ... ok

======================================================================
ERROR: test_4 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_pkg.py", line 180, in test_4
    self.run_code(s)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_pkg.py", line 69, in run_code
    exec(textwrap.dedent(code), globals(), {"self": self})
  File "<string>", line 2, in <module>
  File "/tmp/tmpblwoj1h4/t4.py", line 1, in <module>
RuntimeError: Shouldnt load t4.py

======================================================================
FAIL: test_7 (test.test_pkg.TestPkg)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_pkg.py", line 260, in test_7
    '__name__', '__package__', '__path__', '__spec__'])
AssertionError: Lists differ: ['__c[34 chars]__loader__', '__name__', '__package__', '__spec__'] != ['__c[34 chars]__loader__', '__name__', '__package__', '__path__', '__spec__']

First differing element 6:
'__spec__'
'__path__'

Second list contains 1 additional elements.
First extra element 7:
'__spec__'

  ['__cached__',
   '__doc__',
   '__file__',
   '__loader__',
   '__name__',
   '__package__',
+  '__path__',
   '__spec__']

----------------------------------------------------------------------
Ran 8 tests in 0.038s

FAILED (failures=1, errors=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:58:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:58:06 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535493486.22.0.56676864532.issue34200@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Brett:
> I can't reproduce with master on macOS.

Vladimir Matveev:
> I've tried to repro this on Mac, Windows box and Windows VM - works fine for all cases.

Well, it's a race condition :-( It seems hard to reproduce, but it exists ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Tue Aug 28 17:59:55 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 21:59:55 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535493595.25.0.56676864532.issue34200@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Failure on AMD64 Windows8.1 Non-Debug 3.x buildbot:

https://buildbot.python.org/all/#/builders/12/builds/1223

ERROR: test_4 (test.test_pkg.TestPkg)
FAIL: test_7 (test.test_pkg.TestPkg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:00:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 22:00:52 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535493652.77.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:09:42 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 28 Aug 2018 22:09:42 +0000
Subject: [issue33407] Implement Py_DEPRECATED() macro for Visual Studio
In-Reply-To: <1525253389.49.0.682650639539.issue33407@psf.upfronthosting.co.za>
Message-ID: <1535494182.89.0.56676864532.issue33407@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +8454
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33407>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:16:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 22:16:58 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535494618.37.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 2c8ddcf4f14f3e4c87a6fe6678ab5ad09130c6ab by Victor Stinner in branch 'master':
bpo-34485: Fix _Py_InitializeCore() for C locale coercion (GH-8979)
https://github.com/python/cpython/commit/2c8ddcf4f14f3e4c87a6fe6678ab5ad09130c6ab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:19:31 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 28 Aug 2018 22:19:31 +0000
Subject: [issue34479] ArgumentParser subparser error display at the wrong level
In-Reply-To: <1535038332.48.0.56676864532.issue34479@psf.upfronthosting.co.za>
Message-ID: <1535494771.51.0.56676864532.issue34479@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

Errors that are associated with a specific argument, such as a wrong 'type' do get usage from the appropriate subparser.  

e.g.

In [164]: p.parse_args('--foo 1 cmd1 --bar x'.split())
usage: ipython3 cmd1 [-h] [--bar BAR]
ipython3 cmd1: error: argument --bar: invalid int value: 'x'

`required` tests also issue subparser specific usage; mutually exclusive tests probably do so as well.

But this unrecognized argument error is a bit less specific.  In your example '-x a' and 'a -x' will both produce the same error message.  The route by which the '-x' is put into the 'extras' list is different in the two cases, but in both it's the top 'parse_(known_)args' that determines whether to just return them, or raise an error.  '-x a -x' will put 2 '-x' in the unrecognized list.

If you really need a subparser specific message it might be possible to do so by modifying, or subclassing the _SubParsersAction class, making it raise an error when there are 'extras' rather than returning them as 'unrecognized'.  But that's not a backward compatible change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34479>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:22:32 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 22:22:32 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535494952.99.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8455

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:26:43 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 28 Aug 2018 22:26:43 +0000
Subject: [issue33407] Implement Py_DEPRECATED() macro for Visual Studio
In-Reply-To: <1525253389.49.0.682650639539.issue33407@psf.upfronthosting.co.za>
Message-ID: <1535495203.84.0.56676864532.issue33407@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33407>
_______________________________________

From report at bugs.python.org  Tue Aug 28 18:59:17 2018
From: report at bugs.python.org (Arthur Goldberg)
Date: Tue, 28 Aug 2018 22:59:17 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1535497157.27.0.56676864532.issue2506@psf.upfronthosting.co.za>


Arthur Goldberg <arthur.goldberg at mssm.edu> added the comment:

I'm another user of Ned's coverage tool. Our team at the Mount Sinai School of Medicine is building tools to model the dynamics of biochemistry inside individual cells. Our short term aims are to better understanding microbiology and model microorganisms so they can be engineered to more effectively produce drugs and do other industrial tasks. Long term, we seek to build genetically personalized models of human cells which can be used to improve the medical care of cancer and other illnesses. We're funded by several agencies of the federal government. Our field is called whole-cell modeling.

We use Python because it provides a wide array of powerful tools we can reuse to reduce our development time, enables us to rapidly prototype software to test and advance our modeling ideas, and is fun to program. Using git, pip, coverage, GitHub, CircleCI, Docker and other tools we've built a robust development environment that enables multiple people to contribute to advancing our tools for whole-cell modeling. We strongly emphasize software engineering because the data we use is large, incomplete and inconsistent, and our models are complex and difficult to train, verify and validate. We want to have a high level of confidence in our tested code so that if we have trouble with a model we can focus on checking the data and understanding the model design. Coverage testing is an important part of our software engineering. We test both line and branch coverage.

While working today on our simulator I found code that should have been fully covered except for a # pragma no cover, but was not fully covered. I reported it to Ned (https://github.com/nedbat/coveragepy/issues/697) who reproduced it in a simpler example and pointed out that this "Add mechanism to disable optimizations" issue contributed to the problem.

I realize that approximately 0.0% of Python users work on whole-cell modeling, which diminishes the importance of this use case. But Python is widely used in computational biomedicine, which represents many more users. Case in point -- I've created and teach a course in Biomedical Software Engineering which uses Python and teaches coverage testing to masters, PhD, and MD/PhD students.

We'd appreciate your help improving Ned's coverage tool. You can learn more about us at http://www.karrlab.org/ and https://github.com/KarrLab.

Regards
Arthur

----------
nosy: +ArthurGoldberg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Tue Aug 28 19:02:01 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 23:02:01 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535497321.96.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8456

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 19:13:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 23:13:33 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535498013.12.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 98c49c6ab239875e35a3c271bc8fabde6c9be804 by Victor Stinner in branch '3.7':
bpo-34485: Fix _Py_InitializeCore() for C locale coercion (GH-8979) (GH-8981)
https://github.com/python/cpython/commit/98c49c6ab239875e35a3c271bc8fabde6c9be804


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 19:29:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Aug 2018 23:29:09 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535498949.6.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 124b9eb4e41ba1676dad954eec9a1fb3480794e4 by Victor Stinner in branch 'master':
bpo-34485: Add _Py_ClearStandardStreamEncoding() (GH-8982)
https://github.com/python/cpython/commit/124b9eb4e41ba1676dad954eec9a1fb3480794e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Tue Aug 28 19:50:34 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 28 Aug 2018 23:50:34 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535500234.28.0.56676864532.issue34481@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
keywords: +patch
pull_requests: +8457
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Tue Aug 28 20:01:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 00:01:51 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535500911.42.0.56676864532.issue34481@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Wed Aug 29 00:14:44 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2018 04:14:44 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535516084.25.0.56676864532.issue34535@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Victor or Steve, do you know the resolution of perf_counter() and monotonic() on Windows?

----------
nosy: +rhettinger, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 00:20:50 2018
From: report at bugs.python.org (=?utf-8?q?=C3=81lvaro_Justen?=)
Date: Wed, 29 Aug 2018 04:20:50 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
Message-ID: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>


New submission from ?lvaro Justen <alvarojusten at gmail.com>:

I was working on a library called rows[https://github.com/turicas/rows] when a segmentation fault was thrown in the moment I've tried to read a CSV file. Since this part of the code is implemented completely in Python, I thought it could be a bug in Python itself.
Investigating the code I found it was faulting at exec()'s line inside namedtuple code (Lib/collections/__init__.py). After some time testing, I've came up with this piece of code to reproduce it:

```
try:
    float('?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx')
except:
    from collections import namedtuple
    namedtuple('T', 'f')
```

The code works if I:
- Run passing `PYTHONMALLOC=debug`
- Place 'from collections import namedtuple' into the first line
- Remove any char from the string in the 'float(...)' line
- Remove the '?' from the string in the 'float(...)' line

I've tested the code on Python 3.6.6, 3.7.0, 3.7-dev and 3.8-dev (versions installed using pyenv on a Debian GNU/Linux machine) and the problem happened only in 3.7.0.
This issue seems to be related to https://bugs.python.org/issue34087 but I preferred to create a new one since I don't know if there are automated tests for this specific case.

----------
components: Library (Lib)
files: namedtuple_bug.py
messages: 324300
nosy: turicas
priority: normal
severity: normal
status: open
title: namedtuple's exec() throws segmentation fault
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file47772/namedtuple_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Wed Aug 29 01:10:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 29 Aug 2018 05:10:18 +0000
Subject: [issue34540] shutil._call_external_zip should use subprocess
Message-ID: <1535519418.39.0.56676864532.issue34540@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

disutils.spawn isn't very good at quoting command lines (#8987). We need to use subprocess to avoid shell injection.

----------
components: Library (Lib)
messages: 324301
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: shutil._call_external_zip should use subprocess
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34540>
_______________________________________

From report at bugs.python.org  Wed Aug 29 01:14:07 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 29 Aug 2018 05:14:07 +0000
Subject: [issue34540] shutil._call_external_zip should use subprocess
In-Reply-To: <1535519418.39.0.56676864532.issue34540@psf.upfronthosting.co.za>
Message-ID: <1535519647.38.0.56676864532.issue34540@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +8458
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34540>
_______________________________________

From report at bugs.python.org  Wed Aug 29 03:09:23 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 29 Aug 2018 07:09:23 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535526563.03.0.56676864532.issue34538@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I agree with you.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Wed Aug 29 03:13:28 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 29 Aug 2018 07:13:28 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535526808.31.0.56676864532.issue34522@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I was also talking about static C types, it is possible to write types with custom meta types in C code (even if that is even less common than using meta types in the first place). I have extensions where I use PyVarObject_HEAD_INIT without the first argument being &PyType_Type or NULL and this patch would break those.

This part of your patch silently changes the API for CPython in a way that is confusing. With your patch this code changes behaviour:

static PyTypeObject my_type = {
     PyVarObject_HEAD_INIT(&my_meta_type, 0),
     ...
};

This is currently valid code and I use this pattern in my code. It is easy enough to adjust for your patch (just add "Py_TYPE(&my_type) = &my_meta_type;" before the call to PyType_Ready), but that is just a change for changes sake.

Why not just change all invocations of PyVarObject_HEAD_INIT in the CPython tree, if any? 

I do agree that explicitly calling PyType_Ready for all types would be better, but that is a separate issue from changing the way the static PyTypeObject is initialised.  

A patch that does add calls to PyType_Ready should also ensure that this is done before types are actually used (otherwise there is a nonzero chance that the explicit calls don't actually do anything due to the calls to PyType_Ready in strategic places in the interpreter).

Note that your patch tries to accomplish two things:

1) PyType_Ready should be called to initialize types

2) Explicitly setting the type of PyTypeObject instances through PyVarObject_HEAD_INIT is not necessary in the common case. 

I agree with the first item, and am -1 on a change for the second item, but -1 on the current patch for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Wed Aug 29 03:17:00 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 29 Aug 2018 07:17:00 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535527020.12.0.56676864532.issue34522@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. And that -1 was even before considering that PyVarObject_HEAD_INIT is not a type-object specific macro, but a macro to staticky initialize values of PyVarObject.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Wed Aug 29 03:32:49 2018
From: report at bugs.python.org (ron)
Date: Wed, 29 Aug 2018 07:32:49 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535527969.23.0.56676864532.issue34529@psf.upfronthosting.co.za>


ron <ron at mailinator.com> added the comment:

Raymond Hettinger answer is incorrect.

The main difference between Json and new line delimited json is that new line contains valid json in each line. Meaning you can do to line #47 and what you will have in this line is a valid json. Unlike the regular json where if one bracket is wrong the while  file is unreadable. 

You can not just add /n after one "object". You need also to change the brackets.

Keep in mind that not all Jsons are simple.. some contains huge amount of nested objects inside of them. You must identify where Json start and where it ends without being confused by nesting jsons.


There are many programming solutions to this issue.
For example:
https://stackoverflow.com/questions/51595072/convert-json-to-newline-json-standard-using-python/


My point is that this is a new format which is going to be widely accepted since Google adopted it for BigQuery.

flipping strings can also be easily implemented yet Python still build a function to do that for the user.

I think it's wise to allow support for this with in the Json library.. saving the trouble for programmer from thinking how to implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Wed Aug 29 03:43:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 07:43:18 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535528598.62.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8459

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 03:58:21 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 07:58:21 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535529501.94.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 315877dc361d554bec34b4b62c270479ad36a1be by Victor Stinner in branch 'master':
bpo-34485: stdout uses surrogateescape on POSIX locale (GH-8986)
https://github.com/python/cpython/commit/315877dc361d554bec34b4b62c270479ad36a1be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 04:11:13 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 08:11:13 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535530273.21.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 04:20:21 2018
From: report at bugs.python.org (Paul Pinterits)
Date: Wed, 29 Aug 2018 08:20:21 +0000
Subject: [issue34541] pathlib.Path.iterdir doesn't throw an exception until
 you start iterating
Message-ID: <1535530821.14.0.56676864532.issue34541@psf.upfronthosting.co.za>


New submission from Paul Pinterits <rawing7 at gmail.com>:

The fact that `Path.iterdir()` only throws exceptions once you start iterating over it makes it very difficult to write correct code.

Let's look at an example: We'll iterate over all children of a directory and print their file size.

If we try to do it like this, the `try...except` has no effect whatsoever:

try:
    children = path_that_doesnt_exist.iterdir()
except FileNotFoundError:
    print("directory doesn't exist")
for path in children:
    print(path.stat().st_size)

If we explicitly check whether the path exists (and is a directory), we end up with a race condition:

if path_that_doesnt_exist.is_dir():
    print("directory doesn't exist")
else:
    for path in children:
        print(path.stat().st_size)

We can wrap the whole loop in a `try...except`, but then we might end up catching exceptions we didn't intend to catch. (For example, the exception that's thrown when we try to get the size of a broken symlink.)

try:
    for path in path_that_doesnt_exist.iterdir():
        print(path.stat().st_size)  # this can also throw FileNotFoundError
except FileNotFoundError:
    print("directory doesn't exist")

We can manually call `next` on the iterator inside of a `try..except` block, but that's awfully verbose and requires knowledge about iterators and the `next` function:

children = iter(path_that_doesnt_exist.iterdir())
while True:
    try:
        path = next(children)
    except FileNotFoundError:
        print("directory doesn't exist")
        break
    print(path.stat().st_size)

Or we can turn the iterator into a list inside of a `try...except`, which seems to be the best option, but completely defeats the point of having an iterator:

try:
    children = list(path_that_doesnt_exist.iterdir())
except FileNotFoundError:
    print("directory doesn't exist")
else:
    for path in children:
        print(path.stat().st_size)

As you can see, writing correct (and good) code with `iterdir` is more difficult than it has any right to be. Please change this behavior so that exceptions are thrown immediately when `iterdir` is called.

----------
components: Library (Lib)
messages: 324307
nosy: Paul Pinterits
priority: normal
severity: normal
status: open
title: pathlib.Path.iterdir doesn't throw an exception until you start iterating
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34541>
_______________________________________

From report at bugs.python.org  Wed Aug 29 04:30:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 08:30:04 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535531404.48.0.56676864532.issue34535@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Victor or Steve, do you know the resolution of perf_counter() and monotonic() on Windows?

You can use:

>>> time.get_clock_info('perf_counter')
namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)

perf_counter() has usually a resolution much smaller than 1 ms (ex: 100 ns), whereas monotonic() has a bad resolution (around 15.6 ms).

Rounding matters for the monotonic clock on Windows :-) Python should round away from zero (ROUND_UP) for timeouts.

--

> I have found that using timeout with a python queue.Queue() results in an average delay of  14.5ms in Windows over Ubuntu in python 3.6.5/3.7, I subtracted the 1 ms timeout.

This behaviour looks correct to me. I suggest to close the issue.

Python rely on Windows API. Queue.get() uses a threading.Lock. On Windows, lock.acquire(timeout=timeout) uses EnterNonRecursiveMutex() which expects a number of a milliseconds. Even if you succeed to enhance the resolution of the system clock, you will still be stuck to a resolution of 1 ms because of the Windows API.

I'm not sure of what is your underlying question. Does it look inefficient to you? You can use threads or asyncio to write more efficient code. But this is out of the scope of the bug tracker :-)

I suggest to close this issue as "not a bug".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:01:45 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 09:01:45 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535533305.76.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 0b9ea4b211b24464c7d38f63e45e51c275c52dcd by Victor Stinner in branch '3.7':
[3.7] bpo-34485: stdout uses surrogateescape on POSIX locale (GH-8986) (GH-8987)
https://github.com/python/cpython/commit/0b9ea4b211b24464c7d38f63e45e51c275c52dcd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:02:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 09:02:23 +0000
Subject: [issue34527] On FreeBSD,
 Python 3 doesn't support support the POSIX locale
In-Reply-To: <1535448924.9.0.56676864532.issue34527@psf.upfronthosting.co.za>
Message-ID: <1535533343.93.0.56676864532.issue34527@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-34485. Example:

New changeset 0b9ea4b211b24464c7d38f63e45e51c275c52dcd by Victor Stinner in branch '3.7':
[3.7] bpo-34485: stdout uses surrogateescape on POSIX locale (GH-8986) (GH-8987)
https://github.com/python/cpython/commit/0b9ea4b211b24464c7d38f63e45e51c275c52dcd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34527>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:09:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 09:09:15 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535533755.56.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:25:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 09:25:23 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535534723.31.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 177d921c8c03d30daa32994362023f777624b10d by Victor Stinner in branch 'master':
bpo-34485, Windows: LC_CTYPE set to user preference (GH-8988)
https://github.com/python/cpython/commit/177d921c8c03d30daa32994362023f777624b10d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:38:44 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2018 09:38:44 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535535524.73.0.56676864532.issue34538@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think the advice should stay as-is.  In my experience as a teacher, the possibility doesn't usually occur to people without it having been suggested.  Also, it mirrors practices in the standard library (decimal.DecimalException and sqlite3.DatabaseError).  For users, it provides a way to catch possible errors that are specific to a particular module.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:39:35 2018
From: report at bugs.python.org (Danish Prakash)
Date: Wed, 29 Aug 2018 09:39:35 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1535535575.1.0.56676864532.issue34443@psf.upfronthosting.co.za>


Change by Danish Prakash <grafitykoncept at gmail.com>:


----------
keywords: +patch
pull_requests: +8462
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:41:49 2018
From: report at bugs.python.org (Danish Prakash)
Date: Wed, 29 Aug 2018 09:41:49 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1535535709.29.0.56676864532.issue34443@psf.upfronthosting.co.za>


Danish Prakash <grafitykoncept at gmail.com> added the comment:

Serhiy, why should __qualname__ always be used together with __module__? I can't seem to find a valid reason, I've been through the pep.

<made a PR due to inactivity>

----------
nosy: +prakashdanish

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:46:30 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2018 09:46:30 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
In-Reply-To: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>
Message-ID: <1535535990.04.0.56676864532.issue34539@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The works for me.  Can you try it on a fresh build or install of Python 3.7?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:47:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 09:47:33 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535536053.25.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dfe0dc74536dfb6f331131d9b2b49557675bb6b7 by Victor Stinner in branch 'master':
bpo-34485: Add _PyCoreConfig.stdio_encoding (GH-8881)
https://github.com/python/cpython/commit/dfe0dc74536dfb6f331131d9b2b49557675bb6b7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 05:50:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 09:50:04 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535536204.44.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh wow, I didn't expect that it would be so complicated to "just" get the encoding of sys.stdout... I had to fix many bugs to be able to do that!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 06:20:13 2018
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 29 Aug 2018 10:20:13 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535538013.09.0.56676864532.issue34538@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> Also, it mirrors practices in the standard library  (decimal.DecimalException and sqlite3.DatabaseError).

As Nathaniel said, "it's good idea in the particular circumstances of a particular module's implementation, but generally not."  (I removed "very" because it is too noisy)

For example, socket.error was migrated into OSError.
So not having base exception class for module is also "practices in the standard library".


> For users, it provides a way to catch possible errors that are specific to a particular module.

For tutorial readers, caching errors specific to particular cause should be suggested, instead of particular module.


"How/When custom base exception class is useful" is very high level topic.
It's too difficult for tutorial.

If tutorial reader start using base exception class without any real benefit, it will lead ugly code like this:

  try:
      # some code here
  except ValueError as e:
      raise CustomValueError(e.args)
  except TypeError as e:
      raise CustomTypeError(e.args)
  except ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Wed Aug 29 07:06:52 2018
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 29 Aug 2018 11:06:52 +0000
Subject: [issue34222] Email message serialization enters an infinite loop when
 folding non-ASCII headers with long words
In-Reply-To: <1532523404.04.0.56676864532.issue34222@psf.upfronthosting.co.za>
Message-ID: <1535540812.47.0.56676864532.issue34222@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +8463
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34222>
_______________________________________

From report at bugs.python.org  Wed Aug 29 07:25:40 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 11:25:40 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535541940.66.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b2457efc78b74a1d6d1b77d11a939e886b8a4e2c by Victor Stinner in branch 'master':
bpo-34523: Add _PyCoreConfig.filesystem_encoding (GH-8963)
https://github.com/python/cpython/commit/b2457efc78b74a1d6d1b77d11a939e886b8a4e2c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 07:33:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 11:33:09 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535542389.27.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 07:45:37 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 11:45:37 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535543137.71.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 70fead25e503a742ad4c919b151b9b2b5facee36 by Victor Stinner in branch 'master':
bpo-34523: Fix config_init_fs_encoding() (GH-8991)
https://github.com/python/cpython/commit/70fead25e503a742ad4c919b151b9b2b5facee36


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 08:24:28 2018
From: report at bugs.python.org (Paul Overing)
Date: Wed, 29 Aug 2018 12:24:28 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535545468.24.0.56676864532.issue34535@psf.upfronthosting.co.za>


Paul Overing <paulovering at gmail.com> added the comment:

Thank you for your quick response.  But 1ms resolution or not, 14.5ms does not seem reasonable given that in Ubuntu it is 0.049ms. Ubuntu is on average 295x faster.  

Also the variability in times is much higher in Windows max/avg = 9.547, avg/min =  8.69.

It makes the windows queue.Queue implementations with timeouts unusable in low latency environments and should be documented as such. As it is slow and highly variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 09:23:42 2018
From: report at bugs.python.org (Sergey G. Brester)
Date: Wed, 29 Aug 2018 13:23:42 +0000
Subject: [issue34489] subprocess: execution of batch-files (.cmd/.bat) is
 vulnerable in python for windows / insufficient escape
In-Reply-To: <1535139850.17.0.56676864532.issue34489@psf.upfronthosting.co.za>
Message-ID: <1535549022.62.0.56676864532.issue34489@psf.upfronthosting.co.za>


Sergey G. Brester <serg.brester at sebres.de> added the comment:

> Would you consider adding your test suite into the regression tests as well?

Sure. Done.

> Right now, this is a well known issue on all platforms

Really? I can't imagine this for something else as windows (and it is currently fixed also for windows only).
Anyway if you want the same test-cases for other platforms also, the windows skip-constraint of new test-class "CommandTryInject" should be removed (and the set-up as well as "_do_execwithargs" should get additional processing for *nix-shell-script instead of the .bat-file).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34489>
_______________________________________

From report at bugs.python.org  Wed Aug 29 09:37:45 2018
From: report at bugs.python.org (Michael Osipov)
Date: Wed, 29 Aug 2018 13:37:45 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535549865.1.0.56676864532.issue34403@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Please close, issue fixed. Thank you very much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Wed Aug 29 09:49:04 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 13:49:04 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1534251432.68.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <1535550544.42.0.56676864532.issue34403@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Please close, issue fixed. Thank you very much.

You're welcome ;-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________

From report at bugs.python.org  Wed Aug 29 10:17:16 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 29 Aug 2018 14:17:16 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
Message-ID: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

In bug #34399, I updated all RSA keys to 2048. However that not sufficient for future proof settings. Fedora's FUTURE crypto policy requires 3072bit RSA keys. Further more, I forgot to update the signature algorithm, too.

* RSA >= 3072bits
* finite field DH >= 3072bits
* signature algorithm with SHA2-256 or SHA2-384 PKCSv1 #1.5 (I don't think RSASSA-PSS works with OpenSSL 1.0.2 or TLS < 1.0)

----------
assignee: christian.heimes
components: SSL
messages: 324324
nosy: alex, christian.heimes, dstufft, janssen
priority: normal
severity: normal
stage: test needed
status: open
title: [TLS] Update test certs to future proof settings
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Wed Aug 29 10:25:58 2018
From: report at bugs.python.org (=?utf-8?q?=C3=81lvaro_Justen?=)
Date: Wed, 29 Aug 2018 14:25:58 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
In-Reply-To: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>
Message-ID: <1535552758.17.0.56676864532.issue34539@psf.upfronthosting.co.za>


?lvaro Justen <alvarojusten at gmail.com> added the comment:

I've cloned the cpython git repository and made fresh builds here:

On v.3.6.6 (4cf1f54eb764f856fda5a394d8598c0c90d69d77) it works:

    $ git checkout v3.6.6 && ./configure && make && ./python --version && ./python namedtuple_bug.py
    [...compilation lines supressed...]
    Python 3.6.6

On the v.3.7.0 (1bf9cc509326bc42cd8cb1650eb9bf64550d817e) it segfaults:

    $ git checkout v3.7.0 && make clean && ./configure && make && ./python --version && ./python namedtuple_bug.py
    [...compilation lines supressed...]
    Python 3.7.0
    Segmentation fault

On the most recent 3.7 branch (65ef7425a32ee411d8047a4fad0fc6bb9ff733b1) it works:

    $ git checkout 3.7 && make clean && ./configure && make && ./python --version && ./python namedtuple_bug.py
    [...compilation lines supressed...]
    Python 3.7.0+

On master branch (2c8ddcf4f14f3e4c87a6fe6678ab5ad09130c6ab) it also works:

    $ git checkout master && make clean && ./configure && make && ./python --version && ./python namedtuple_bug.py
    [...compilation lines supressed...]
    Python 3.8.0a0

Note: I've tried to add a `print('works!')` at the end of the script, so we can see the result when it does not segfault, but adding this actually make it works on all versions; removing this line has the behaviour reported above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Wed Aug 29 10:35:34 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 29 Aug 2018 14:35:34 +0000
Subject: [issue34399] [TLS] Update test keys to >= 2048bit
In-Reply-To: <1534236389.74.0.56676864532.issue34399@psf.upfronthosting.co.za>
Message-ID: <1535553334.01.0.56676864532.issue34399@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +8465

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34399>
_______________________________________

From report at bugs.python.org  Wed Aug 29 11:41:04 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Wed, 29 Aug 2018 15:41:04 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535557264.38.0.56676864532.issue34522@psf.upfronthosting.co.za>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

@ronaldoussoren

* This change currently works for all CPython. If you are using this pattern then you probably want to be using PyType_FromSpec rather than having a static PyTypeObject as discussed in PEP384: https://www.python.org/dev/peps/pep-0384. In general, extensions should all be using PyType_FromSpec rather than static PyTypeObjects.

* As mentioned by Erik Bray in the e-mail thread, the usage of a static PyTypeObject with a PyVarObject_HEAD_INIT requires a compile-time constant. This causes problems cross-compatibility problems, especially with Windows. You can read more here: http://iguananaut.net/blog/programming/windows-data-import.html

In general, this pattern is just pervasive. It causes cross-compatibility issues, it can cause users to forget calling PyType_Ready on a type and we are better off without it.

Again, please read the mail thread. Everything that I'm saying here is all discussed there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Wed Aug 29 11:43:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 15:43:15 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535557395.1.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8466

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 11:45:46 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Aug 2018 15:45:46 +0000
Subject: [issue34528] Windows installer: Failed to run untrusted mode.
In-Reply-To: <1535453399.16.0.56676864532.issue34528@psf.upfronthosting.co.za>
Message-ID: <1535557546.52.0.56676864532.issue34528@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Unfortunately, I don't have any better suggestion than trying to get your company policy changed :(

The "clean room" feature of our installer is not configurable (and also not in our code, so we can't change it without going through the upstream project). You will likely have similar trouble with any other installer that uses the same project, which includes many of Microsoft's programs - if there is an exception for Microsoft signed code, perhaps you could request an exception for PSF signed code?

If you have more information about the specific technical configuration that prevents this, then I may be able to follow up with people to find other ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34528>
_______________________________________

From report at bugs.python.org  Wed Aug 29 11:56:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 15:56:26 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535558186.81.0.56676864532.issue34535@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

>  It makes the windows queue.Queue implementations with timeouts unusable in low latency environments and should be documented as such. As it is slow and highly variable.

Well, it seems like you have a solution which is called Linux, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 12:04:00 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 29 Aug 2018 16:04:00 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535558640.77.0.56676864532.issue34481@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I'm finding it very difficult to reconcile these things. I'm not entirely sure, but we may need to take a performance hit in normal strftime if we want to make this work with surrogate characters, which really does not appeal to me (though we can certainly improve to some degree).

One major question here: Is anyone (@vstinner, @belopolsky?) know why time's strftime opportunistically uses wcsftime instead of strftime? It makes the code *way* more complicated and difficult to read / maintain - are there platforms that provide wcstrftime and not strftime?

Also, related, it seems according to https://bugs.python.org/issue10653#msg243660 that there may have been a regression in issue #10653, which may be related here.

Either way, some note should probably be made in the code to clarify exactly *why* these choices were made in the code, in case the situation has changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Wed Aug 29 12:18:52 2018
From: report at bugs.python.org (DeKrain)
Date: Wed, 29 Aug 2018 16:18:52 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
Message-ID: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>


New submission from DeKrain <dawidkrainski8 at gmail.com>:

>>> from _struct import Struct
>>> s = Struct.__new__(Struct)
>>> s.unpack_from(b'asdf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: /Objects/tupleobject.c:84: Bad argument to internal function

In Modules/_struct.c:

static PyObject *
s_unpack_internal(PyStructObject *soself, const char *startfrom) {
...
PyObject *result = PyTuple_New(soself->s_len);
// soself->s_len is -1, set in Struct.__new__

----------
components: Extension Modules
messages: 324330
nosy: DeKrain
priority: normal
severity: normal
status: open
title: _struct.Struct: calling functions without calling __init__ results in SystemError
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34543>
_______________________________________

From report at bugs.python.org  Wed Aug 29 12:43:51 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 29 Aug 2018 16:43:51 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535561031.77.0.56676864532.issue34543@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This exception goes back to at least Python 2.6 (if not older) but I'm not convinced it is a bug.

Calling __new__ alone is not guaranteed to initialise a new instance completely. The public API for creating an instance is to call the class object:

    s = Struct()


not to call __new__. You bypassed the proper initialisation of the instance, resulting in a broken, half-initialised instance. When you tried to use it, it correctly raised an exception.

If this caused a crash or a seg fault, then it would be reasonable to report it as a bug, but it looks to me that this is behaving correctly.

If you disagree, please explain why you think it is a bug.


(Also, for the record, you shouldn't be importing Struct from the private module _struct, you should import it from the public struct module.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34543>
_______________________________________

From report at bugs.python.org  Wed Aug 29 12:49:03 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Wed, 29 Aug 2018 16:49:03 +0000
Subject: [issue34541] pathlib.Path.iterdir doesn't throw an exception until
 you start iterating
In-Reply-To: <1535530821.14.0.56676864532.issue34541@psf.upfronthosting.co.za>
Message-ID: <1535561343.54.0.56676864532.issue34541@psf.upfronthosting.co.za>


Change by Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com>:


----------
keywords: +patch
pull_requests: +8467
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34541>
_______________________________________

From report at bugs.python.org  Wed Aug 29 12:50:54 2018
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 29 Aug 2018 16:50:54 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1535561454.43.0.56676864532.issue34542@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +8468
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Wed Aug 29 12:52:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 16:52:34 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535561554.51.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8469

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Tue Aug 28 14:43:44 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 28 Aug 2018 18:43:44 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <1535455206.96.0.56676864532.issue34403@psf.upfronthosting.co.za>
Message-ID: <2e69558e-40ac-fbb6-aee8-c3c79201648b@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 28/08/2018 13:20, STINNER Victor wrote:
> I updated my PR 8969 to implement properly my idea. With this PR, on HP-UX with C or POSIX locale, Python now uses ASCII for its "filesystem encoding": sys.getfilesystemencoding() returns "ascii".
>
> Michael: can you please try my updated PR 8969?
>
> * apply the updated change
> * recompile Python
> * run the test suite using: LC_ALL=C ./python -m test -j0 -r
>
> You may also test with the current locale: ./python -m test -j0 -r

Seems to work well as far as AIX and test_utf8_mode (as you had already
merged I pulled master and built that anew).

Attached is the output with LC_ALL=C in the prefix. If you were hoping
for "dangling processes - your hopes are affirmed.

Perhaps also noteworthy:

root at x066:[/data/prj/python/git/python3-3.8]set | grep LC
LC__FASTMSG=true
MAILCHECK=600
root at x066:[/data/prj/python/git/python3-3.8]set | grep LANG
LANG=en_US

----------
Added file: https://bugs.python.org/file47770/py3.8-LC-C.text

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________
-------------- next part --------------
Script command is started on Tue Aug 28 18:19:16 UTC 2018.
root at x066:[/data/prj/python/git/python3-3.8]script ../py3.8.textrm ../py3.8.text    ls ../py3.8.textls ../py3.8.text.rm ../py3.8.text.make             make distclean; buildaix --without-computed-gotos --with-openssl=/opt/aixto>cd *3.8                                                                     py     LC _ALL=C ./python -m test -j0 -r
== CPython 3.8.0a0 (heads/master:d500e5307a, Aug 28 2018, 18:09:17) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /data/prj/python/git/python3-3.8/build/test_python_16777456
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Using random seed 2001895
Run tests in parallel using 10 child processes
0:00:02 [  1/418] test_sqlite skipped
test_sqlite skipped -- No module named '_sqlite3'
0:00:02 [  2/418] test_startfile skipped
test_startfile skipped -- object <module 'os' from '/data/prj/python/git/python3-3.8/Lib/os.py'> has no attribute 'startfile'
0:00:02 [  3/418] test_mailcap passed
0:00:02 [  4/418] test_peepholer passed
0:00:02 [  5/418] test_sort passed
0:00:02 [  6/418] test_symbol passed
0:00:02 [  7/418] test_imghdr passed
0:00:02 [  8/418] test_string_literals passed
0:00:02 [  9/418] test_functools passed
0:00:03 [ 10/418] test_crashers passed
0:00:03 [ 11/418] test_unicode_identifiers passed
0:00:03 [ 12/418] test_metaclass passed
0:00:03 [ 13/418] test_normalization passed
0:00:03 [ 14/418] test_turtle skipped
test_turtle skipped -- No module named '_tkinter'
0:00:04 [ 15/418] test_codecmaps_kr passed
0:00:04 [ 16/418] test_pprint passed
0:00:04 [ 17/418] test_bdb passed
0:00:05 [ 18/418] test_pyexpat passed
0:00:05 [ 19/418] test_sched passed
0:00:05 [ 20/418] test_dict passed
0:00:05 [ 21/418] test_setcomps passed
0:00:05 [ 22/418] test_gdb skipped
test_gdb skipped -- Couldn't find gdb on the path
0:00:06 [ 23/418] test_ttk_textonly skipped
test_ttk_textonly skipped -- No module named '_tkinter'
0:00:06 [ 24/418] test_telnetlib passed
0:00:06 [ 25/418] test_plistlib passed
0:00:06 [ 26/418] test_urllib2 passed
0:00:07 [ 27/418] test_popen passed
0:00:07 [ 28/418] test_traceback passed
0:00:08 [ 29/418] test_pipes passed
0:00:08 [ 30/418] test_bisect passed
0:00:08 [ 31/418] test_robotparser passed
0:00:08 [ 32/418] test_statistics passed
0:00:08 [ 33/418] test_dataclasses passed
0:00:09 [ 34/418] test_linecache passed
0:00:09 [ 35/418] test_abstract_numbers passed
0:00:09 [ 36/418] test_profile passed
0:00:09 [ 37/418] test_pdb passed
0:00:09 [ 38/418] test__locale passed
0:00:10 [ 39/418] test_socketserver skipped (resource denied)
test_socketserver skipped -- Use of the 'network' resource not enabled
0:00:10 [ 40/418] test_nntplib passed
0:00:10 [ 41/418] test_xmlrpc_net skipped (resource denied)
test_xmlrpc_net skipped -- Use of the 'network' resource not enabled
0:00:10 [ 42/418] test_script_helper passed
0:00:11 [ 43/418] test_dbm_dumb passed
0:00:11 [ 44/418] test_epoll skipped
test_epoll skipped -- test works only on Linux 2.6
0:00:11 [ 45/418] test_genericpath passed
0:00:12 [ 46/418/1] test_time failed
test test_time failed -- multiple errors occurred; run in verbose mode for details
0:00:12 [ 47/418/1] test_ordered_dict passed
0:00:13 [ 48/418/1] test_wait4 passed
0:00:13 [ 49/418/1] test_stat passed
0:00:14 [ 50/418/1] test_file passed
0:00:14 [ 51/418/1] test_getopt passed
0:00:14 [ 52/418/1] test_capi passed
0:00:15 [ 53/418/1] test_code passed
0:00:15 [ 54/418/1] test_cprofile passed
0:00:15 [ 55/418/1] test_codecencodings_jp passed
0:00:16 [ 56/418/1] test_generator_stop passed
0:00:16 [ 57/418/1] test_module passed
0:00:16 [ 58/418/1] test_warnings passed
0:00:16 [ 59/418/1] test_unpack_ex passed
0:00:17 [ 60/418/1] test_typing passed
0:00:17 [ 61/418/1] test_tix skipped
test_tix skipped -- No module named '_tkinter'
0:00:17 [ 62/418/1] test_frame passed
0:00:18 [ 63/418/1] test_future passed
0:00:18 [ 64/418/1] test_aifc passed
0:00:19 [ 65/418/1] test_binascii passed
0:00:19 [ 66/418/1] test_cgi passed
0:00:20 [ 67/418/1] test_stringprep passed
0:00:21 [ 68/418/1] test_userdict passed
0:00:21 [ 69/418/1] test_zipapp passed
0:00:21 [ 70/418/1] test_dynamic passed
0:00:22 [ 71/418/1] test_abc passed
0:00:23 [ 72/418/1] test_set passed
0:00:24 [ 73/418/1] test_fork1 passed
0:00:24 [ 74/418/1] test_trace passed
0:00:25 [ 75/418/1] test_coroutines passed
0:00:27 [ 76/418/1] test_macpath passed
0:00:27 [ 77/418/1] test_webbrowser passed
0:00:28 [ 78/418/1] test_asyncore passed
0:00:28 [ 79/418/1] test_mailbox passed
0:00:28 [ 80/418/1] test_threadedtempfile passed
0:00:29 [ 81/418/1] test_uu passed
0:00:29 [ 82/418/1] test_funcattrs passed
0:00:29 [ 83/418/1] test_tokenize passed
0:00:30 [ 84/418/1] test_cmd passed
0:00:31 [ 85/418/1] test_finalization passed
0:00:31 [ 86/418/1] test_opcodes passed
0:00:32 [ 87/418/1] test_crypt passed
0:00:33 [ 88/418/1] test_datetime passed
0:00:33 [ 89/418/1] test_http_cookiejar passed
0:00:34 [ 90/418/1] test_wsgiref passed
0:00:40 [ 91/418/1] test_doctest passed -- running: test_support (34 sec 137 ms), test_zipfile (30 sec 188 ms)
0:00:40 [ 92/418/1] test_select passed -- running: test_support (34 sec 563 ms), test_zipfile (30 sec 614 ms)
0:00:41 [ 93/418/1] test_curses skipped (resource denied) -- running: test_support (35 sec 307 ms), test_zipfile (31 sec 358 ms)
test_curses skipped -- Use of the 'curses' resource not enabled
0:00:42 [ 94/418/1] test_codecencodings_iso2022 passed -- running: test_support (36 sec 50 ms), test_zipfile (32 sec 101 ms)
0:00:42 [ 95/418/1] test_poll passed -- running: test_support (36 sec 783 ms), test_zipfile (32 sec 834 ms)
0:00:43 [ 96/418/1] test_support passed (35 sec 855 ms) -- running: test_zipfile (33 sec 365 ms)
0:00:43 [ 97/418/1] test_kqueue skipped -- running: test_zipfile (33 sec 589 ms)
test_kqueue skipped -- test works only on BSD
0:00:44 [ 98/418/1] test_unittest passed -- running: test_zipfile (34 sec 65 ms)
0:00:44 [ 99/418/1] test_dummy_threading passed -- running: test_subprocess (30 sec 212 ms), test_zipfile (34 sec 782 ms)
0:00:45 [100/418/1] test_collections passed -- running: test_subprocess (30 sec 528 ms), test_zipfile (35 sec 97 ms)
0:00:45 [101/418/1] test_optparse passed -- running: test_subprocess (30 sec 594 ms), test_zipfile (35 sec 163 ms)
0:00:45 [102/418/1] test_glob passed -- running: test_subprocess (30 sec 660 ms), test_zipfile (35 sec 230 ms)
0:00:46 [103/418/1] test_codecencodings_kr passed -- running: test_subprocess (31 sec 677 ms), test_zipfile (36 sec 246 ms)
0:00:47 [104/418/1] test_rlcompleter passed -- running: test_subprocess (32 sec 476 ms), test_zipfile (37 sec 45 ms)
0:00:48 [105/418/1] test_zipfile64 skipped (resource denied) -- running: test_subprocess (33 sec 569 ms), test_zipfile (38 sec 138 ms)
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
0:00:48 [106/418/1] test_tarfile passed -- running: test_subprocess (33 sec 983 ms), test_zipfile (38 sec 553 ms)
0:00:48 [107/418/1] test_winreg skipped -- running: test_subprocess (34 sec 16 ms), test_zipfile (38 sec 585 ms)
test_winreg skipped -- No module named 'winreg'
0:00:50 [108/418/1] test_uuid passed -- running: test_subprocess (35 sec 699 ms), test_zipfile (40 sec 268 ms)
0:00:50 [109/418/1] test_fstring passed -- running: test_subprocess (35 sec 906 ms), test_zipfile (40 sec 476 ms)
0:00:50 [110/418/1] test_format passed -- running: test_subprocess (36 sec 264 ms), test_zipfile (40 sec 833 ms)
0:00:51 [111/418/1] test_urllib_response passed -- running: test_subprocess (36 sec 444 ms), test_zipfile (41 sec 13 ms)
0:00:51 [112/418/1] test_selectors passed -- running: test_subprocess (37 sec 266 ms), test_zipfile (41 sec 836 ms)
0:00:52 [113/418/1] test_iter passed -- running: test_subprocess (37 sec 419 ms), test_zipfile (41 sec 988 ms)
0:00:52 [114/418/1] test_gzip passed -- running: test_subprocess (37 sec 832 ms), test_zipfile (42 sec 401 ms)
0:00:56 [115/418/1] test_memoryio passed -- running: test_subprocess (41 sec 894 ms), test_zipfile (46 sec 463 ms)
0:00:57 [116/418/1] test_openpty passed -- running: test_subprocess (42 sec 876 ms), test_zipfile (47 sec 446 ms)
0:00:57 [117/418/2] test_httpservers failed -- running: test_subprocess (43 sec 51 ms), test_zipfile (47 sec 620 ms)
test test_httpservers failed -- multiple errors occurred; run in verbose mode for details
0:00:57 [118/418/2] test_bz2 passed -- running: test_subprocess (43 sec 242 ms), test_zipfile (47 sec 811 ms)
0:00:58 [119/418/2] test_winconsoleio skipped -- running: test_subprocess (43 sec 747 ms), test_zipfile (48 sec 317 ms)
test_winconsoleio skipped -- test only relevant on win32
0:00:58 [120/418/2] test_audioop passed -- running: test_subprocess (43 sec 816 ms), test_zipfile (48 sec 385 ms)
0:00:58 [121/418/2] test_raise passed -- running: test_subprocess (44 sec 343 ms), test_zipfile (48 sec 912 ms)
0:01:01 [122/418/2] test_urllib2_localnet passed -- running: test_subprocess (46 sec 991 ms), test_zipfile (51 sec 560 ms)
0:01:01 [123/418/2] test_pty passed -- running: test_subprocess (47 sec 55 ms), test_zipfile (51 sec 624 ms)
0:01:01 [124/418/2] test_re passed -- running: test_subprocess (47 sec 160 ms), test_zipfile (51 sec 729 ms)
0:01:02 [125/418/2] test_timeit passed -- running: test_subprocess (48 sec 30 ms), test_zipfile (52 sec 600 ms)
0:01:02 [126/418/2] test_osx_env passed -- running: test_subprocess (48 sec 140 ms), test_zipfile (52 sec 709 ms)
0:01:03 [127/418/2] test_cmd_line passed -- running: test_subprocess (48 sec 641 ms), test_zipfile (53 sec 210 ms)
0:01:03 [128/418/2] test_eof passed -- running: test_subprocess (48 sec 709 ms), test_zipfile (53 sec 279 ms)
0:01:03 [129/418/2] test_userstring passed -- running: test_subprocess (48 sec 735 ms), test_zipfile (53 sec 305 ms)
0:01:03 [130/418/2] test_iterlen passed -- running: test_subprocess (48 sec 864 ms), test_zipfile (53 sec 433 ms)
0:01:04 [131/418/2] test_structmembers passed -- running: test_subprocess (49 sec 505 ms), test_zipfile (54 sec 75 ms)
0:01:04 [132/418/2] test_global passed -- running: test_subprocess (49 sec 517 ms), test_zipfile (54 sec 86 ms)
0:01:04 [133/418/2] test_bigmem passed -- running: test_subprocess (49 sec 675 ms), test_zipfile (54 sec 244 ms)
0:01:04 [134/418/2] test_idle skipped -- running: test_subprocess (50 sec 269 ms), test_zipfile (54 sec 839 ms)
test_idle skipped -- No module named '_tkinter'
0:01:05 [135/418/2] test_types passed -- running: test_subprocess (50 sec 597 ms), test_zipfile (55 sec 167 ms)
0:01:05 [136/418/2] test_urllib passed -- running: test_subprocess (50 sec 630 ms), test_zipfile (55 sec 200 ms)
0:01:06 [137/418/2] test_itertools passed -- running: test_subprocess (51 sec 576 ms), test_zipfile (56 sec 146 ms)
0:01:07 [138/418/2] test_msilib skipped -- running: test_subprocess (52 sec 602 ms), test_zipfile (57 sec 172 ms)
test_msilib skipped -- No module named '_msi'
0:01:08 [139/418/2] test_inspect passed -- running: test_subprocess (53 sec 742 ms), test_zipfile (58 sec 311 ms)
0:01:08 [140/418/2] test_filecmp passed -- running: test_subprocess (54 sec 36 ms), test_zipfile (58 sec 605 ms)
0:01:09 [141/418/2] test_threaded_import passed -- running: test_subprocess (54 sec 493 ms), test_zipfile (59 sec 62 ms)
0:01:09 [142/418/2] test_dbm_gnu skipped -- running: test_subprocess (54 sec 530 ms), test_zipfile (59 sec 99 ms)
test_dbm_gnu skipped -- No module named '_gdbm'
0:01:11 [143/418/2] test_c_locale_coercion passed -- running: test_subprocess (56 sec 417 ms), test_zipfile (1 min 986 ms)
0:01:11 [144/418/2] test_pstats passed -- running: test_subprocess (57 sec 354 ms), test_zipfile (1 min 1 sec)
0:01:13 [145/418/2] test_difflib passed -- running: test_subprocess (58 sec 580 ms), test_zipfile (1 min 3 sec)
0:01:14 [146/418/2] test_symtable passed -- running: test_subprocess (59 sec 752 ms), test_zipfile (1 min 4 sec)
0:01:14 [147/418/2] test_utf8_mode passed -- running: test_subprocess (59 sec 754 ms), test_zipfile (1 min 4 sec)
0:01:14 [148/418/2] test_range passed -- running: test_subprocess (1 min 356 ms), test_zipfile (1 min 4 sec)
0:01:15 [149/418/2] test_sundry passed -- running: test_subprocess (1 min 720 ms), test_zipfile (1 min 5 sec), test_argparse (30 sec 128 ms)
0:01:15 [150/418/2] test_textwrap passed -- running: test_subprocess (1 min 1 sec), test_zipfile (1 min 5 sec), test_argparse (30 sec 541 ms)
0:01:15 [151/418/2] test_scope passed -- running: test_subprocess (1 min 1 sec), test_zipfile (1 min 5 sec), test_argparse (30 sec 750 ms)
0:01:16 [152/418/2] test_copyreg passed -- running: test_subprocess (1 min 2 sec), test_zipfile (1 min 6 sec), test_argparse (31 sec 425 ms)
0:01:17 [153/418/2] test_site passed -- running: test_subprocess (1 min 2 sec), test_zipfile (1 min 7 sec), test_argparse (32 sec 3 ms)
0:01:17 [154/418/2] test_dynamicclassattribute passed -- running: test_subprocess (1 min 2 sec), test_zipfile (1 min 7 sec), test_argparse (32 sec 68 ms)
0:01:18 [155/418/2] test_httplib passed -- running: test_subprocess (1 min 3 sec), test_zipfile (1 min 8 sec), test_argparse (33 sec 20 ms)
0:01:19 [156/418/2] test_xml_etree passed -- running: test_subprocess (1 min 4 sec), test_zipfile (1 min 9 sec), test_argparse (34 sec 104 ms)
0:01:19 [157/418/2] test_weakref passed -- running: test_subprocess (1 min 5 sec), test_zipfile (1 min 9 sec), test_argparse (34 sec 419 ms)
0:01:20 [158/418/2] test_flufl passed -- running: test_subprocess (1 min 5 sec), test_zipfile (1 min 10 sec), test_argparse (34 sec 887 ms)
0:01:21 [159/418/2] test_slice passed -- running: test_subprocess (1 min 6 sec), test_zipfile (1 min 11 sec), test_argparse (36 sec 56 ms)
0:01:21 [160/418/2] test_argparse passed (35 sec 299 ms) -- running: test_subprocess (1 min 6 sec), test_zipfile (1 min 11 sec)
0:01:22 [161/418/2] test_longexp passed -- running: test_subprocess (1 min 8 sec), test_zipfile (1 min 12 sec), test_asyncio (30 sec 799 ms)
0:01:22 [162/418/2] test_exceptions passed -- running: test_subprocess (1 min 8 sec), test_zipfile (1 min 12 sec), test_asyncio (30 sec 950 ms)
0:01:24 [163/418/2] test_gettext passed -- running: test_subprocess (1 min 10 sec), test_zipfile (1 min 14 sec), test_asyncio (33 sec 80 ms)
0:01:25 [164/418/2] test_bool passed -- running: test_subprocess (1 min 10 sec), test_zipfile (1 min 15 sec), test_asyncio (33 sec 591 ms)
0:01:35 [165/418/3] test_embed failed -- running: test_subprocess (1 min 21 sec), test_distutils (30 sec 535 ms), test_venv (32 sec 491 ms), test_zipfile (1 min 25 sec), test_asyncio (43 sec 867 ms)
test test_embed failed -- multiple errors occurred; run in verbose mode for details
0:01:44 [166/418/3] test_pyclbr passed -- running: test_subprocess (1 min 29 sec), test_distutils (38 sec 916 ms), test_venv (40 sec 873 ms), test_zipfile (1 min 34 sec), test_asyncio (52 sec 248 ms)
0:01:44 [167/418/3] test_xdrlib passed -- running: test_subprocess (1 min 29 sec), test_distutils (39 sec 367 ms), test_venv (41 sec 324 ms), test_zipfile (1 min 34 sec), test_asyncio (52 sec 699 ms)
0:01:45 [168/418/3] test_wave passed -- running: test_subprocess (1 min 30 sec), test_distutils (40 sec 167 ms), test_venv (42 sec 124 ms), test_zipfile (1 min 35 sec), test_asyncio (53 sec 499 ms)
0:01:45 [169/418/3] test_binhex passed -- running: test_subprocess (1 min 31 sec), test_distutils (40 sec 671 ms), test_venv (42 sec 628 ms), test_zipfile (1 min 35 sec), test_asyncio (54 sec 3 ms)
0:01:47 [170/418/3] test_list passed -- running: test_runpy (30 sec 616 ms), test_subprocess (1 min 33 sec), test_distutils (42 sec 672 ms), test_venv (44 sec 629 ms), test_zipfile (1 min 37 sec), test_asyncio (56 sec 4 ms)
0:02:14 [171/418/3] test_multibytecodec passed -- running: test_runpy (57 sec 257 ms), test_subprocess (1 min 59 sec), test_io (56 sec 316 ms), test_distutils (1 min 9 sec), test_venv (1 min 11 sec), test_zipfile (2 min 4 sec), test_asyncio (1 min 22 sec), test_multiprocessing_forkserver (51 sec 853 ms), test_faulthandler (53 sec 269 ms)
0:02:17 [172/418/3] test_faulthandler passed (54 sec 278 ms) -- running: test_runpy (1 min 618 ms), test_subprocess (2 min 3 sec), test_io (59 sec 671 ms), test_distutils (1 min 12 sec), test_venv (1 min 14 sec), test_zipfile (2 min 7 sec), test_asyncio (1 min 26 sec), test_multiprocessing_forkserver (55 sec 208 ms)
0:02:18 [173/418/3] test_zlib passed -- running: test_runpy (1 min 1 sec), test_subprocess (2 min 4 sec), test_io (1 min 431 ms), test_distutils (1 min 13 sec), test_venv (1 min 15 sec), test_zipfile (2 min 8 sec), test_asyncio (1 min 26 sec), test_multiprocessing_forkserver (55 sec 968 ms)
0:02:18 [174/418/3] test_pow passed -- running: test_runpy (1 min 1 sec), test_subprocess (2 min 4 sec), test_io (1 min 598 ms), test_distutils (1 min 13 sec), test_venv (1 min 15 sec), test_zipfile (2 min 8 sec), test_asyncio (1 min 26 sec), test_multiprocessing_forkserver (56 sec 135 ms)
0:02:23 [175/418/3] test_docxmlrpc passed -- running: test_runpy (1 min 5 sec), test_subprocess (2 min 8 sec), test_io (1 min 5 sec), test_distutils (1 min 18 sec), test_venv (1 min 19 sec), test_zipfile (2 min 13 sec), test_asyncio (1 min 31 sec), test_multiprocessing_forkserver (1 min 551 ms)
0:02:23 [176/418/3] test_urllibnet skipped (resource denied) -- running: test_runpy (1 min 6 sec), test_subprocess (2 min 9 sec), test_io (1 min 5 sec), test_distutils (1 min 18 sec), test_venv (1 min 20 sec), test_zipfile (2 min 13 sec), test_asyncio (1 min 32 sec), test_multiprocessing_forkserver (1 min 1 sec)
test_urllibnet skipped -- Use of the 'network' resource not enabled
0:02:24 [177/418/3] test_winsound skipped (resource denied) -- running: test_runpy (1 min 7 sec), test_subprocess (2 min 9 sec), test_io (1 min 6 sec), test_distutils (1 min 19 sec), test_venv (1 min 21 sec), test_zipfile (2 min 14 sec), test_asyncio (1 min 32 sec), test_multiprocessing_forkserver (1 min 1 sec)
test_winsound skipped -- Use of the 'audio' resource not enabled
0:02:25 [178/418/3] test_userlist passed -- running: test_runpy (1 min 7 sec), test_subprocess (2 min 10 sec), test_io (1 min 6 sec), test_distutils (1 min 19 sec), test_venv (1 min 21 sec), test_zipfile (2 min 15 sec), test_asyncio (1 min 33 sec), test_multiprocessing_forkserver (1 min 2 sec)
0:02:25 [179/418/3] test_runpy passed (1 min 6 sec) -- running: test_subprocess (2 min 11 sec), test_io (1 min 7 sec), test_distutils (1 min 20 sec), test_venv (1 min 22 sec), test_zipfile (2 min 15 sec), test_asyncio (1 min 33 sec), test_multiprocessing_forkserver (1 min 2 sec)
0:02:25 [180/418/3] test_future3 passed -- running: test_subprocess (2 min 11 sec), test_io (1 min 7 sec), test_distutils (1 min 20 sec), test_venv (1 min 22 sec), test_zipfile (2 min 15 sec), test_asyncio (1 min 33 sec), test_multiprocessing_forkserver (1 min 3 sec)
0:02:25 [181/418/3] test_zipimport_support passed -- running: test_subprocess (2 min 11 sec), test_io (1 min 7 sec), test_distutils (1 min 20 sec), test_venv (1 min 22 sec), test_zipfile (2 min 15 sec), test_asyncio (1 min 33 sec), test_multiprocessing_forkserver (1 min 3 sec)
0:02:26 [182/418/3] test_repl passed -- running: test_subprocess (2 min 11 sec), test_io (1 min 8 sec), test_distutils (1 min 21 sec), test_venv (1 min 23 sec), test_zipfile (2 min 16 sec), test_asyncio (1 min 34 sec), test_multiprocessing_forkserver (1 min 3 sec)
0:02:27 [183/418/3] test_typechecks passed -- running: test_subprocess (2 min 12 sec), test_io (1 min 8 sec), test_distutils (1 min 21 sec), test_venv (1 min 23 sec), test_zipfile (2 min 17 sec), test_asyncio (1 min 35 sec), test_multiprocessing_forkserver (1 min 4 sec)
0:02:34 [184/418/3] test_index passed -- running: test_subprocess (2 min 19 sec), test_io (1 min 16 sec), test_distutils (1 min 29 sec), test_venv (1 min 30 sec), test_zipfile (2 min 24 sec), test_asyncio (1 min 42 sec), test_multiprocessing_forkserver (1 min 11 sec)
0:02:34 [185/418/3] test_xmlrpc passed -- running: test_subprocess (2 min 19 sec), test_io (1 min 16 sec), test_distutils (1 min 29 sec), test_venv (1 min 30 sec), test_zipfile (2 min 24 sec), test_asyncio (1 min 42 sec), test_multiprocessing_forkserver (1 min 11 sec)
0:02:36 [186/418/3] test_ioctl passed -- running: test_subprocess (2 min 21 sec), test_io (1 min 17 sec), test_distutils (1 min 30 sec), test_venv (1 min 32 sec), test_zipfile (2 min 26 sec), test_asyncio (1 min 44 sec), test_multiprocessing_forkserver (1 min 13 sec)
0:02:36 [187/418/3] test_array passed -- running: test_subprocess (2 min 21 sec), test_io (1 min 18 sec), test_distutils (1 min 31 sec), test_venv (1 min 33 sec), test_zipfile (2 min 26 sec), test_asyncio (1 min 44 sec), test_multiprocessing_forkserver (1 min 13 sec)
0:02:36 [188/418/3] test_xml_dom_minicompat passed -- running: test_subprocess (2 min 22 sec), test_io (1 min 18 sec), test_distutils (1 min 31 sec), test_venv (1 min 33 sec), test_zipfile (2 min 26 sec), test_asyncio (1 min 45 sec), test_multiprocessing_forkserver (1 min 14 sec)
0:02:37 [189/418/3] test_unary passed -- running: test_subprocess (2 min 22 sec), test_io (1 min 18 sec), test_distutils (1 min 31 sec), test_venv (1 min 33 sec), test_zipfile (2 min 27 sec), test_asyncio (1 min 45 sec), test_multiprocessing_forkserver (1 min 14 sec)
0:02:37 [190/418/3] test_sys_settrace passed -- running: test_subprocess (2 min 23 sec), test_io (1 min 19 sec), test_distutils (1 min 32 sec), test_venv (1 min 34 sec), test_zipfile (2 min 27 sec), test_asyncio (1 min 46 sec), test_multiprocessing_forkserver (1 min 15 sec)
0:02:38 [191/418/3] test_dict_version passed -- running: test_subprocess (2 min 24 sec), test_io (1 min 20 sec), test_distutils (1 min 33 sec), test_venv (1 min 35 sec), test_zipfile (2 min 28 sec), test_asyncio (1 min 46 sec), test_multiprocessing_forkserver (1 min 16 sec)
0:02:38 [192/418/3] test_io passed (1 min 19 sec) -- running: test_subprocess (2 min 24 sec), test_distutils (1 min 33 sec), test_venv (1 min 35 sec), test_zipfile (2 min 28 sec), test_asyncio (1 min 46 sec), test_multiprocessing_forkserver (1 min 16 sec)
0:02:39 [193/418/3] test_locale passed -- running: test_subprocess (2 min 24 sec), test_distutils (1 min 34 sec), test_venv (1 min 36 sec), test_zipfile (2 min 29 sec), test_asyncio (1 min 47 sec), test_multiprocessing_forkserver (1 min 16 sec)
0:02:40 [194/418/3] test_hash passed -- running: test_subprocess (2 min 25 sec), test_distutils (1 min 35 sec), test_venv (1 min 37 sec), test_zipfile (2 min 30 sec), test_asyncio (1 min 48 sec), test_multiprocessing_forkserver (1 min 17 sec)
0:02:41 [195/418/3] test_keyword passed -- running: test_subprocess (2 min 27 sec), test_distutils (1 min 36 sec), test_venv (1 min 38 sec), test_zipfile (2 min 31 sec), test_asyncio (1 min 49 sec), test_multiprocessing_forkserver (1 min 19 sec)
0:02:42 [196/418/3] test_zipfile passed (2 min 27 sec) -- running: test_subprocess (2 min 27 sec), test_distutils (1 min 37 sec), test_venv (1 min 38 sec), test_asyncio (1 min 50 sec), test_multiprocessing_forkserver (1 min 19 sec)
0:02:43 [197/418/3] test_code_module passed -- running: test_subprocess (2 min 28 sec), test_distutils (1 min 38 sec), test_venv (1 min 40 sec), test_asyncio (1 min 51 sec), test_multiprocessing_forkserver (1 min 20 sec)
0:02:44 [198/418/3] test_fileinput passed -- running: test_subprocess (2 min 29 sec), test_distutils (1 min 39 sec), test_venv (1 min 41 sec), test_asyncio (1 min 52 sec), test_multiprocessing_forkserver (1 min 21 sec)
0:02:44 [199/418/3] test_readline skipped -- running: test_subprocess (2 min 30 sec), test_distutils (1 min 39 sec), test_venv (1 min 41 sec), test_asyncio (1 min 53 sec), test_multiprocessing_forkserver (1 min 22 sec)
test_readline skipped -- No module named 'readline'
0:02:45 [200/418/4] test_distutils failed -- running: test_subprocess (2 min 30 sec), test_venv (1 min 41 sec), test_asyncio (1 min 53 sec), test_multiprocessing_forkserver (1 min 22 sec)
xlc_r: 1501-218 (S) file _configtest.i contains an incorrect file suffix
test test_distutils failed -- multiple errors occurred; run in verbose mode for details
0:02:45 [201/418/4] test_syslog passed -- running: test_subprocess (2 min 31 sec), test_venv (1 min 42 sec), test_asyncio (1 min 53 sec), test_multiprocessing_forkserver (1 min 23 sec)
0:02:47 [202/418/4] test_pkgutil passed -- running: test_subprocess (2 min 32 sec), test_venv (1 min 43 sec), test_asyncio (1 min 55 sec), test_multiprocessing_forkserver (1 min 24 sec)
0:02:48 [203/418/4] test_codecencodings_tw passed -- running: test_subprocess (2 min 33 sec), test_venv (1 min 44 sec), test_asyncio (1 min 56 sec), test_multiprocessing_forkserver (1 min 25 sec)
0:02:49 [204/418/4] test_numeric_tower passed -- running: test_subprocess (2 min 34 sec), test_venv (1 min 45 sec), test_asyncio (1 min 57 sec), test_multiprocessing_forkserver (1 min 26 sec)
0:02:53 [205/418/4] test_unicode passed -- running: test_subprocess (2 min 39 sec), test_venv (1 min 50 sec), test_asyncio (2 min 1 sec), test_multiprocessing_forkserver (1 min 31 sec)
0:02:56 [206/418/4] test_tempfile passed -- running: test_subprocess (2 min 41 sec), test_venv (1 min 52 sec), test_asyncio (2 min 4 sec), test_multiprocessing_forkserver (1 min 33 sec), test_importlib (30 sec 575 ms)
0:02:56 [207/418/4] test_fileio passed -- running: test_subprocess (2 min 42 sec), test_venv (1 min 53 sec), test_asyncio (2 min 5 sec), test_multiprocessing_forkserver (1 min 34 sec), test_importlib (31 sec 298 ms)
0:03:00 [208/418/4] test_pickletools passed -- running: test_subprocess (2 min 45 sec), test_venv (1 min 56 sec), test_asyncio (2 min 8 sec), test_multiprocessing_forkserver (1 min 37 sec), test_importlib (34 sec 399 ms)
0:03:00 [209/418/5] test_asyncio failed -- running: test_subprocess (2 min 46 sec), test_venv (1 min 57 sec), test_multiprocessing_forkserver (1 min 38 sec), test_importlib (35 sec 6 ms)
test test_asyncio failed -- multiple errors occurred; run in verbose mode for details
0:03:01 [210/418/5] test_subclassinit passed -- running: test_subprocess (2 min 46 sec), test_venv (1 min 58 sec), test_multiprocessing_forkserver (1 min 38 sec), test_importlib (35 sec 696 ms)
0:03:01 [211/418/5] test_tcl skipped -- running: test_subprocess (2 min 47 sec), test_venv (1 min 58 sec), test_multiprocessing_forkserver (1 min 39 sec), test_importlib (36 sec 210 ms)
test_tcl skipped -- No module named '_tkinter'
0:03:02 [212/418/5] test_shutil passed -- running: test_subprocess (2 min 47 sec), test_venv (1 min 59 sec), test_multiprocessing_forkserver (1 min 39 sec), test_importlib (36 sec 843 ms)
0:03:05 [213/418/5] test_descr passed -- running: test_subprocess (2 min 51 sec), test_venv (2 min 2 sec), test_multiprocessing_forkserver (1 min 43 sec), test_importlib (40 sec 10 ms)
0:03:06 [214/418/5] test_ucn passed -- running: test_subprocess (2 min 52 sec), test_venv (2 min 3 sec), test_multiprocessing_forkserver (1 min 44 sec), test_importlib (41 sec 257 ms)
0:03:09 [215/418/5] test_importlib passed (42 sec 683 ms) -- running: test_subprocess (2 min 54 sec), test_venv (2 min 5 sec), test_multiprocessing_forkserver (1 min 46 sec)
0:03:09 [216/418/5] test_compare passed -- running: test_subprocess (2 min 55 sec), test_venv (2 min 6 sec), test_multiprocessing_forkserver (1 min 47 sec)
0:03:10 [217/418/5] test___all__ passed -- running: test_subprocess (2 min 55 sec), test_venv (2 min 6 sec), test_multiprocessing_forkserver (1 min 47 sec)
0:03:10 [218/418/5] test_syntax passed -- running: test_subprocess (2 min 55 sec), test_venv (2 min 7 sec), test_multiprocessing_forkserver (1 min 47 sec)
0:03:10 [219/418/5] test_keywordonlyarg passed -- running: test_subprocess (2 min 55 sec), test_venv (2 min 7 sec), test_multiprocessing_forkserver (1 min 47 sec)
0:03:10 [220/418/5] test_future5 passed -- running: test_subprocess (2 min 56 sec), test_venv (2 min 7 sec), test_multiprocessing_forkserver (1 min 48 sec)
0:03:11 [221/418/5] test_smtpd passed -- running: test_subprocess (2 min 56 sec), test_venv (2 min 8 sec), test_multiprocessing_forkserver (1 min 48 sec)
0:03:11 [222/418/5] test_mimetypes passed -- running: test_subprocess (2 min 56 sec), test_venv (2 min 8 sec), test_multiprocessing_forkserver (1 min 48 sec)
0:03:11 [223/418/5] test_csv passed -- running: test_subprocess (2 min 57 sec), test_venv (2 min 8 sec), test_multiprocessing_forkserver (1 min 49 sec)
0:03:12 [224/418/5] test_sndhdr passed -- running: test_subprocess (2 min 57 sec), test_venv (2 min 9 sec), test_multiprocessing_forkserver (1 min 49 sec)
0:03:12 [225/418/5] test_fnmatch passed -- running: test_subprocess (2 min 57 sec), test_venv (2 min 9 sec), test_multiprocessing_forkserver (1 min 49 sec)
0:03:12 [226/418/5] test_html passed -- running: test_subprocess (2 min 58 sec), test_venv (2 min 9 sec), test_multiprocessing_forkserver (1 min 50 sec)
0:03:13 [227/418/5] test_signal passed -- running: test_subprocess (2 min 58 sec), test_venv (2 min 9 sec), test_multiprocessing_forkserver (1 min 50 sec)
0:03:13 [228/418/5] test_doctest2 passed -- running: test_subprocess (2 min 58 sec), test_venv (2 min 10 sec), test_multiprocessing_forkserver (1 min 50 sec)
0:03:13 [229/418/5] test_print passed -- running: test_cmd_line_script (30 sec 78 ms), test_subprocess (2 min 59 sec), test_venv (2 min 10 sec), test_multiprocessing_forkserver (1 min 51 sec)
0:03:13 [230/418/5] test_thread passed -- running: test_cmd_line_script (30 sec 223 ms), test_subprocess (2 min 59 sec), test_venv (2 min 10 sec), test_multiprocessing_forkserver (1 min 51 sec)
0:03:14 [231/418/5] test_tuple passed -- running: test_cmd_line_script (30 sec 441 ms), test_subprocess (2 min 59 sec), test_venv (2 min 10 sec), test_multiprocessing_forkserver (1 min 51 sec)
0:03:14 [232/418/5] test_errno passed -- running: test_cmd_line_script (30 sec 804 ms), test_subprocess (2 min 59 sec), test_venv (2 min 11 sec), test_multiprocessing_forkserver (1 min 51 sec)
0:03:14 [233/418/5] test_ttk_guionly skipped -- running: test_cmd_line_script (31 sec 370 ms), test_subprocess (3 min 364 ms), test_venv (2 min 11 sec), test_multiprocessing_forkserver (1 min 52 sec)
test_ttk_guionly skipped -- No module named '_tkinter'
0:03:15 [234/418/5] test_contextlib_async passed -- running: test_cmd_line_script (31 sec 968 ms), test_subprocess (3 min 962 ms), test_venv (2 min 12 sec), test_multiprocessing_forkserver (1 min 52 sec)
0:03:15 [235/418/5] test_int_literal passed -- running: test_cmd_line_script (32 sec 412 ms), test_subprocess (3 min 1 sec), test_venv (2 min 12 sec), test_multiprocessing_forkserver (1 min 53 sec)
0:03:17 [236/418/5] test_deque passed -- running: test_cmd_line_script (33 sec 955 ms), test_subprocess (3 min 2 sec), test_venv (2 min 14 sec), test_multiprocessing_forkserver (1 min 54 sec)
0:03:17 [237/418/5] test_pwd passed -- running: test_cmd_line_script (34 sec 362 ms), test_subprocess (3 min 3 sec), test_venv (2 min 14 sec), test_multiprocessing_forkserver (1 min 55 sec)
0:03:20 [238/418/5] test_wait3 passed -- running: test_cmd_line_script (36 sec 933 ms), test_subprocess (3 min 5 sec), test_venv (2 min 17 sec), test_multiprocessing_forkserver (1 min 57 sec)
0:03:20 [239/418/5] test_hashlib passed -- running: test_cmd_line_script (37 sec 169 ms), test_subprocess (3 min 6 sec), test_venv (2 min 17 sec), test_multiprocessing_forkserver (1 min 58 sec)
0:03:20 [240/418/5] test_super passed -- running: test_cmd_line_script (37 sec 390 ms), test_subprocess (3 min 6 sec), test_venv (2 min 17 sec), test_multiprocessing_forkserver (1 min 58 sec)
0:03:21 [241/418/5] test_yield_from passed -- running: test_cmd_line_script (37 sec 702 ms), test_subprocess (3 min 6 sec), test_venv (2 min 18 sec), test_multiprocessing_forkserver (1 min 58 sec)
0:03:21 [242/418/5] test_timeout skipped (resource denied) -- running: test_cmd_line_script (37 sec 787 ms), test_subprocess (3 min 6 sec), test_venv (2 min 18 sec), test_multiprocessing_forkserver (1 min 58 sec)
test_timeout skipped -- Use of the 'network' resource not enabled
0:03:26 [243/418/5] test_ensurepip passed -- running: test_cmd_line_script (42 sec 965 ms), test_subprocess (3 min 11 sec), test_venv (2 min 23 sec), test_multiprocessing_forkserver (2 min 3 sec)
0:03:34 [244/418/6] test_ctypes failed -- running: test_cmd_line_script (51 sec 267 ms), test_subprocess (3 min 20 sec), test_venv (2 min 31 sec), test_regrtest (37 sec 912 ms), test_ssl (32 sec 992 ms), test_multiprocessing_forkserver (2 min 12 sec)
test test_ctypes failed -- multiple errors occurred; run in verbose mode for details
0:03:34 [245/418/6] test_cmd_line_script passed (50 sec 734 ms) -- running: test_subprocess (3 min 20 sec), test_venv (2 min 31 sec), test_regrtest (38 sec 60 ms), test_ssl (33 sec 140 ms), test_multiprocessing_forkserver (2 min 12 sec)
0:03:35 [246/418/6] test_frozen passed -- running: test_subprocess (3 min 21 sec), test_venv (2 min 32 sec), test_regrtest (38 sec 699 ms), test_ssl (33 sec 779 ms), test_multiprocessing_forkserver (2 min 12 sec)
0:03:35 [247/418/6] test_weakset passed -- running: test_subprocess (3 min 21 sec), test_venv (2 min 32 sec), test_regrtest (38 sec 834 ms), test_ssl (33 sec 914 ms), test_multiprocessing_forkserver (2 min 13 sec)
0:03:36 [248/418/6] test_threading passed -- running: test_subprocess (3 min 21 sec), test_venv (2 min 32 sec), test_regrtest (39 sec 248 ms), test_ssl (34 sec 328 ms), test_multiprocessing_forkserver (2 min 13 sec)
0:03:36 [249/418/6] test_codecmaps_tw passed -- running: test_subprocess (3 min 21 sec), test_venv (2 min 33 sec), test_regrtest (39 sec 494 ms), test_ssl (34 sec 574 ms), test_multiprocessing_forkserver (2 min 13 sec)
0:03:36 [250/418/6] test_exception_variations passed -- running: test_subprocess (3 min 21 sec), test_venv (2 min 33 sec), test_regrtest (39 sec 495 ms), test_ssl (34 sec 575 ms), test_multiprocessing_forkserver (2 min 13 sec)
0:03:36 [251/418/7] test__xxsubinterpreters failed -- running: test_subprocess (3 min 22 sec), test_venv (2 min 33 sec), test_regrtest (39 sec 811 ms), test_ssl (34 sec 891 ms), test_multiprocessing_forkserver (2 min 14 sec)
test test__xxsubinterpreters failed -- Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test__xxsubinterpreters.py", line 370, in _assert_values
    self.assertEqual(got, obj)
AssertionError: 4294967295 != -1
0:03:37 [252/418/7] test_largefile passed -- running: test_subprocess (3 min 22 sec), test_venv (2 min 33 sec), test_regrtest (40 sec 218 ms), test_ssl (35 sec 298 ms), test_multiprocessing_forkserver (2 min 14 sec)
0:03:37 [253/418/7] test_utf8source passed -- running: test_subprocess (3 min 22 sec), test_venv (2 min 34 sec), test_regrtest (40 sec 386 ms), test_ssl (35 sec 466 ms), test_multiprocessing_forkserver (2 min 14 sec)
0:03:37 [254/418/7] test_structseq passed -- running: test_subprocess (3 min 23 sec), test_venv (2 min 34 sec), test_regrtest (40 sec 689 ms), test_ssl (35 sec 768 ms), test_multiprocessing_forkserver (2 min 14 sec)
0:03:38 [255/418/7] test_float passed -- running: test_subprocess (3 min 23 sec), test_venv (2 min 35 sec), test_regrtest (41 sec 500 ms), test_ssl (36 sec 580 ms), test_multiprocessing_forkserver (2 min 15 sec)
0:03:39 [256/418/7] test_complex passed -- running: test_subprocess (3 min 25 sec), test_venv (2 min 36 sec), test_regrtest (42 sec 765 ms), test_ssl (37 sec 845 ms), test_multiprocessing_forkserver (2 min 17 sec)
0:03:40 [257/418/7] test_tabnanny passed -- running: test_subprocess (3 min 25 sec), test_venv (2 min 36 sec), test_regrtest (43 sec 161 ms), test_ssl (38 sec 241 ms), test_multiprocessing_forkserver (2 min 17 sec)
0:03:40 [258/418/7] test_tk skipped -- running: test_subprocess (3 min 25 sec), test_venv (2 min 37 sec), test_regrtest (43 sec 331 ms), test_ssl (38 sec 411 ms), test_multiprocessing_forkserver (2 min 17 sec)
test_tk skipped -- No module named '_tkinter'
0:03:41 [259/418/7] test_colorsys passed -- running: test_subprocess (3 min 26 sec), test_venv (2 min 37 sec), test_regrtest (44 sec 90 ms), test_ssl (39 sec 169 ms), test_multiprocessing_forkserver (2 min 18 sec)
0:03:41 [260/418/7] test_htmlparser passed -- running: test_subprocess (3 min 26 sec), test_venv (2 min 37 sec), test_regrtest (44 sec 166 ms), test_ssl (39 sec 246 ms), test_multiprocessing_forkserver (2 min 18 sec)
0:03:41 [261/418/7] test_sysconfig passed -- running: test_subprocess (3 min 27 sec), test_venv (2 min 38 sec), test_regrtest (45 sec 15 ms), test_ssl (40 sec 95 ms), test_multiprocessing_forkserver (2 min 19 sec)
0:03:42 [262/418/7] test_quopri passed -- running: test_subprocess (3 min 27 sec), test_venv (2 min 38 sec), test_regrtest (45 sec 82 ms), test_ssl (40 sec 162 ms), test_multiprocessing_forkserver (2 min 19 sec)
0:03:42 [263/418/7] test_future4 passed -- running: test_subprocess (3 min 27 sec), test_venv (2 min 39 sec), test_regrtest (45 sec 621 ms), test_ssl (40 sec 701 ms), test_multiprocessing_forkserver (2 min 19 sec)
0:03:43 [264/418/7] test_augassign passed -- running: test_subprocess (3 min 28 sec), test_venv (2 min 39 sec), test_regrtest (46 sec 113 ms), test_ssl (41 sec 193 ms), test_multiprocessing_forkserver (2 min 20 sec)
0:03:43 [265/418/7] test_platform passed -- running: test_subprocess (3 min 28 sec), test_venv (2 min 40 sec), test_regrtest (46 sec 612 ms), test_ssl (41 sec 692 ms), test_multiprocessing_forkserver (2 min 20 sec)
0:03:43 [266/418/7] test_operator passed -- running: test_subprocess (3 min 29 sec), test_venv (2 min 40 sec), test_regrtest (46 sec 680 ms), test_ssl (41 sec 760 ms), test_multiprocessing_forkserver (2 min 20 sec)
0:03:44 [267/418/7] test_descrtut passed -- running: test_subprocess (3 min 29 sec), test_venv (2 min 41 sec), test_regrtest (47 sec 351 ms), test_ssl (42 sec 431 ms), test_multiprocessing_forkserver (2 min 21 sec)
0:03:44 [268/418/7] test_memoryview passed -- running: test_subprocess (3 min 29 sec), test_venv (2 min 41 sec), test_regrtest (47 sec 479 ms), test_ssl (42 sec 559 ms), test_multiprocessing_forkserver (2 min 21 sec)
0:03:47 [269/418/7] test_eintr passed -- running: test_subprocess (3 min 32 sec), test_venv (2 min 44 sec), test_regrtest (50 sec 446 ms), test_ssl (45 sec 525 ms), test_multiprocessing_forkserver (2 min 24 sec)
0:03:48 [270/418/7] test_cmath passed -- running: test_subprocess (3 min 33 sec), test_venv (2 min 45 sec), test_regrtest (51 sec 507 ms), test_ssl (46 sec 587 ms), test_multiprocessing_forkserver (2 min 25 sec)
0:03:56 [271/418/7] test_modulefinder passed -- running: test_subprocess (3 min 41 sec), test_venv (2 min 53 sec), test_regrtest (59 sec 463 ms), test_ssl (54 sec 542 ms), test_multiprocessing_forkserver (2 min 33 sec), test_tools (35 sec 122 ms)
0:03:59 [272/418/7] test_tools passed (37 sec 324 ms) -- running: test_subprocess (3 min 44 sec), test_venv (2 min 55 sec), test_regrtest (1 min 2 sec), test_ssl (57 sec 321 ms), test_multiprocessing_forkserver (2 min 36 sec)
0:04:00 [273/418/7] test__osx_support passed -- running: test_subprocess (3 min 45 sec), test_venv (2 min 56 sec), test_regrtest (1 min 3 sec), test_ssl (58 sec 235 ms), test_multiprocessing_forkserver (2 min 37 sec)
0:04:01 [274/418/7] test_spwd skipped -- running: test_subprocess (3 min 46 sec), test_venv (2 min 57 sec), test_regrtest (1 min 4 sec), test_ssl (59 sec 154 ms), test_multiprocessing_forkserver (2 min 38 sec)
test_spwd skipped -- No module named 'spwd'
0:04:02 [275/418/7] test_urllib2net skipped (resource denied) -- running: test_subprocess (3 min 47 sec), test_venv (2 min 58 sec), test_regrtest (1 min 5 sec), test_ssl (1 min 288 ms), test_multiprocessing_forkserver (2 min 39 sec)
test_urllib2net skipped -- Use of the 'network' resource not enabled
0:04:03 [276/418/7] test_lltrace passed -- running: test_subprocess (3 min 49 sec), test_venv (3 min 419 ms), test_regrtest (1 min 6 sec), test_ssl (1 min 1 sec), test_multiprocessing_forkserver (2 min 40 sec)
0:04:04 [277/418/7] test_nis passed -- running: test_subprocess (3 min 50 sec), test_venv (3 min 1 sec), test_regrtest (1 min 7 sec), test_ssl (1 min 2 sec), test_multiprocessing_forkserver (2 min 42 sec)
0:04:08 [278/418/8] test_socket failed -- running: test_subprocess (3 min 53 sec), test_venv (3 min 4 sec), test_regrtest (1 min 11 sec), test_ssl (1 min 6 sec), test_multiprocessing_forkserver (2 min 45 sec)
/data/prj/python/git/python3-3.8/Lib/test/test_socket.py:2345: RuntimeWarning: received malformed or improperly-truncated ancillary data
  result = sock.recvmsg(bufsize, *args)
/data/prj/python/git/python3-3.8/Lib/test/test_socket.py:2436: RuntimeWarning: received malformed or improperly-truncated ancillary data
  result = sock.recvmsg_into([buf], *args)
test test_socket failed -- multiple errors occurred; run in verbose mode for details
0:04:12 [279/418/8] test_py_compile passed -- running: test_subprocess (3 min 57 sec), test_venv (3 min 9 sec), test_regrtest (1 min 15 sec), test_ssl (1 min 10 sec), test_multiprocessing_forkserver (2 min 49 sec)
0:04:13 [280/418/8] test_atexit passed -- running: test_subprocess (3 min 59 sec), test_venv (3 min 10 sec), test_regrtest (1 min 16 sec), test_ssl (1 min 11 sec), test_multiprocessing_forkserver (2 min 50 sec)
0:04:15 [281/418/8] test_sunau passed -- running: test_buffer (31 sec 597 ms), test_subprocess (4 min 1 sec), test_lib2to3 (31 sec 470 ms), test_venv (3 min 12 sec), test_regrtest (1 min 18 sec), test_ssl (1 min 14 sec), test_multiprocessing_forkserver (2 min 53 sec)
0:04:17 [282/418/8] test_regrtest passed (1 min 20 sec) -- running: test_buffer (33 sec 698 ms), test_subprocess (4 min 3 sec), test_lib2to3 (33 sec 571 ms), test_venv (3 min 14 sec), test_ssl (1 min 16 sec), test_multiprocessing_forkserver (2 min 55 sec)
0:04:19 [283/418/8] test_mmap passed -- running: test_buffer (35 sec 314 ms), test_subprocess (4 min 5 sec), test_lib2to3 (35 sec 187 ms), test_venv (3 min 16 sec), test_ssl (1 min 17 sec), test_multiprocessing_forkserver (2 min 56 sec)
0:04:20 [284/418/8] test_getpass passed -- running: test_buffer (36 sec 239 ms), test_subprocess (4 min 5 sec), test_lib2to3 (36 sec 113 ms), test_venv (3 min 17 sec), test_ssl (1 min 18 sec), test_multiprocessing_forkserver (2 min 57 sec)
0:04:21 [285/418/8] test_buffer passed (36 sec 372 ms) -- running: test_subprocess (4 min 6 sec), test_lib2to3 (36 sec 910 ms), test_venv (3 min 18 sec), test_ssl (1 min 19 sec), test_multiprocessing_forkserver (2 min 58 sec)
0:04:23 [286/418/8] test_threading_local passed -- running: test_subprocess (4 min 8 sec), test_lib2to3 (38 sec 917 ms), test_venv (3 min 20 sec), test_ssl (1 min 21 sec), test_multiprocessing_forkserver (3 min 680 ms)
0:04:24 [287/418/8] test_with passed -- running: test_subprocess (4 min 9 sec), test_lib2to3 (39 sec 593 ms), test_venv (3 min 20 sec), test_ssl (1 min 22 sec), test_multiprocessing_forkserver (3 min 1 sec)
0:04:24 [288/418/8] test_call passed -- running: test_subprocess (4 min 10 sec), test_lib2to3 (40 sec 539 ms), test_venv (3 min 21 sec), test_ssl (1 min 23 sec), test_multiprocessing_forkserver (3 min 2 sec)
0:04:28 [289/418/8] test_ssl passed (1 min 25 sec) -- running: test_subprocess (4 min 13 sec), test_lib2to3 (44 sec 51 ms), test_multiprocessing_main_handling (32 sec 79 ms), test_venv (3 min 25 sec), test_multiprocessing_forkserver (3 min 5 sec)
0:04:28 [290/418/8] test_threadsignals passed -- running: test_subprocess (4 min 14 sec), test_lib2to3 (44 sec 299 ms), test_multiprocessing_main_handling (32 sec 328 ms), test_venv (3 min 25 sec), test_multiprocessing_forkserver (3 min 6 sec)
0:04:29 [291/418/8] test_fractions passed -- running: test_subprocess (4 min 14 sec), test_lib2to3 (44 sec 767 ms), test_multiprocessing_main_handling (32 sec 796 ms), test_venv (3 min 25 sec), test_multiprocessing_forkserver (3 min 6 sec)
0:04:29 [292/418/8] test_lzma skipped -- running: test_subprocess (4 min 15 sec), test_lib2to3 (45 sec 348 ms), test_multiprocessing_main_handling (33 sec 376 ms), test_venv (3 min 26 sec), test_multiprocessing_forkserver (3 min 7 sec)
test_lzma skipped -- No module named '_lzma'
0:04:30 [293/418/8] test_math passed -- running: test_subprocess (4 min 16 sec), test_lib2to3 (46 sec 507 ms), test_multiprocessing_main_handling (34 sec 536 ms), test_venv (3 min 27 sec), test_multiprocessing_forkserver (3 min 8 sec)
0:04:32 [294/418/8] test_zipimport passed -- running: test_subprocess (4 min 18 sec), test_lib2to3 (48 sec 273 ms), test_multiprocessing_main_handling (36 sec 301 ms), test_venv (3 min 29 sec), test_multiprocessing_forkserver (3 min 10 sec)
0:04:33 [295/418/8] test_xxtestfuzz passed -- running: test_subprocess (4 min 18 sec), test_lib2to3 (49 sec 171 ms), test_multiprocessing_main_handling (37 sec 199 ms), test_venv (3 min 30 sec), test_multiprocessing_forkserver (3 min 10 sec)
0:04:36 [296/418/8] test_ast passed -- running: test_subprocess (4 min 22 sec), test_lib2to3 (52 sec 208 ms), test_multiprocessing_main_handling (40 sec 236 ms), test_venv (3 min 33 sec), test_multiprocessing_forkserver (3 min 13 sec), test_compileall (31 sec 973 ms)
0:04:38 [297/418/8] test_sys passed -- running: test_subprocess (4 min 23 sec), test_lib2to3 (53 sec 982 ms), test_multiprocessing_main_handling (42 sec 10 ms), test_venv (3 min 35 sec), test_multiprocessing_forkserver (3 min 15 sec), test_compileall (33 sec 747 ms)
0:04:57 [298/418/8] test_unicodedata passed -- running: test_subprocess (4 min 43 sec), test_lib2to3 (1 min 13 sec), test_multiprocessing_main_handling (1 min 1 sec), test_venv (3 min 54 sec), test_logging (37 sec 146 ms), test_multiprocessing_forkserver (3 min 35 sec), test_compileall (53 sec 16 ms)
0:04:57 [299/418/8] test_asynchat passed -- running: test_subprocess (4 min 43 sec), test_lib2to3 (1 min 13 sec), test_multiprocessing_main_handling (1 min 1 sec), test_venv (3 min 54 sec), test_logging (37 sec 149 ms), test_multiprocessing_forkserver (3 min 35 sec), test_compileall (53 sec 19 ms)
0:05:01 [300/418/8] test_bufio passed -- running: test_subprocess (4 min 47 sec), test_lib2to3 (1 min 17 sec), test_multiprocessing_main_handling (1 min 5 sec), test_venv (3 min 58 sec), test_logging (41 sec 147 ms), test_multiprocessing_forkserver (3 min 39 sec), test_compileall (57 sec 17 ms)
0:05:12 [301/418/8] test_string passed -- running: test_subprocess (4 min 57 sec), test_lib2to3 (1 min 27 sec), test_multiprocessing_main_handling (1 min 15 sec), test_venv (4 min 9 sec), test_logging (51 sec 756 ms), test_multiprocessing_forkserver (3 min 49 sec), test_compileall (1 min 7 sec)
0:05:12 [302/418/8] test_codeccallbacks passed -- running: test_subprocess (4 min 58 sec), test_lib2to3 (1 min 28 sec), test_multiprocessing_main_handling (1 min 16 sec), test_venv (4 min 9 sec), test_logging (52 sec 80 ms), test_multiprocessing_forkserver (3 min 49 sec), test_compileall (1 min 7 sec)
0:05:13 [303/418/8] test_contains passed -- running: test_subprocess (4 min 59 sec), test_lib2to3 (1 min 29 sec), test_multiprocessing_main_handling (1 min 17 sec), test_venv (4 min 10 sec), test_logging (53 sec 258 ms), test_multiprocessing_forkserver (3 min 51 sec), test_compileall (1 min 9 sec)
0:05:13 [304/418/8] test_imp passed -- running: test_subprocess (4 min 59 sec), test_lib2to3 (1 min 29 sec), test_multiprocessing_main_handling (1 min 17 sec), test_venv (4 min 10 sec), test_logging (53 sec 322 ms), test_multiprocessing_forkserver (3 min 51 sec), test_compileall (1 min 9 sec)
0:05:15 [305/418/8] test_genericclass passed -- running: test_subprocess (5 min 508 ms), test_lib2to3 (1 min 30 sec), test_multiprocessing_main_handling (1 min 18 sec), test_venv (4 min 11 sec), test_logging (54 sec 578 ms), test_multiprocessing_forkserver (3 min 52 sec), test_compileall (1 min 10 sec)
0:05:19 [306/418/8] test_random passed -- running: test_subprocess (5 min 4 sec), test_lib2to3 (1 min 34 sec), test_multiprocessing_main_handling (1 min 22 sec), test_venv (4 min 15 sec), test_logging (58 sec 602 ms), test_multiprocessing_forkserver (3 min 56 sec), test_compileall (1 min 14 sec)
0:05:19 [307/418/8] test__opcode passed -- running: test_subprocess (5 min 5 sec), test_lib2to3 (1 min 35 sec), test_multiprocessing_main_handling (1 min 23 sec), test_venv (4 min 16 sec), test_logging (59 sec 123 ms), test_multiprocessing_forkserver (3 min 56 sec), test_compileall (1 min 14 sec)
0:05:20 [308/418/8] test_listcomps passed -- running: test_subprocess (5 min 5 sec), test_lib2to3 (1 min 35 sec), test_multiprocessing_main_handling (1 min 23 sec), test_venv (4 min 16 sec), test_logging (59 sec 595 ms), test_multiprocessing_forkserver (3 min 57 sec), test_compileall (1 min 15 sec)
0:05:20 [309/418/8] test_genexps passed -- running: test_subprocess (5 min 6 sec), test_lib2to3 (1 min 36 sec), test_multiprocessing_main_handling (1 min 24 sec), test_venv (4 min 17 sec), test_logging (1 min 103 ms), test_multiprocessing_forkserver (3 min 57 sec), test_compileall (1 min 15 sec)
0:05:21 [310/418/8] test_decorators passed -- running: test_subprocess (5 min 6 sec), test_lib2to3 (1 min 36 sec), test_multiprocessing_main_handling (1 min 24 sec), test_venv (4 min 17 sec), test_logging (1 min 543 ms), test_multiprocessing_forkserver (3 min 58 sec), test_compileall (1 min 16 sec)
0:05:28 [311/418/8] test_queue passed -- running: test_subprocess (5 min 13 sec), test_lib2to3 (1 min 44 sec), test_multiprocessing_main_handling (1 min 32 sec), test_venv (4 min 25 sec), test_logging (1 min 7 sec), test_multiprocessing_forkserver (4 min 5 sec), test_compileall (1 min 23 sec)
0:05:28 [312/418/8] test_long passed -- running: test_subprocess (5 min 13 sec), test_lib2to3 (1 min 44 sec), test_multiprocessing_main_handling (1 min 32 sec), test_venv (4 min 25 sec), test_logging (1 min 8 sec), test_multiprocessing_forkserver (4 min 5 sec), test_compileall (1 min 23 sec)
0:05:29 [313/418/8] test_dbm_ndbm passed -- running: test_subprocess (5 min 14 sec), test_lib2to3 (1 min 44 sec), test_multiprocessing_main_handling (1 min 32 sec), test_venv (4 min 26 sec), test_logging (1 min 8 sec), test_multiprocessing_forkserver (4 min 6 sec), test_compileall (1 min 24 sec)
0:05:29 [314/418/8] test_base64 passed -- running: test_subprocess (5 min 15 sec), test_lib2to3 (1 min 45 sec), test_multiprocessing_main_handling (1 min 33 sec), test_venv (4 min 26 sec), test_logging (1 min 9 sec), test_multiprocessing_forkserver (4 min 7 sec), test_compileall (1 min 25 sec)
running: test_pickle (46 sec 758 ms), test_subprocess (5 min 54 sec), test_pkgimport (39 sec 421 ms), test_lib2to3 (2 min 24 sec), test_multiprocessing_main_handling (2 min 12 sec), test_venv (5 min 5 sec), test_logging (1 min 48 sec), test_os (39 sec 856 ms), test_multiprocessing_forkserver (4 min 46 sec), test_compileall (2 min 4 sec)
0:06:10 [315/418/8] test_pickle passed (42 sec 812 ms) -- running: test_subprocess (5 min 56 sec), test_pkgimport (41 sec 26 ms), test_lib2to3 (2 min 26 sec), test_multiprocessing_main_handling (2 min 14 sec), test_venv (5 min 7 sec), test_logging (1 min 50 sec), test_os (41 sec 461 ms), test_multiprocessing_forkserver (4 min 48 sec), test_compileall (2 min 6 sec)
0:06:16 [316/418/9] test_os failed -- running: test_subprocess (6 min 2 sec), test_pkgimport (47 sec 216 ms), test_lib2to3 (2 min 32 sec), test_multiprocessing_main_handling (2 min 20 sec), test_venv (5 min 13 sec), test_logging (1 min 56 sec), test_multiprocessing_forkserver (4 min 54 sec), test_compileall (2 min 12 sec)
test test_os failed -- Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test_os.py", line 1118, in test_mode
    self.assertEqual(stat.S_IMODE(os.stat(path).st_mode), 0o555)
AssertionError: 1389 != 365
0:06:22 [317/418/9] test_urlparse passed -- running: test_subprocess (6 min 7 sec), test_lib2to3 (2 min 37 sec), test_multiprocessing_main_handling (2 min 25 sec), test_venv (5 min 18 sec), test_logging (2 min 1 sec), test_multiprocessing_forkserver (4 min 59 sec), test_compileall (2 min 17 sec)
0:06:22 [318/418/9] test_pkgimport passed (46 sec 924 ms) -- running: test_subprocess (6 min 7 sec), test_lib2to3 (2 min 37 sec), test_multiprocessing_main_handling (2 min 25 sec), test_venv (5 min 18 sec), test_logging (2 min 1 sec), test_multiprocessing_forkserver (4 min 59 sec), test_compileall (2 min 17 sec)
0:06:22 [319/418/9] test_exception_hierarchy passed -- running: test_subprocess (6 min 7 sec), test_lib2to3 (2 min 37 sec), test_multiprocessing_main_handling (2 min 25 sec), test_venv (5 min 18 sec), test_logging (2 min 1 sec), test_multiprocessing_forkserver (4 min 59 sec), test_compileall (2 min 17 sec)
0:06:23 [320/418/9] test_dummy_thread passed -- running: test_subprocess (6 min 8 sec), test_lib2to3 (2 min 38 sec), test_multiprocessing_main_handling (2 min 26 sec), test_venv (5 min 19 sec), test_logging (2 min 2 sec), test_multiprocessing_forkserver (5 min 473 ms), test_compileall (2 min 18 sec)
0:06:23 [321/418/9] test_isinstance passed -- running: test_subprocess (6 min 8 sec), test_lib2to3 (2 min 38 sec), test_multiprocessing_main_handling (2 min 26 sec), test_venv (5 min 19 sec), test_logging (2 min 2 sec), test_multiprocessing_forkserver (5 min 523 ms), test_compileall (2 min 18 sec)
0:06:23 [322/418/9] test_grammar passed -- running: test_subprocess (6 min 9 sec), test_lib2to3 (2 min 39 sec), test_multiprocessing_main_handling (2 min 27 sec), test_venv (5 min 20 sec), test_logging (2 min 3 sec), test_multiprocessing_forkserver (5 min 1 sec), test_compileall (2 min 19 sec)
0:06:23 [323/418/9] test_contextlib passed -- running: test_subprocess (6 min 9 sec), test_lib2to3 (2 min 39 sec), test_multiprocessing_main_handling (2 min 27 sec), test_venv (5 min 20 sec), test_logging (2 min 3 sec), test_multiprocessing_forkserver (5 min 1 sec), test_compileall (2 min 19 sec)
0:06:24 [324/418/9] test_getargs2 passed -- running: test_subprocess (6 min 9 sec), test_lib2to3 (2 min 40 sec), test_multiprocessing_main_handling (2 min 28 sec), test_venv (5 min 21 sec), test_logging (2 min 3 sec), test_multiprocessing_forkserver (5 min 1 sec), test_compileall (2 min 19 sec)
0:06:24 [325/418/9] test_dictcomps passed -- running: test_subprocess (6 min 9 sec), test_lib2to3 (2 min 40 sec), test_multiprocessing_main_handling (2 min 28 sec), test_venv (5 min 21 sec), test_logging (2 min 4 sec), test_multiprocessing_forkserver (5 min 1 sec), test_compileall (2 min 19 sec)
0:06:25 [326/418/9] test_enum passed -- running: test_subprocess (6 min 11 sec), test_lib2to3 (2 min 41 sec), test_multiprocessing_main_handling (2 min 29 sec), test_venv (5 min 22 sec), test_logging (2 min 5 sec), test_multiprocessing_forkserver (5 min 3 sec), test_compileall (2 min 21 sec)
0:06:26 [327/418/9] test_unicode_file_functions passed -- running: test_subprocess (6 min 11 sec), test_lib2to3 (2 min 41 sec), test_multiprocessing_main_handling (2 min 29 sec), test_venv (5 min 23 sec), test_logging (2 min 5 sec), test_multiprocessing_forkserver (5 min 3 sec), test_compileall (2 min 21 sec)
0:06:26 [328/418/9] test_shelve passed -- running: test_subprocess (6 min 11 sec), test_lib2to3 (2 min 41 sec), test_multiprocessing_main_handling (2 min 30 sec), test_venv (5 min 23 sec), test_logging (2 min 5 sec), test_multiprocessing_forkserver (5 min 3 sec), test_compileall (2 min 21 sec)
0:06:26 [329/418/9] test_codecmaps_cn passed -- running: test_subprocess (6 min 12 sec), test_lib2to3 (2 min 42 sec), test_multiprocessing_main_handling (2 min 30 sec), test_venv (5 min 23 sec), test_logging (2 min 6 sec), test_multiprocessing_forkserver (5 min 4 sec), test_compileall (2 min 22 sec)
0:06:27 [330/418/9] test_defaultdict passed -- running: test_subprocess (6 min 13 sec), test_lib2to3 (2 min 43 sec), test_multiprocessing_main_handling (2 min 31 sec), test_venv (5 min 24 sec), test_logging (2 min 7 sec), test_multiprocessing_forkserver (5 min 4 sec), test_compileall (2 min 22 sec)
0:06:27 [331/418/9] test_configparser passed -- running: test_subprocess (6 min 13 sec), test_lib2to3 (2 min 43 sec), test_multiprocessing_main_handling (2 min 31 sec), test_venv (5 min 24 sec), test_logging (2 min 7 sec), test_multiprocessing_forkserver (5 min 5 sec), test_compileall (2 min 23 sec)
0:06:28 [332/418/9] test_enumerate passed -- running: test_subprocess (6 min 13 sec), test_lib2to3 (2 min 44 sec), test_multiprocessing_main_handling (2 min 32 sec), test_venv (5 min 25 sec), test_logging (2 min 7 sec), test_multiprocessing_forkserver (5 min 5 sec), test_compileall (2 min 23 sec)
0:06:29 [333/418/9] test_ipaddress passed -- running: test_subprocess (6 min 14 sec), test_lib2to3 (2 min 44 sec), test_multiprocessing_main_handling (2 min 32 sec), test_venv (5 min 25 sec), test_logging (2 min 8 sec), test_multiprocessing_forkserver (5 min 6 sec), test_compileall (2 min 24 sec)
0:06:30 [334/418/9] test_builtin passed -- running: test_subprocess (6 min 15 sec), test_lib2to3 (2 min 45 sec), test_multiprocessing_main_handling (2 min 33 sec), test_venv (5 min 27 sec), test_logging (2 min 9 sec), test_multiprocessing_forkserver (5 min 7 sec), test_compileall (2 min 25 sec)
0:06:30 [335/418/9] test_unpack passed -- running: test_subprocess (6 min 16 sec), test_lib2to3 (2 min 46 sec), test_multiprocessing_main_handling (2 min 34 sec), test_venv (5 min 27 sec), test_logging (2 min 10 sec), test_multiprocessing_forkserver (5 min 8 sec), test_compileall (2 min 26 sec)
0:06:32 [336/418/9] test_smtplib passed -- running: test_subprocess (6 min 17 sec), test_lib2to3 (2 min 47 sec), test_multiprocessing_main_handling (2 min 35 sec), test_venv (5 min 29 sec), test_logging (2 min 11 sec), test_multiprocessing_forkserver (5 min 9 sec), test_compileall (2 min 27 sec)
0:06:35 [337/418/9] test_heapq passed -- running: test_subprocess (6 min 21 sec), test_lib2to3 (2 min 51 sec), test_multiprocessing_main_handling (2 min 39 sec), test_venv (5 min 32 sec), test_logging (2 min 15 sec), test_multiprocessing_forkserver (5 min 13 sec), test_compileall (2 min 31 sec)
0:06:36 [338/418/9] test_http_cookies passed -- running: test_subprocess (6 min 21 sec), test_lib2to3 (2 min 51 sec), test_multiprocessing_main_handling (2 min 39 sec), test_venv (5 min 33 sec), test_logging (2 min 15 sec), test_multiprocessing_forkserver (5 min 13 sec), test_compileall (2 min 31 sec)
0:06:37 [339/418/9] test_class passed -- running: test_subprocess (6 min 22 sec), test_lib2to3 (2 min 52 sec), test_multiprocessing_main_handling (2 min 40 sec), test_venv (5 min 33 sec), test_logging (2 min 16 sec), test_multiprocessing_forkserver (5 min 14 sec), test_compileall (2 min 32 sec)
0:06:37 [340/418/9] test_bytes passed -- running: test_subprocess (6 min 23 sec), test_lib2to3 (2 min 53 sec), test_multiprocessing_main_handling (2 min 41 sec), test_venv (5 min 34 sec), test_logging (2 min 17 sec), test_multiprocessing_forkserver (5 min 15 sec), test_compileall (2 min 33 sec)
0:06:38 [341/418/9] test_codecmaps_jp passed -- running: test_subprocess (6 min 23 sec), test_lib2to3 (2 min 53 sec), test_multiprocessing_main_handling (2 min 41 sec), test_venv (5 min 35 sec), test_logging (2 min 17 sec), test_multiprocessing_forkserver (5 min 15 sec), test_compileall (2 min 33 sec)
0:06:42 [342/418/9] test_poplib passed -- running: test_subprocess (6 min 27 sec), test_lib2to3 (2 min 58 sec), test_multiprocessing_main_handling (2 min 46 sec), test_venv (5 min 39 sec), test_logging (2 min 21 sec), test_multiprocessing_forkserver (5 min 19 sec), test_compileall (2 min 37 sec)
0:06:45 [343/418/9] test_posix passed -- running: test_subprocess (6 min 31 sec), test_lib2to3 (3 min 1 sec), test_multiprocessing_main_handling (2 min 49 sec), test_venv (5 min 42 sec), test_logging (2 min 25 sec), test_multiprocessing_forkserver (5 min 23 sec), test_compileall (2 min 41 sec)
0:06:46 [344/418/9] test_reprlib passed -- running: test_subprocess (6 min 32 sec), test_lib2to3 (3 min 2 sec), test_multiprocessing_main_handling (2 min 50 sec), test_venv (5 min 43 sec), test_logging (2 min 26 sec), test_multiprocessing_forkserver (5 min 24 sec), test_compileall (2 min 42 sec)
0:06:47 [345/418/9] test_strptime passed -- running: test_subprocess (6 min 32 sec), test_lib2to3 (3 min 3 sec), test_multiprocessing_main_handling (2 min 51 sec), test_venv (5 min 44 sec), test_logging (2 min 26 sec), test_multiprocessing_forkserver (5 min 24 sec), test_compileall (2 min 42 sec)
0:06:49 [346/418/9] test_lib2to3 passed (3 min 3 sec) -- running: test_subprocess (6 min 34 sec), test_multiprocessing_main_handling (2 min 52 sec), test_venv (5 min 45 sec), test_logging (2 min 28 sec), test_multiprocessing_forkserver (5 min 26 sec), test_compileall (2 min 44 sec)
0:06:50 [347/418/9] test_sax passed -- running: test_subprocess (6 min 35 sec), test_multiprocessing_main_handling (2 min 54 sec), test_venv (5 min 47 sec), test_logging (2 min 30 sec), test_multiprocessing_forkserver (5 min 27 sec), test_compileall (2 min 45 sec)
0:06:51 [348/418/10] test_subprocess failed -- running: test_multiprocessing_main_handling (2 min 55 sec), test_venv (5 min 48 sec), test_logging (2 min 31 sec), test_multiprocessing_forkserver (5 min 29 sec), test_compileall (2 min 47 sec)
test test_subprocess failed -- Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test_subprocess.py", line 2596, in test_zombie_fast_process_del
    self.assertIn(ident, [id(o) for o in subprocess._active])
AssertionError: 810459296 not found in []
0:06:54 [349/418/10] test_compileall passed (2 min 43 sec) -- running: test_multiprocessing_main_handling (2 min 57 sec), test_venv (5 min 50 sec), test_logging (2 min 33 sec), test_multiprocessing_forkserver (5 min 31 sec)
0:06:54 [350/418/10] test_xml_etree_c passed -- running: test_multiprocessing_main_handling (2 min 57 sec), test_venv (5 min 50 sec), test_logging (2 min 33 sec), test_multiprocessing_forkserver (5 min 31 sec)
0:06:54 [351/418/10] test_pathlib passed -- running: test_multiprocessing_main_handling (2 min 57 sec), test_venv (5 min 50 sec), test_logging (2 min 33 sec), test_multiprocessing_forkserver (5 min 31 sec)
0:06:54 [352/418/10] test_univnewlines passed -- running: test_multiprocessing_main_handling (2 min 57 sec), test_venv (5 min 51 sec), test_logging (2 min 33 sec), test_multiprocessing_forkserver (5 min 31 sec)
0:06:55 [353/418/10] test_sys_setprofile passed -- running: test_multiprocessing_main_handling (2 min 59 sec), test_venv (5 min 52 sec), test_logging (2 min 34 sec), test_multiprocessing_forkserver (5 min 32 sec)
0:06:56 [354/418/10] test_shlex passed -- running: test_multiprocessing_main_handling (2 min 59 sec), test_venv (5 min 52 sec), test_logging (2 min 34 sec), test_multiprocessing_forkserver (5 min 32 sec)
0:06:56 [355/418/10] test_int passed -- running: test_multiprocessing_main_handling (2 min 59 sec), test_venv (5 min 52 sec), test_logging (2 min 35 sec), test_multiprocessing_forkserver (5 min 33 sec)
0:06:56 [356/418/10] test_property passed -- running: test_multiprocessing_main_handling (2 min 59 sec), test_venv (5 min 52 sec), test_logging (2 min 35 sec), test_multiprocessing_forkserver (5 min 33 sec)
0:06:57 [357/418/10] test_codecmaps_hk passed -- running: test_multiprocessing_main_handling (3 min 898 ms), test_venv (5 min 54 sec), test_logging (2 min 36 sec), test_multiprocessing_forkserver (5 min 34 sec)
0:06:57 [358/418/10] test_extcall passed -- running: test_multiprocessing_main_handling (3 min 942 ms), test_venv (5 min 54 sec), test_logging (2 min 36 sec), test_multiprocessing_forkserver (5 min 34 sec)
0:06:58 [359/418/10] test_strftime passed -- running: test_multiprocessing_main_handling (3 min 1 sec), test_venv (5 min 54 sec), test_logging (2 min 37 sec), test_multiprocessing_forkserver (5 min 35 sec)
0:06:58 [360/418/10] test_dictviews passed -- running: test_multiprocessing_main_handling (3 min 2 sec), test_venv (5 min 55 sec), test_logging (2 min 38 sec), test_multiprocessing_forkserver (5 min 35 sec)
0:07:00 [361/418/10] test_email passed -- running: test_multiprocessing_main_handling (3 min 3 sec), test_venv (5 min 56 sec), test_logging (2 min 39 sec), test_multiprocessing_forkserver (5 min 37 sec)
0:07:00 [362/418/11] test_pkg failed -- running: test_multiprocessing_main_handling (3 min 3 sec), test_venv (5 min 56 sec), test_logging (2 min 39 sec), test_multiprocessing_forkserver (5 min 37 sec)
test test_pkg failed -- multiple errors occurred; run in verbose mode for details
0:07:00 [363/418/11] test_logging passed (2 min 39 sec) -- running: test_multiprocessing_main_handling (3 min 4 sec), test_venv (5 min 57 sec), test_multiprocessing_forkserver (5 min 38 sec)
0:07:01 [364/418/11] test_gc passed -- running: test_multiprocessing_main_handling (3 min 5 sec), test_venv (5 min 58 sec), test_multiprocessing_forkserver (5 min 38 sec)
0:07:01 [365/418/11] test_multiprocessing_main_handling passed (3 min 3 sec) -- running: test_venv (5 min 58 sec), test_multiprocessing_forkserver (5 min 39 sec)
0:07:02 [366/418/11] test_codecencodings_cn passed -- running: test_venv (5 min 58 sec), test_multiprocessing_forkserver (5 min 39 sec)
0:07:02 [367/418/11] test_dbm passed -- running: test_venv (5 min 59 sec), test_multiprocessing_forkserver (5 min 39 sec)
0:07:02 [368/418/11] test_ftplib passed -- running: test_venv (5 min 59 sec), test_multiprocessing_forkserver (5 min 40 sec)
0:07:03 [369/418/11] test_asyncgen passed -- running: test_venv (6 min 253 ms), test_multiprocessing_forkserver (5 min 40 sec)
0:07:03 [370/418/11] test_marshal passed -- running: test_venv (6 min 256 ms), test_multiprocessing_forkserver (5 min 40 sec)
0:07:03 [371/418/11] test_netrc passed -- running: test_venv (6 min 559 ms), test_multiprocessing_forkserver (5 min 41 sec)
0:07:04 [372/418/11] test_codeop passed -- running: test_venv (6 min 1 sec), test_multiprocessing_forkserver (5 min 41 sec)
0:07:05 [373/418/11] test_cgitb passed -- running: test_venv (6 min 1 sec), test_multiprocessing_forkserver (5 min 42 sec)
0:07:16 [374/418/11] test_secrets passed -- running: test_venv (6 min 13 sec), test_multiprocessing_forkserver (5 min 53 sec)
0:07:16 [375/418/11] test_json passed -- running: test_venv (6 min 13 sec), test_multiprocessing_forkserver (5 min 54 sec)
0:07:45 [376/418/11] test_ossaudiodev skipped (resource denied) -- running: test_context (39 sec 109 ms), test_pydoc (44 sec 811 ms), test_multiprocessing_spawn (50 sec 838 ms), test_strtod (40 sec 554 ms), test_concurrent_futures (41 sec 218 ms), test_venv (6 min 41 sec), test_compile (42 sec 738 ms), test_multiprocessing_forkserver (6 min 22 sec), test_source_encoding (41 sec 510 ms)
test_ossaudiodev skipped -- Use of the 'audio' resource not enabled
0:07:45 [377/418/11] test_context passed -- running: test_pydoc (45 sec 277 ms), test_multiprocessing_spawn (51 sec 304 ms), test_strtod (41 sec 20 ms), test_concurrent_futures (41 sec 684 ms), test_venv (6 min 42 sec), test_compile (43 sec 204 ms), test_multiprocessing_forkserver (6 min 22 sec), test_source_encoding (41 sec 976 ms)
0:07:45 [378/418/11] test_strtod passed (31 sec 346 ms) -- running: test_pydoc (45 sec 510 ms), test_multiprocessing_spawn (51 sec 537 ms), test_concurrent_futures (41 sec 917 ms), test_venv (6 min 42 sec), test_compile (43 sec 437 ms), test_multiprocessing_forkserver (6 min 23 sec), test_source_encoding (42 sec 209 ms)
0:07:47 [379/418/11] test_generators passed -- running: test_pydoc (46 sec 828 ms), test_multiprocessing_spawn (52 sec 855 ms), test_concurrent_futures (43 sec 235 ms), test_venv (6 min 43 sec), test_compile (44 sec 755 ms), test_multiprocessing_forkserver (6 min 24 sec), test_source_encoding (43 sec 527 ms)
0:07:47 [380/418/11] test_hmac passed -- running: test_pydoc (47 sec 356 ms), test_multiprocessing_spawn (53 sec 383 ms), test_concurrent_futures (43 sec 763 ms), test_venv (6 min 44 sec), test_compile (45 sec 283 ms), test_multiprocessing_forkserver (6 min 24 sec), test_source_encoding (44 sec 55 ms)
0:07:51 [381/418/11] test_dis passed -- running: test_pydoc (51 sec 325 ms), test_multiprocessing_spawn (57 sec 353 ms), test_concurrent_futures (47 sec 732 ms), test_venv (6 min 48 sec), test_compile (49 sec 253 ms), test_multiprocessing_forkserver (6 min 28 sec), test_source_encoding (48 sec 24 ms)
0:07:51 [382/418/11] test_codecencodings_hk passed -- running: test_pydoc (51 sec 698 ms), test_multiprocessing_spawn (57 sec 725 ms), test_concurrent_futures (48 sec 105 ms), test_venv (6 min 48 sec), test_compile (49 sec 625 ms), test_multiprocessing_forkserver (6 min 29 sec), test_source_encoding (48 sec 397 ms)
0:08:12 [383/418/11] test_binop passed -- running: test_pydoc (1 min 11 sec), test_multiprocessing_spawn (1 min 18 sec), test_concurrent_futures (1 min 8 sec), test_venv (7 min 8 sec), test_compile (1 min 9 sec), test_multiprocessing_fork (37 sec 872 ms), test_multiprocessing_forkserver (6 min 49 sec), test_source_encoding (1 min 8 sec)
0:08:12 [384/418/11] test_asdl_parser passed -- running: test_pydoc (1 min 11 sec), test_multiprocessing_spawn (1 min 18 sec), test_concurrent_futures (1 min 8 sec), test_venv (7 min 8 sec), test_compile (1 min 9 sec), test_multiprocessing_fork (37 sec 873 ms), test_multiprocessing_forkserver (6 min 49 sec), test_source_encoding (1 min 8 sec)
0:08:16 [385/418/11] test_fcntl passed -- running: test_pydoc (1 min 16 sec), test_multiprocessing_spawn (1 min 22 sec), test_concurrent_futures (1 min 12 sec), test_venv (7 min 12 sec), test_compile (1 min 13 sec), test_multiprocessing_fork (41 sec 917 ms), test_multiprocessing_forkserver (6 min 53 sec), test_source_encoding (1 min 12 sec)
0:08:16 [386/418/11] test_file_eintr passed -- running: test_pydoc (1 min 16 sec), test_multiprocessing_spawn (1 min 22 sec), test_concurrent_futures (1 min 12 sec), test_venv (7 min 13 sec), test_compile (1 min 14 sec), test_multiprocessing_fork (42 sec 154 ms), test_multiprocessing_forkserver (6 min 53 sec), test_source_encoding (1 min 12 sec)
0:08:16 [387/418/11] test_copy passed -- running: test_pydoc (1 min 16 sec), test_multiprocessing_spawn (1 min 22 sec), test_concurrent_futures (1 min 12 sec), test_venv (7 min 13 sec), test_compile (1 min 14 sec), test_multiprocessing_fork (42 sec 483 ms), test_multiprocessing_forkserver (6 min 54 sec), test_source_encoding (1 min 13 sec)
0:08:17 [388/418/11] test_charmapcodec passed -- running: test_pydoc (1 min 17 sec), test_multiprocessing_spawn (1 min 23 sec), test_concurrent_futures (1 min 13 sec), test_venv (7 min 13 sec), test_compile (1 min 14 sec), test_multiprocessing_fork (42 sec 920 ms), test_multiprocessing_forkserver (6 min 54 sec), test_source_encoding (1 min 13 sec)
0:08:18 [389/418/11] test_minidom passed -- running: test_pydoc (1 min 17 sec), test_multiprocessing_spawn (1 min 23 sec), test_concurrent_futures (1 min 14 sec), test_venv (7 min 14 sec), test_compile (1 min 15 sec), test_multiprocessing_fork (43 sec 731 ms), test_multiprocessing_forkserver (6 min 55 sec), test_source_encoding (1 min 14 sec)
0:08:18 [390/418/11] test_richcmp passed -- running: test_pydoc (1 min 18 sec), test_multiprocessing_spawn (1 min 24 sec), test_concurrent_futures (1 min 14 sec), test_venv (7 min 15 sec), test_compile (1 min 16 sec), test_multiprocessing_fork (44 sec 212 ms), test_multiprocessing_forkserver (6 min 55 sec), test_source_encoding (1 min 15 sec)
0:08:19 [391/418/11] test_tracemalloc passed -- running: test_pydoc (1 min 19 sec), test_multiprocessing_spawn (1 min 25 sec), test_concurrent_futures (1 min 15 sec), test_venv (7 min 15 sec), test_compile (1 min 16 sec), test_multiprocessing_fork (44 sec 908 ms), test_multiprocessing_forkserver (6 min 56 sec), test_source_encoding (1 min 15 sec)
0:08:19 [392/418/11] test_smtpnet skipped (resource denied) -- running: test_pydoc (1 min 19 sec), test_multiprocessing_spawn (1 min 25 sec), test_concurrent_futures (1 min 15 sec), test_venv (7 min 16 sec), test_compile (1 min 17 sec), test_multiprocessing_fork (45 sec 472 ms), test_multiprocessing_forkserver (6 min 57 sec), test_source_encoding (1 min 16 sec)
test_smtpnet skipped -- Use of the 'network' resource not enabled
0:08:20 [393/418/11] test_baseexception passed -- running: test_pydoc (1 min 19 sec), test_multiprocessing_spawn (1 min 26 sec), test_concurrent_futures (1 min 16 sec), test_venv (7 min 16 sec), test_compile (1 min 17 sec), test_multiprocessing_fork (45 sec 887 ms), test_multiprocessing_forkserver (6 min 57 sec), test_source_encoding (1 min 16 sec)
0:08:20 [394/418/11] test_resource passed -- running: test_pydoc (1 min 20 sec), test_multiprocessing_spawn (1 min 26 sec), test_concurrent_futures (1 min 17 sec), test_venv (7 min 17 sec), test_compile (1 min 18 sec), test_multiprocessing_fork (46 sec 687 ms), test_multiprocessing_forkserver (6 min 58 sec), test_source_encoding (1 min 17 sec)
0:08:26 [395/418/11] test_ntpath passed -- running: test_pydoc (1 min 26 sec), test_multiprocessing_spawn (1 min 32 sec), test_concurrent_futures (1 min 22 sec), test_venv (7 min 23 sec), test_compile (1 min 24 sec), test_multiprocessing_fork (52 sec 177 ms), test_multiprocessing_forkserver (7 min 3 sec), test_source_encoding (1 min 22 sec)
0:08:27 [396/418/11] test_grp passed -- running: test_pydoc (1 min 27 sec), test_multiprocessing_spawn (1 min 33 sec), test_concurrent_futures (1 min 23 sec), test_venv (7 min 24 sec), test_compile (1 min 25 sec), test_multiprocessing_fork (53 sec 17 ms), test_multiprocessing_forkserver (7 min 4 sec), test_source_encoding (1 min 23 sec)
0:08:28 [397/418/11] test_pulldom passed -- running: test_pydoc (1 min 27 sec), test_multiprocessing_spawn (1 min 33 sec), test_concurrent_futures (1 min 24 sec), test_venv (7 min 24 sec), test_compile (1 min 25 sec), test_multiprocessing_fork (53 sec 848 ms), test_multiprocessing_forkserver (7 min 5 sec), test_source_encoding (1 min 24 sec)
0:08:28 [398/418/11] test_dtrace passed -- running: test_pydoc (1 min 28 sec), test_multiprocessing_spawn (1 min 34 sec), test_concurrent_futures (1 min 25 sec), test_venv (7 min 25 sec), test_compile (1 min 26 sec), test_multiprocessing_fork (54 sec 536 ms), test_multiprocessing_forkserver (7 min 6 sec), test_source_encoding (1 min 25 sec)
0:08:29 [399/418/11] test___future__ passed -- running: test_pydoc (1 min 29 sec), test_multiprocessing_spawn (1 min 35 sec), test_concurrent_futures (1 min 25 sec), test_venv (7 min 26 sec), test_compile (1 min 27 sec), test_multiprocessing_fork (55 sec 41 ms), test_multiprocessing_forkserver (7 min 6 sec), test_source_encoding (1 min 25 sec)
0:08:29 [400/418/11] test_bigaddrspace passed -- running: test_pydoc (1 min 29 sec), test_multiprocessing_spawn (1 min 35 sec), test_concurrent_futures (1 min 26 sec), test_venv (7 min 26 sec), test_compile (1 min 27 sec), test_multiprocessing_fork (55 sec 537 ms), test_multiprocessing_forkserver (7 min 7 sec), test_source_encoding (1 min 26 sec)
0:08:30 [401/418/11] test_pydoc passed (1 min 18 sec) -- running: test_multiprocessing_spawn (1 min 36 sec), test_concurrent_futures (1 min 26 sec), test_venv (7 min 27 sec), test_compile (1 min 28 sec), test_multiprocessing_fork (56 sec 109 ms), test_multiprocessing_forkserver (7 min 7 sec), test_source_encoding (1 min 26 sec)
0:08:30 [402/418/11] test_unicode_file passed -- running: test_multiprocessing_spawn (1 min 36 sec), test_concurrent_futures (1 min 26 sec), test_venv (7 min 27 sec), test_compile (1 min 28 sec), test_multiprocessing_fork (56 sec 200 ms), test_multiprocessing_forkserver (7 min 7 sec), test_source_encoding (1 min 27 sec)
0:08:30 [403/418/11] test_devpoll skipped -- running: test_multiprocessing_spawn (1 min 36 sec), test_concurrent_futures (1 min 27 sec), test_venv (7 min 27 sec), test_compile (1 min 28 sec), test_multiprocessing_fork (56 sec 650 ms), test_multiprocessing_forkserver (7 min 8 sec), test_source_encoding (1 min 27 sec)
test_devpoll skipped -- test works only on Solaris OS family
0:08:31 [404/418/11] test_source_encoding passed (1 min 22 sec) -- running: test_multiprocessing_spawn (1 min 37 sec), test_concurrent_futures (1 min 27 sec), test_venv (7 min 28 sec), test_compile (1 min 29 sec), test_multiprocessing_fork (57 sec 64 ms), test_multiprocessing_forkserver (7 min 8 sec)
0:08:33 [405/418/11] test_struct passed -- running: test_multiprocessing_spawn (1 min 39 sec), test_concurrent_futures (1 min 29 sec), test_venv (7 min 30 sec), test_compile (1 min 31 sec), test_multiprocessing_fork (59 sec 110 ms), test_multiprocessing_forkserver (7 min 10 sec)
0:08:37 [406/418/11] test_import passed -- running: test_multiprocessing_spawn (1 min 43 sec), test_concurrent_futures (1 min 34 sec), test_venv (7 min 34 sec), test_compile (1 min 35 sec), test_multiprocessing_fork (1 min 3 sec), test_multiprocessing_forkserver (7 min 15 sec)
0:08:38 [407/418/11] test_calendar passed -- running: test_multiprocessing_spawn (1 min 44 sec), test_concurrent_futures (1 min 34 sec), test_venv (7 min 35 sec), test_compile (1 min 36 sec), test_multiprocessing_fork (1 min 4 sec), test_multiprocessing_forkserver (7 min 15 sec)
0:08:39 [408/418/11] test_parser passed -- running: test_multiprocessing_spawn (1 min 44 sec), test_concurrent_futures (1 min 35 sec), test_venv (7 min 35 sec), test_compile (1 min 36 sec), test_multiprocessing_fork (1 min 4 sec), test_multiprocessing_forkserver (7 min 16 sec)
0:08:40 [409/418/11] test_posixpath passed -- running: test_multiprocessing_spawn (1 min 45 sec), test_concurrent_futures (1 min 36 sec), test_venv (7 min 36 sec), test_compile (1 min 37 sec), test_multiprocessing_fork (1 min 5 sec), test_multiprocessing_forkserver (7 min 17 sec)
0:08:44 [410/418/11] test_decimal passed -- running: test_multiprocessing_spawn (1 min 49 sec), test_concurrent_futures (1 min 40 sec), test_venv (7 min 40 sec), test_compile (1 min 41 sec), test_multiprocessing_fork (1 min 9 sec), test_multiprocessing_forkserver (7 min 21 sec)
0:08:44 [411/418/11] test_codecs passed -- running: test_multiprocessing_spawn (1 min 49 sec), test_concurrent_futures (1 min 40 sec), test_venv (7 min 40 sec), test_compile (1 min 41 sec), test_multiprocessing_fork (1 min 9 sec), test_multiprocessing_forkserver (7 min 21 sec)
running: test_imaplib (37 sec 8 ms), test_multiprocessing_spawn (2 min 21 sec), test_concurrent_futures (2 min 11 sec), test_venv (8 min 12 sec), test_compile (2 min 13 sec), test_multiprocessing_fork (1 min 41 sec), test_multiprocessing_forkserver (7 min 52 sec)
0:09:21 [412/418/11] test_imaplib passed (42 sec 338 ms) -- running: test_multiprocessing_spawn (2 min 27 sec), test_concurrent_futures (2 min 17 sec), test_venv (8 min 18 sec), test_compile (2 min 19 sec), test_multiprocessing_fork (1 min 46 sec), test_multiprocessing_forkserver (7 min 58 sec)
running: test_multiprocessing_spawn (2 min 57 sec), test_concurrent_futures (2 min 47 sec), test_venv (8 min 48 sec), test_compile (2 min 49 sec), test_multiprocessing_fork (2 min 16 sec), test_multiprocessing_forkserver (8 min 28 sec)
running: test_multiprocessing_spawn (3 min 27 sec), test_concurrent_futures (3 min 17 sec), test_venv (9 min 18 sec), test_compile (3 min 19 sec), test_multiprocessing_fork (2 min 46 sec), test_multiprocessing_forkserver (8 min 58 sec)
running: test_multiprocessing_spawn (4 min 6 sec), test_concurrent_futures (3 min 56 sec), test_venv (9 min 57 sec), test_compile (3 min 58 sec), test_multiprocessing_fork (3 min 26 sec), test_multiprocessing_forkserver (9 min 37 sec)
0:11:20 [413/418/11] test_multiprocessing_forkserver passed (9 min 48 sec) -- running: test_multiprocessing_spawn (4 min 26 sec), test_concurrent_futures (4 min 16 sec), test_venv (10 min 17 sec), test_compile (4 min 18 sec), test_multiprocessing_fork (3 min 46 sec)
0:11:31 [414/418/11] test_venv passed (10 min 25 sec) -- running: test_multiprocessing_spawn (4 min 37 sec), test_concurrent_futures (4 min 27 sec), test_compile (4 min 29 sec), test_multiprocessing_fork (3 min 57 sec)
running: test_multiprocessing_spawn (5 min 17 sec), test_concurrent_futures (5 min 7 sec), test_compile (5 min 9 sec), test_multiprocessing_fork (4 min 37 sec)
running: test_multiprocessing_spawn (5 min 51 sec), test_concurrent_futures (5 min 42 sec), test_compile (5 min 43 sec), test_multiprocessing_fork (5 min 11 sec)
running: test_multiprocessing_spawn (6 min 21 sec), test_concurrent_futures (6 min 12 sec), test_compile (6 min 13 sec), test_multiprocessing_fork (5 min 41 sec)
0:13:24 [415/418/12] test_concurrent_futures failed -- running: test_multiprocessing_spawn (6 min 29 sec), test_compile (6 min 21 sec), test_multiprocessing_fork (5 min 49 sec)
test test_concurrent_futures failed -- multiple errors occurred; run in verbose mode for details
running: test_multiprocessing_spawn (7 min 108 ms), test_compile (6 min 52 sec), test_multiprocessing_fork (6 min 19 sec)
0:14:03 [416/418/13] test_multiprocessing_fork failed -- running: test_multiprocessing_spawn (7 min 8 sec), test_compile (7 min 844 ms)
Warning -- Dangling processes: {<Process(Process-421, started)>, <Process(Process-423, started)>, <Process(Process-424, started)>, <Process(Process-419, started)>, <Process(Process-422, started)>, <Process(Process-402, started)>, <Process(Process-404, started)>, <Process(Process-415, started)>, <Process(Process-344, started)>, <Process(Process-345, started)>, <Process(Process-346, started)>, <Process(Process-347, started)>, <Process(Process-413, started)>, <Process(Process-348, started)>, <Process(Process-349, started)>, <Process(Process-408, started)>, <Process(Process-350, started)>, <Process(Process-420, started)>, <Process(Process-351, started)>, <Process(Process-352, started)>, <Process(Process-412, started)>, <Process(Process-353, started)>, <Process(Process-418, started)>, <Process(Process-354, started)>, <Process(Process-414, started)>, <Process(Process-355, started)>, <Process(Process-356, started)>, <Process(Process-357, started)>, <Process(Process-358, started)>, <
 Process(Process-403, started)>, <Process(Process-359, started)>, <Process(Process-360, started)>, <Process(Process-361, started)>, <Process(Process-362, started)>, <Process(Process-363, started)>, <Process(Process-407, started)>, <Process(Process-364, started)>, <Process(Process-365, started)>, <Process(Process-366, started)>, <Process(Process-367, started)>, <Process(Process-368, started)>, <Process(Process-369, started)>, <Process(Process-370, started)>, <Process(Process-371, started)>, <Process(Process-372, started)>, <Process(Process-373, started)>, <Process(Process-433, stopped[SIGKILL])>, <Process(Process-374, started)>, <Process(Process-375, started)>, <Process(Process-376, started)>, <Process(Process-406, started)>, <Process(Process-377, started)>, <Process(Process-409, started)>, <Process(Process-378, started)>, <Process(Process-379, started)>, <Process(Process-431, stopped[SIGKILL])>, <Process(Process-380, started)>, <Process(Process-381, started)>, <Process(Proces
 s-382, started)>, <Process(Process-401, started)>, <Process(Process-383, started)>, <Process(Process-411, started)>, <Process(Process-384, started)>, <Process(Process-385, started)>, <Process(Process-405, started)>, <Process(Process-430, stopped[SIGKILL])>, <Process(Process-386, started)>, <Process(Process-387, started)>, <Process(Process-388, started)>, <Process(Process-389, started)>, <Process(Process-390, started)>, <Process(Process-416, started)>, <Process(Process-391, started)>, <Process(Process-392, started)>, <Process(Process-393, started)>, <Process(Process-417, started)>, <Process(Process-394, started)>, <Process(Process-395, started)>, <Process(Process-396, started)>, <Process(Process-397, started)>, <Process(Process-410, started)>, <Process(Process-398, started)>, <Process(Process-399, started)>, <Process(Process-426, started)>, <Process(Process-400, started)>, <Process(Process-425, started)>}
Warning -- Dangling processes: {<Process(Process-359, started)>, <Process(Process-360, started)>, <Process(Process-361, started)>, <Process(Process-362, started)>, <Process(Process-363, started)>, <Process(Process-407, started)>, <Process(Process-364, started)>, <Process(Process-365, started)>, <Process(Process-366, started)>, <Process(Process-367, started)>, <Process(Process-368, started)>, <Process(Process-369, started)>, <Process(Process-370, started)>, <Process(Process-371, started)>, <Process(Process-372, started)>, <Process(Process-402, started)>, <Process(Process-373, started)>, <Process(Process-374, started)>, <Process(Process-375, started)>, <Process(Process-376, started)>, <Process(Process-406, started)>, <Process(Process-377, started)>, <Process(Process-378, started)>, <Process(Process-379, started)>, <Process(Process-380, started)>, <Process(Process-381, started)>, <Process(Process-382, started)>, <Process(Process-383, started)>, <Process(Process-404, started)>, <
 Process(Process-384, started)>, <Process(Process-385, started)>, <Process(Process-386, started)>, <Process(Process-344, started)>, <Process(Process-387, started)>, <Process(Process-345, started)>, <Process(Process-388, started)>, <Process(Process-346, started)>, <Process(Process-389, started)>, <Process(Process-347, started)>, <Process(Process-390, started)>, <Process(Process-348, started)>, <Process(Process-391, started)>, <Process(Process-349, started)>, <Process(Process-392, started)>, <Process(Process-350, started)>, <Process(Process-393, started)>, <Process(Process-351, started)>, <Process(Process-394, started)>, <Process(Process-352, started)>, <Process(Process-395, started)>, <Process(Process-353, started)>, <Process(Process-396, started)>, <Process(Process-354, started)>, <Process(Process-397, started)>, <Process(Process-355, started)>, <Process(Process-398, started)>, <Process(Process-356, started)>, <Process(Process-399, started)>, <Process(Process-357, started)>, 
 <Process(Process-400, stopped[SIGKILL])>, <Process(Process-358, started)>, <Process(Process-401, started)>, <Process(Process-403, stopped[SIGKILL])>}
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing_fork
  Before: <_weakrefset.WeakSet object at 0x3045bcb8>
  After:  <_weakrefset.WeakSet object at 0x3049a640> 
test test_multiprocessing_fork failed -- multiple errors occurred; run in verbose mode for details
0:14:14 [417/418/13] test_compile passed (7 min 11 sec) -- running: test_multiprocessing_spawn (7 min 20 sec)
running: test_multiprocessing_spawn (7 min 50 sec)
0:14:53 [418/418/13] test_multiprocessing_spawn passed (7 min 54 sec)

== Tests result: FAILURE ==

375 tests OK.

13 tests failed:
    test__xxsubinterpreters test_asyncio test_concurrent_futures
    test_ctypes test_distutils test_embed test_httpservers
    test_multiprocessing_fork test_os test_pkg test_socket
    test_subprocess test_time

30 tests skipped:
    test_curses test_dbm_gnu test_devpoll test_epoll test_gdb
    test_idle test_kqueue test_lzma test_msilib test_ossaudiodev
    test_readline test_smtpnet test_socketserver test_spwd test_sqlite
    test_startfile test_tcl test_timeout test_tix test_tk
    test_ttk_guionly test_ttk_textonly test_turtle test_urllib2net
    test_urllibnet test_winconsoleio test_winreg test_winsound
    test_xmlrpc_net test_zipfile64

Total duration: 14 min 53 sec
Tests result: FAILURE
root at x066:[/data/prj/python/git/python3-3.8]

Script command is complete on Tue Aug 28 18:34:29 UTC 2018.

From report at bugs.python.org  Tue Aug 28 14:53:26 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 28 Aug 2018 18:53:26 +0000
Subject: [issue34403] test_utf8_mode.test_cmd_line() fails on HP-UX due to
 false assumptions
In-Reply-To: <2e69558e-40ac-fbb6-aee8-c3c79201648b@felt.demon.nl>
Message-ID: <99e39cef-8c28-0957-92f2-f8590a2c65c7@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 28/08/2018 20:43, Michael Felt wrote:
> Attached is the output with LC_ALL=C in the prefix. If you were hoping
> for "dangling processes - your hopes are affirmed.

Previous mail ended with:

== Tests result: FAILURE ==

375 tests OK.

13 tests failed:
??? test__xxsubinterpreters test_asyncio test_concurrent_futures
??? test_ctypes test_distutils test_embed test_httpservers
??? test_multiprocessing_fork test_os test_pkg test_socket
??? test_subprocess test_time

30 tests skipped:
??? test_curses test_dbm_gnu test_devpoll test_epoll test_gdb
??? test_idle test_kqueue test_lzma test_msilib test_ossaudiodev
??? test_readline test_smtpnet test_socketserver test_spwd test_sqlite
??? test_startfile test_tcl test_timeout test_tix test_tk
??? test_ttk_guionly test_ttk_textonly test_turtle test_urllib2net
??? test_urllibnet test_winconsoleio test_winreg test_winsound
??? test_xmlrpc_net test_zipfile64

Total duration: 14 min 53 sec
Tests result: FAILURE
root at x066:[/data/prj/python/git/python3-3.8]

Without LC_ALL=C summary is (different):

== Tests result: FAILURE ==

376 tests OK.

10 tests failed:
??? test__xxsubinterpreters test_asyncio test_ctypes test_distutils
??? test_embed test_httpservers test_multiprocessing_forkserver
??? test_os test_socket test_time

32 tests skipped:
??? test_curses test_dbm_gnu test_devpoll test_epoll test_gdb
??? test_idle test_kqueue test_lzma test_msilib test_ossaudiodev
??? test_readline test_smtpnet test_socketserver test_spwd test_sqlite
??? test_startfile test_tcl test_timeout test_tix test_tk
??? test_ttk_guionly test_ttk_textonly test_turtle test_unicode_file
??? test_unicode_file_functions test_urllib2net test_urllibnet
??? test_winconsoleio test_winreg test_winsound test_xmlrpc_net
??? test_zipfile64

Total duration: 11 min 1 sec

And, rather than dangling processes, I see BrokenBarrierErrors

FYI

----------
Added file: https://bugs.python.org/file47771/py3.8-default.text

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34403>
_______________________________________
-------------- next part --------------
Script command is started on Tue Aug 28 18:34:49 UTC 2018.
root at x066:[/data/prj/python/git/python3-3.8]script ../py3.8-default.textm                           maketopas -i 5LC _ALL=C ./python -m test -j0 -rC _ALL=C ./python -m test -j0 -r  _ALL=C ./python -m test -j0 -r ALL=C ./python -m test -j0 -r LL=C ./python -m test -j0 -r L=C ./python -m test -j0 -r =C ./python -m test -j0 -r C ./python -m test -j0 -r  ./python -m test -j0 -r ./python -m test -j0 -r 
== CPython 3.8.0a0 (heads/master:d500e5307a, Aug 28 2018, 18:09:17) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /data/prj/python/git/python3-3.8/build/test_python_16777460
== CPU count: 8
== encodings: locale=ISO8859-1, FS=iso8859-1
Using random seed 1054694
Run tests in parallel using 10 child processes
0:00:01 [  1/418] test_dictcomps passed
0:00:01 [  2/418] test_class passed
0:00:01 [  3/418] test_global passed
0:00:01 [  4/418] test_types passed
0:00:02 [  5/418] test_unpack_ex passed
0:00:02 [  6/418] test_sysconfig passed
0:00:02 [  7/418] test_functools passed
0:00:02 [  8/418] test_frozen passed
0:00:02 [  9/418] test_bigmem passed
0:00:03 [ 10/418] test_binascii passed
0:00:03 [ 11/418] test_profile passed
0:00:03 [ 12/418] test_tabnanny passed
0:00:03 [ 13/418] test_pty passed
0:00:03 [ 14/418] test_fstring passed
0:00:03 [ 15/418] test_codecencodings_kr passed
0:00:04 [ 16/418] test_strptime passed
0:00:04 [ 17/418] test_sunau passed
0:00:04 [ 18/418] test_unicode_identifiers passed
0:00:04 [ 19/418] test_longexp passed
0:00:05 [ 20/418] test_fileio passed
0:00:05 [ 21/418] test_repl passed
0:00:06 [ 22/418] test_int passed
0:00:06 [ 23/418] test_posixpath passed
running: test_compile (35 sec 776 ms), test_lib2to3 (36 sec 396 ms), test_queue (35 sec 862 ms), test_multiprocessing_spawn (37 sec 717 ms), test_faulthandler (35 sec 494 ms), test_compileall (33 sec 460 ms), test_random (37 sec 839 ms), test_fork1 (38 sec 549 ms)
0:00:40 [ 24/418] test_xmlrpc passed -- running: test_compile (36 sec 924 ms), test_lib2to3 (37 sec 167 ms), test_queue (36 sec 613 ms), test_multiprocessing_spawn (38 sec 468 ms), test_faulthandler (36 sec 244 ms), test_compileall (34 sec 211 ms), test_random (38 sec 590 ms), test_fork1 (39 sec 296 ms)
0:00:40 [ 25/418] test_ast passed -- running: test_compile (37 sec 6 ms), test_lib2to3 (37 sec 249 ms), test_queue (36 sec 695 ms), test_multiprocessing_spawn (38 sec 550 ms), test_faulthandler (36 sec 327 ms), test_compileall (34 sec 293 ms), test_random (38 sec 672 ms), test_fork1 (39 sec 378 ms)
0:00:41 [ 26/418] test_audioop passed -- running: test_compile (38 sec 444 ms), test_lib2to3 (38 sec 687 ms), test_queue (38 sec 133 ms), test_multiprocessing_spawn (39 sec 988 ms), test_faulthandler (37 sec 765 ms), test_compileall (35 sec 731 ms), test_random (40 sec 110 ms), test_fork1 (40 sec 816 ms)
0:00:42 [ 27/418] test_linecache passed -- running: test_compile (39 sec 289 ms), test_lib2to3 (39 sec 532 ms), test_queue (38 sec 978 ms), test_multiprocessing_spawn (40 sec 833 ms), test_faulthandler (38 sec 609 ms), test_compileall (36 sec 576 ms), test_random (40 sec 955 ms), test_fork1 (41 sec 661 ms)
0:00:43 [ 28/418] test_queue passed (37 sec 893 ms) -- running: test_compile (40 sec 316 ms), test_lib2to3 (40 sec 559 ms), test_multiprocessing_spawn (41 sec 860 ms), test_faulthandler (39 sec 637 ms), test_compileall (37 sec 603 ms), test_random (41 sec 982 ms), test_fork1 (42 sec 688 ms)
0:00:43 [ 29/418] test_zipimport passed -- running: test_compile (40 sec 409 ms), test_lib2to3 (40 sec 652 ms), test_multiprocessing_spawn (41 sec 953 ms), test_faulthandler (39 sec 730 ms), test_compileall (37 sec 696 ms), test_random (42 sec 75 ms), test_fork1 (42 sec 781 ms)
0:00:45 [ 30/418] test_random passed (40 sec 273 ms) -- running: test_compile (42 sec 406 ms), test_lib2to3 (42 sec 649 ms), test_multiprocessing_spawn (43 sec 950 ms), test_faulthandler (41 sec 726 ms), test_compileall (39 sec 693 ms), test_fork1 (44 sec 778 ms)
0:00:46 [ 31/418] test_fork1 passed (39 sec 359 ms) -- running: test_compile (42 sec 795 ms), test_lib2to3 (43 sec 38 ms), test_multiprocessing_spawn (44 sec 339 ms), test_faulthandler (42 sec 116 ms), test_compileall (40 sec 82 ms)
0:00:46 [ 32/418] test_dbm_ndbm passed -- running: test_compile (43 sec 383 ms), test_lib2to3 (43 sec 626 ms), test_multiprocessing_spawn (44 sec 927 ms), test_faulthandler (42 sec 704 ms), test_compileall (40 sec 671 ms)
0:00:47 [ 33/418] test_listcomps passed -- running: test_compile (43 sec 670 ms), test_lib2to3 (43 sec 913 ms), test_multiprocessing_spawn (45 sec 214 ms), test_faulthandler (42 sec 991 ms), test_compileall (40 sec 957 ms)
0:00:49 [ 34/418] test_tk skipped -- running: test_compile (46 sec 409 ms), test_lib2to3 (46 sec 652 ms), test_multiprocessing_spawn (47 sec 953 ms), test_faulthandler (45 sec 730 ms), test_compileall (43 sec 696 ms)
test_tk skipped -- No module named '_tkinter'
0:00:53 [ 35/418] test_weakref passed -- running: test_compile (49 sec 872 ms), test_lib2to3 (50 sec 115 ms), test_multiprocessing_spawn (51 sec 416 ms), test_faulthandler (49 sec 193 ms), test_compileall (47 sec 159 ms)
0:00:54 [ 36/418] test_fileinput passed -- running: test_compile (51 sec 11 ms), test_lib2to3 (51 sec 254 ms), test_multiprocessing_spawn (52 sec 555 ms), test_faulthandler (50 sec 332 ms), test_compileall (48 sec 298 ms)
0:00:54 [ 37/418] test_winreg skipped -- running: test_compile (51 sec 198 ms), test_lib2to3 (51 sec 441 ms), test_multiprocessing_spawn (52 sec 742 ms), test_faulthandler (50 sec 519 ms), test_compileall (48 sec 485 ms)
test_winreg skipped -- No module named 'winreg'
0:00:55 [ 38/418] test_pyexpat passed -- running: test_compile (51 sec 749 ms), test_lib2to3 (51 sec 992 ms), test_multiprocessing_spawn (53 sec 293 ms), test_faulthandler (51 sec 70 ms), test_compileall (49 sec 36 ms)
0:00:58 [ 39/418] test_datetime passed -- running: test_compile (54 sec 955 ms), test_lib2to3 (55 sec 198 ms), test_multiprocessing_spawn (56 sec 499 ms), test_faulthandler (54 sec 276 ms), test_compileall (52 sec 242 ms)
0:00:58 [ 40/418] test_gc passed -- running: test_compile (55 sec 251 ms), test_lib2to3 (55 sec 494 ms), test_multiprocessing_spawn (56 sec 795 ms), test_faulthandler (54 sec 572 ms), test_compileall (52 sec 538 ms)
0:00:59 [ 41/418] test_socketserver skipped (resource denied) -- running: test_compile (55 sec 641 ms), test_lib2to3 (55 sec 884 ms), test_multiprocessing_spawn (57 sec 185 ms), test_faulthandler (54 sec 962 ms), test_compileall (52 sec 928 ms)
test_socketserver skipped -- Use of the 'network' resource not enabled
0:00:59 [ 42/418] test_locale passed -- running: test_compile (56 sec 58 ms), test_lib2to3 (56 sec 301 ms), test_multiprocessing_spawn (57 sec 602 ms), test_faulthandler (55 sec 378 ms), test_compileall (53 sec 345 ms)
0:00:59 [ 43/418] test_univnewlines passed -- running: test_compile (56 sec 544 ms), test_lib2to3 (56 sec 787 ms), test_multiprocessing_spawn (58 sec 88 ms), test_faulthandler (55 sec 865 ms), test_compileall (53 sec 831 ms)
0:01:00 [ 44/418] test_asyncore passed -- running: test_compile (56 sec 673 ms), test_lib2to3 (56 sec 916 ms), test_multiprocessing_spawn (58 sec 217 ms), test_faulthandler (55 sec 994 ms), test_compileall (53 sec 960 ms)
0:01:00 [ 45/418] test_metaclass passed -- running: test_compile (56 sec 761 ms), test_lib2to3 (57 sec 4 ms), test_multiprocessing_spawn (58 sec 305 ms), test_faulthandler (56 sec 81 ms), test_compileall (54 sec 48 ms)
0:01:00 [ 46/418] test_unary passed -- running: test_compile (57 sec 415 ms), test_lib2to3 (57 sec 658 ms), test_multiprocessing_spawn (58 sec 959 ms), test_faulthandler (56 sec 736 ms), test_compileall (54 sec 702 ms)
0:01:00 [ 47/418] test_imghdr passed -- running: test_compile (57 sec 574 ms), test_lib2to3 (57 sec 817 ms), test_multiprocessing_spawn (59 sec 118 ms), test_faulthandler (56 sec 895 ms), test_compileall (54 sec 861 ms)
0:01:01 [ 48/418] test_decimal passed -- running: test_compile (57 sec 674 ms), test_lib2to3 (57 sec 917 ms), test_multiprocessing_spawn (59 sec 218 ms), test_faulthandler (56 sec 994 ms), test_compileall (54 sec 961 ms)
0:01:02 [ 49/418] test_cprofile passed -- running: test_compile (59 sec 273 ms), test_lib2to3 (59 sec 517 ms), test_multiprocessing_spawn (1 min 817 ms), test_faulthandler (58 sec 594 ms), test_compileall (56 sec 561 ms)
0:01:03 [ 50/418] test_array passed -- running: test_compile (1 min 88 ms), test_lib2to3 (1 min 331 ms), test_multiprocessing_spawn (1 min 1 sec), test_faulthandler (59 sec 409 ms), test_compileall (57 sec 375 ms)
0:01:03 [ 51/418] test_modulefinder passed -- running: test_compile (1 min 487 ms), test_lib2to3 (1 min 731 ms), test_multiprocessing_spawn (1 min 2 sec), test_faulthandler (59 sec 808 ms), test_compileall (57 sec 775 ms)
0:01:05 [ 52/418] test_compile passed (59 sec 549 ms) -- running: test_lib2to3 (1 min 2 sec), test_multiprocessing_spawn (1 min 3 sec), test_faulthandler (1 min 1 sec), test_compileall (59 sec 355 ms)
0:01:05 [ 53/418] test_faulthandler passed (59 sec 302 ms) -- running: test_lib2to3 (1 min 2 sec), test_multiprocessing_spawn (1 min 3 sec), test_compileall (59 sec 644 ms)
0:01:06 [ 54/418] test_binop passed -- running: test_lib2to3 (1 min 2 sec), test_multiprocessing_spawn (1 min 4 sec), test_compileall (1 min 21 ms)
0:01:06 [ 55/418] test_file passed -- running: test_lib2to3 (1 min 3 sec), test_multiprocessing_spawn (1 min 5 sec), test_compileall (1 min 811 ms)
0:01:08 [ 56/418] test_iter passed -- running: test_lib2to3 (1 min 5 sec), test_multiprocessing_spawn (1 min 6 sec), test_compileall (1 min 2 sec)
0:01:08 [ 57/418] test_doctest passed -- running: test_lib2to3 (1 min 5 sec), test_multiprocessing_spawn (1 min 6 sec), test_compileall (1 min 2 sec)
0:01:09 [ 58/418] test_largefile passed -- running: test_lib2to3 (1 min 5 sec), test_multiprocessing_spawn (1 min 7 sec), test_compileall (1 min 2 sec)
0:01:09 [ 59/418] test_winconsoleio skipped -- running: test_lib2to3 (1 min 6 sec), test_multiprocessing_spawn (1 min 7 sec), test_compileall (1 min 3 sec)
test_winconsoleio skipped -- test only relevant on win32
0:01:09 [ 60/418] test_compare passed -- running: test_lib2to3 (1 min 6 sec), test_multiprocessing_spawn (1 min 7 sec), test_compileall (1 min 3 sec)
0:01:10 [ 61/418] test_compileall passed (1 min 1 sec) -- running: test_lib2to3 (1 min 6 sec), test_multiprocessing_spawn (1 min 8 sec)
0:01:10 [ 62/418] test_sys_setprofile passed -- running: test_lib2to3 (1 min 7 sec), test_multiprocessing_spawn (1 min 8 sec)
0:01:10 [ 63/418] test_operator passed -- running: test_lib2to3 (1 min 7 sec), test_multiprocessing_spawn (1 min 8 sec)
0:01:11 [ 64/418] test_urlparse passed -- running: test_lib2to3 (1 min 8 sec), test_multiprocessing_spawn (1 min 9 sec)
0:01:11 [ 65/418] test_codecmaps_kr passed -- running: test_lib2to3 (1 min 8 sec), test_multiprocessing_spawn (1 min 9 sec)
0:01:12 [ 66/418] test_errno passed -- running: test_lib2to3 (1 min 8 sec), test_multiprocessing_spawn (1 min 10 sec)
0:01:12 [ 67/418] test_textwrap passed -- running: test_lib2to3 (1 min 9 sec), test_multiprocessing_spawn (1 min 10 sec)
0:01:12 [ 68/418] test_gettext passed -- running: test_lib2to3 (1 min 9 sec), test_multiprocessing_spawn (1 min 11 sec)
0:01:13 [ 69/418] test_future passed -- running: test_lib2to3 (1 min 10 sec), test_multiprocessing_spawn (1 min 12 sec), test_pickle (30 sec 55 ms)
0:01:14 [ 70/418] test_runpy passed -- running: test_lib2to3 (1 min 10 sec), test_multiprocessing_spawn (1 min 12 sec), test_pickle (30 sec 254 ms)
0:01:14 [ 71/418] test_copyreg passed -- running: test_lib2to3 (1 min 11 sec), test_multiprocessing_spawn (1 min 12 sec), test_pickle (30 sec 746 ms)
0:01:14 [ 72/418] test_strftime passed -- running: test_lib2to3 (1 min 11 sec), test_multiprocessing_spawn (1 min 12 sec), test_pickle (30 sec 838 ms)
0:01:14 [ 73/418] test_readline skipped -- running: test_lib2to3 (1 min 11 sec), test_multiprocessing_spawn (1 min 12 sec), test_pickle (30 sec 882 ms)
test_readline skipped -- No module named 'readline'
0:01:15 [ 74/418] test_smtpnet skipped (resource denied) -- running: test_lib2to3 (1 min 12 sec), test_multiprocessing_spawn (1 min 13 sec), test_pickle (31 sec 509 ms)
test_smtpnet skipped -- Use of the 'network' resource not enabled
0:01:15 [ 75/418] test_atexit passed -- running: test_lib2to3 (1 min 12 sec), test_multiprocessing_spawn (1 min 13 sec), test_pickle (31 sec 835 ms)
0:01:16 [ 76/418] test_decorators passed -- running: test_lib2to3 (1 min 12 sec), test_multiprocessing_spawn (1 min 14 sec), test_pickle (32 sec 248 ms)
0:01:16 [ 77/418] test_userdict passed -- running: test_lib2to3 (1 min 13 sec), test_multiprocessing_spawn (1 min 14 sec), test_pickle (32 sec 945 ms)
0:01:17 [ 78/418] test_scope passed -- running: test_lib2to3 (1 min 14 sec), test_multiprocessing_spawn (1 min 15 sec), test_pickle (33 sec 993 ms)
0:01:19 [ 79/418] test_fcntl passed -- running: test_lib2to3 (1 min 16 sec), test_multiprocessing_spawn (1 min 17 sec), test_pickle (35 sec 488 ms)
0:01:20 [ 80/418] test_pow passed -- running: test_lib2to3 (1 min 17 sec), test_multiprocessing_spawn (1 min 18 sec), test_pickle (36 sec 696 ms)
0:01:21 [ 81/418] test_bufio passed -- running: test_lib2to3 (1 min 17 sec), test_multiprocessing_spawn (1 min 19 sec), test_pickle (37 sec 307 ms)
0:01:21 [ 82/418] test_timeit passed -- running: test_lib2to3 (1 min 18 sec), test_multiprocessing_spawn (1 min 19 sec), test_pickle (37 sec 789 ms)
0:01:22 [ 83/418] test_wsgiref passed -- running: test_lib2to3 (1 min 18 sec), test_multiprocessing_spawn (1 min 20 sec), test_pickle (38 sec 254 ms)
0:01:22 [ 84/418] test_raise passed -- running: test_lib2to3 (1 min 19 sec), test_multiprocessing_spawn (1 min 20 sec), test_pickle (38 sec 486 ms)
0:01:22 [ 85/418] test_pickle passed (37 sec 975 ms) -- running: test_lib2to3 (1 min 19 sec), test_multiprocessing_spawn (1 min 20 sec)
0:01:22 [ 86/418] test_long passed -- running: test_lib2to3 (1 min 19 sec), test_multiprocessing_spawn (1 min 20 sec)
0:01:22 [ 87/418] test_opcodes passed -- running: test_lib2to3 (1 min 19 sec), test_multiprocessing_spawn (1 min 20 sec)
0:01:24 [ 88/418] test_tempfile passed -- running: test_lib2to3 (1 min 21 sec), test_multiprocessing_spawn (1 min 23 sec)
0:01:25 [ 89/418] test_zipapp passed -- running: test_lib2to3 (1 min 21 sec), test_multiprocessing_spawn (1 min 23 sec)
0:01:25 [ 90/418] test_copy passed -- running: test_lib2to3 (1 min 22 sec), test_multiprocessing_spawn (1 min 23 sec)
0:01:26 [ 91/418] test_shutil passed -- running: test_lib2to3 (1 min 22 sec), test_multiprocessing_spawn (1 min 24 sec)
0:01:26 [ 92/418] test_difflib passed -- running: test_lib2to3 (1 min 23 sec), test_multiprocessing_spawn (1 min 24 sec)
0:01:26 [ 93/418] test_string_literals passed -- running: test_lib2to3 (1 min 23 sec), test_multiprocessing_spawn (1 min 24 sec)
0:01:26 [ 94/418] test_genexps passed -- running: test_lib2to3 (1 min 23 sec), test_multiprocessing_spawn (1 min 24 sec)
0:01:26 [ 95/418] test_cmd_line passed -- running: test_lib2to3 (1 min 23 sec), test_multiprocessing_spawn (1 min 24 sec)
0:01:26 [ 96/418] test_asdl_parser passed -- running: test_lib2to3 (1 min 23 sec), test_multiprocessing_spawn (1 min 25 sec)
0:01:27 [ 97/418] test_typechecks passed -- running: test_lib2to3 (1 min 24 sec), test_multiprocessing_spawn (1 min 25 sec)
0:01:27 [ 98/418] test_zipfile64 skipped (resource denied) -- running: test_lib2to3 (1 min 24 sec), test_multiprocessing_spawn (1 min 25 sec)
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
0:01:27 [ 99/418] test_lib2to3 passed (1 min 23 sec) -- running: test_multiprocessing_spawn (1 min 25 sec)
0:01:27 [100/418] test_sys_settrace passed -- running: test_multiprocessing_spawn (1 min 26 sec)
0:01:28 [101/418] test_collections passed -- running: test_multiprocessing_spawn (1 min 26 sec)
0:01:28 [102/418] test_ucn passed -- running: test_multiprocessing_spawn (1 min 26 sec)
0:01:28 [103/418] test_telnetlib passed -- running: test_multiprocessing_spawn (1 min 26 sec)
0:01:28 [104/418] test_openpty passed -- running: test_multiprocessing_spawn (1 min 26 sec)
0:01:28 [105/418] test_netrc passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:28 [106/418] test_support passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:29 [107/418] test_dtrace passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:29 [108/418] test_format passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:29 [109/418] test_ttk_textonly skipped -- running: test_multiprocessing_spawn (1 min 27 sec)
test_ttk_textonly skipped -- No module named '_tkinter'
0:01:29 [110/418] test_doctest2 passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:29 [111/418] test_filecmp passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:29 [112/418] test_imp passed -- running: test_multiprocessing_spawn (1 min 27 sec)
0:01:30 [113/418] test_stringprep passed -- running: test_multiprocessing_spawn (1 min 28 sec)
0:01:30 [114/418] test_gdb skipped -- running: test_multiprocessing_spawn (1 min 28 sec)
test_gdb skipped -- Couldn't find gdb on the path
0:01:30 [115/418] test_hmac passed -- running: test_multiprocessing_spawn (1 min 28 sec)
0:01:30 [116/418] test_urllib2net skipped (resource denied) -- running: test_multiprocessing_spawn (1 min 28 sec)
test_urllib2net skipped -- Use of the 'network' resource not enabled
0:01:31 [117/418] test_genericclass passed -- running: test_multiprocessing_spawn (1 min 29 sec)
0:01:32 [118/418] test_keyword passed -- running: test_multiprocessing_spawn (1 min 30 sec)
0:01:32 [119/418] test_numeric_tower passed -- running: test_multiprocessing_spawn (1 min 30 sec)
0:01:32 [120/418] test_iterlen passed -- running: test_multiprocessing_spawn (1 min 30 sec)
0:01:33 [121/418] test_print passed -- running: test_multiprocessing_spawn (1 min 31 sec)
0:01:33 [122/418] test_bdb passed -- running: test_multiprocessing_spawn (1 min 31 sec)
0:01:33 [123/418] test_cgitb passed -- running: test_multiprocessing_spawn (1 min 31 sec)
0:01:34 [124/418] test_xml_etree_c passed -- running: test_multiprocessing_spawn (1 min 32 sec)
0:01:34 [125/418] test_htmlparser passed -- running: test_multiprocessing_spawn (1 min 32 sec)
0:01:34 [126/418] test_future3 passed -- running: test_multiprocessing_spawn (1 min 32 sec)
0:01:35 [127/418] test_descrtut passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [128/418] test_fractions passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [129/418] test_coroutines passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [130/418] test_mmap passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [131/418] test__osx_support passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [132/418] test_augassign passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [133/418] test_fnmatch passed -- running: test_multiprocessing_spawn (1 min 33 sec)
0:01:35 [134/418/1] test_os failed -- running: test_multiprocessing_spawn (1 min 33 sec)
test test_os failed -- Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test_os.py", line 1118, in test_mode
    self.assertEqual(stat.S_IMODE(os.stat(path).st_mode), 0o555)
AssertionError: 1389 != 365
0:01:35 [135/418/1] test_descr passed -- running: test_multiprocessing_spawn (1 min 34 sec)
0:01:36 [136/418/1] test_xmlrpc_net skipped (resource denied) -- running: test_multiprocessing_spawn (1 min 34 sec)
test_xmlrpc_net skipped -- Use of the 'network' resource not enabled
0:01:36 [137/418/1] test_codecmaps_cn passed -- running: test_multiprocessing_spawn (1 min 34 sec)
0:01:36 [138/418/1] test_subclassinit passed -- running: test_multiprocessing_spawn (1 min 35 sec)
0:01:37 [139/418/1] test_baseexception passed -- running: test_multiprocessing_spawn (1 min 35 sec)
0:01:37 [140/418/1] test_poplib passed -- running: test_multiprocessing_spawn (1 min 35 sec)
0:01:37 [141/418/1] test_pkgimport passed -- running: test_multiprocessing_spawn (1 min 35 sec)
0:01:38 [142/418/1] test_devpoll skipped -- running: test_multiprocessing_spawn (1 min 36 sec)
test_devpoll skipped -- test works only on Solaris OS family
0:01:39 [143/418/1] test_sax passed -- running: test_multiprocessing_spawn (1 min 37 sec)
0:01:39 [144/418/1] test_traceback passed -- running: test_multiprocessing_spawn (1 min 37 sec)
0:01:39 [145/418/1] test_re passed -- running: test_multiprocessing_spawn (1 min 37 sec)
0:01:41 [146/418/1] test_http_cookies passed -- running: test_multiprocessing_spawn (1 min 39 sec)
0:01:41 [147/418/1] test_complex passed -- running: test_multiprocessing_spawn (1 min 39 sec)
0:01:41 [148/418/1] test_poll passed -- running: test_multiprocessing_spawn (1 min 39 sec)
0:01:42 [149/418/1] test_getopt passed -- running: test_multiprocessing_spawn (1 min 40 sec)
0:01:42 [150/418/1] test_grammar passed -- running: test_multiprocessing_spawn (1 min 40 sec)
0:01:44 [151/418/1] test_ensurepip passed -- running: test_multiprocessing_spawn (1 min 42 sec)
0:01:44 [152/418/1] test_urllib2 passed -- running: test_multiprocessing_spawn (1 min 42 sec)
0:01:44 [153/418/1] test_tcl skipped -- running: test_multiprocessing_spawn (1 min 42 sec)
test_tcl skipped -- No module named '_tkinter'
0:01:45 [154/418/1] test_threadsignals passed -- running: test_multiprocessing_spawn (1 min 43 sec)
0:01:45 [155/418/1] test_parser passed -- running: test_multiprocessing_spawn (1 min 43 sec)
0:01:46 [156/418/1] test_csv passed -- running: test_multiprocessing_spawn (1 min 44 sec)
0:01:46 [157/418/1] test_codecmaps_hk passed -- running: test_multiprocessing_spawn (1 min 44 sec)
0:01:46 [158/418/1] test_import passed -- running: test_multiprocessing_spawn (1 min 45 sec)
0:01:46 [159/418/1] test_sort passed -- running: test_multiprocessing_spawn (1 min 45 sec)
0:01:47 [160/418/1] test_unittest passed -- running: test_multiprocessing_spawn (1 min 45 sec)
0:01:47 [161/418/1] test_dict passed -- running: test_multiprocessing_spawn (1 min 45 sec)
0:01:47 [162/418/1] test_symtable passed -- running: test_multiprocessing_spawn (1 min 45 sec)
0:01:47 [163/418/1] test___all__ passed -- running: test_multiprocessing_spawn (1 min 45 sec)
0:01:47 [164/418/1] test_yield_from passed -- running: test_multiprocessing_spawn (1 min 46 sec)
0:01:48 [165/418/1] test_startfile skipped -- running: test_multiprocessing_spawn (1 min 46 sec)
test_startfile skipped -- object <module 'os' from '/data/prj/python/git/python3-3.8/Lib/os.py'> has no attribute 'startfile'
0:01:48 [166/418/1] test_secrets passed -- running: test_multiprocessing_spawn (1 min 46 sec)
0:01:48 [167/418/1] test_rlcompleter passed -- running: test_multiprocessing_spawn (1 min 46 sec)
0:01:48 [168/418/1] test_pulldom passed -- running: test_multiprocessing_spawn (1 min 46 sec)
0:01:49 [169/418/1] test_getpass passed -- running: test_multiprocessing_spawn (1 min 47 sec)
0:01:50 [170/418/1] test_codecmaps_tw passed -- running: test_multiprocessing_spawn (1 min 48 sec)
0:01:50 [171/418/1] test_shelve passed -- running: test_multiprocessing_spawn (1 min 48 sec)
0:01:50 [172/418/1] test_dictviews passed -- running: test_multiprocessing_spawn (1 min 49 sec)
0:01:51 [173/418/1] test_pkgutil passed -- running: test_multiprocessing_spawn (1 min 49 sec)
0:01:51 [174/418/1] test_normalization passed -- running: test_multiprocessing_spawn (1 min 49 sec)
0:01:52 [175/418/1] test_abc passed -- running: test_multiprocessing_spawn (1 min 50 sec)
0:01:53 [176/418/1] test_inspect passed -- running: test_multiprocessing_forkserver (30 sec 727 ms), test_multiprocessing_spawn (1 min 51 sec)
0:01:53 [177/418/1] test_nis passed -- running: test_multiprocessing_forkserver (31 sec 245 ms), test_multiprocessing_spawn (1 min 51 sec)
0:01:53 [178/418/1] test_unicode passed -- running: test_multiprocessing_forkserver (31 sec 296 ms), test_multiprocessing_spawn (1 min 51 sec)
0:01:54 [179/418/1] test_glob passed -- running: test_multiprocessing_forkserver (31 sec 694 ms), test_multiprocessing_spawn (1 min 52 sec)
0:01:54 [180/418/1] test_future4 passed -- running: test_multiprocessing_forkserver (32 sec 307 ms), test_multiprocessing_spawn (1 min 52 sec)
0:01:55 [181/418/1] test_codecencodings_iso2022 passed -- running: test_multiprocessing_forkserver (32 sec 713 ms), test_multiprocessing_spawn (1 min 53 sec)
0:01:55 [182/418/1] test_base64 passed -- running: test_multiprocessing_forkserver (32 sec 759 ms), test_multiprocessing_spawn (1 min 53 sec)
0:01:55 [183/418/1] test_dbm passed -- running: test_multiprocessing_forkserver (33 sec 280 ms), test_multiprocessing_spawn (1 min 53 sec)
0:01:55 [184/418/1] test_dict_version passed -- running: test_multiprocessing_forkserver (33 sec 330 ms), test_multiprocessing_spawn (1 min 53 sec)
0:01:55 [185/418/1] test_spwd skipped -- running: test_multiprocessing_forkserver (33 sec 331 ms), test_multiprocessing_spawn (1 min 53 sec)
test_spwd skipped -- No module named 'spwd'
0:01:57 [186/418/1] test_pyclbr passed -- running: test_multiprocessing_forkserver (34 sec 980 ms), test_multiprocessing_spawn (1 min 55 sec)
0:01:59 [187/418/1] test_json passed -- running: test_multiprocessing_forkserver (36 sec 803 ms), test_multiprocessing_spawn (1 min 57 sec)
0:01:59 [188/418/1] test_warnings passed -- running: test_multiprocessing_forkserver (37 sec 65 ms), test_multiprocessing_spawn (1 min 57 sec)
0:02:00 [189/418/1] test_frame passed -- running: test_multiprocessing_forkserver (37 sec 607 ms), test_multiprocessing_spawn (1 min 58 sec)
0:02:00 [190/418/1] test_exception_hierarchy passed -- running: test_multiprocessing_forkserver (38 sec 77 ms), test_multiprocessing_spawn (1 min 58 sec)
0:02:00 [191/418/1] test_xml_dom_minicompat passed -- running: test_multiprocessing_forkserver (38 sec 480 ms), test_multiprocessing_spawn (1 min 59 sec)
0:02:01 [192/418/1] test_osx_env passed -- running: test_multiprocessing_forkserver (38 sec 896 ms), test_multiprocessing_spawn (1 min 59 sec)
0:02:02 [193/418/1] test_module passed -- running: test_multiprocessing_forkserver (39 sec 892 ms), test_multiprocessing_spawn (2 min 510 ms)
0:02:04 [194/418/1] test_bytes passed -- running: test_multiprocessing_forkserver (42 sec 406 ms), test_multiprocessing_spawn (2 min 3 sec)
0:02:06 [195/418/1] test_urllib passed -- running: test_multiprocessing_fork (31 sec 267 ms), test_multiprocessing_forkserver (44 sec 475 ms), test_multiprocessing_spawn (2 min 5 sec), test_zipfile (31 sec 854 ms)
0:02:07 [196/418/1] test_shlex passed -- running: test_multiprocessing_fork (31 sec 971 ms), test_multiprocessing_forkserver (45 sec 180 ms), test_multiprocessing_spawn (2 min 5 sec), test_zipfile (32 sec 559 ms)
0:02:08 [197/418/1] test_urllib_response passed -- running: test_multiprocessing_fork (32 sec 678 ms), test_multiprocessing_forkserver (45 sec 886 ms), test_multiprocessing_spawn (2 min 6 sec), test_zipfile (33 sec 265 ms)
0:02:08 [198/418/1] test_mailbox passed -- running: test_multiprocessing_fork (33 sec 116 ms), test_multiprocessing_forkserver (46 sec 324 ms), test_multiprocessing_spawn (2 min 6 sec), test_zipfile (33 sec 703 ms)
0:02:09 [199/418/1] test_cmath passed -- running: test_multiprocessing_fork (33 sec 392 ms), test_multiprocessing_forkserver (46 sec 601 ms), test_multiprocessing_spawn (2 min 7 sec), test_zipfile (33 sec 980 ms)
0:02:09 [200/418/1] test_structmembers passed -- running: test_multiprocessing_fork (33 sec 578 ms), test_multiprocessing_forkserver (46 sec 786 ms), test_multiprocessing_spawn (2 min 7 sec), test_zipfile (34 sec 165 ms)
0:02:09 [201/418/1] test_dummy_thread passed -- running: test_multiprocessing_fork (34 sec 151 ms), test_multiprocessing_forkserver (47 sec 359 ms), test_multiprocessing_spawn (2 min 7 sec), test_zipfile (34 sec 738 ms)
0:02:18 [202/418/1] test_wait4 passed -- running: test_multiprocessing_fork (42 sec 791 ms), test_multiprocessing_forkserver (56 sec 124 ms), test_multiprocessing_spawn (2 min 16 sec), test_zipfile (43 sec 503 ms)
0:02:18 [203/418/1] test_docxmlrpc passed -- running: test_multiprocessing_fork (43 sec 43 ms), test_multiprocessing_forkserver (56 sec 252 ms), test_multiprocessing_spawn (2 min 16 sec), test_zipfile (43 sec 631 ms)
0:02:18 [204/418/1] test_ftplib passed -- running: test_multiprocessing_fork (43 sec 44 ms), test_multiprocessing_forkserver (56 sec 253 ms), test_multiprocessing_spawn (2 min 16 sec), test_zipfile (43 sec 631 ms)
0:02:19 [205/418/1] test_dbm_gnu skipped -- running: test_multiprocessing_fork (43 sec 957 ms), test_multiprocessing_forkserver (57 sec 166 ms), test_multiprocessing_spawn (2 min 17 sec), test_zipfile (44 sec 544 ms)
test_dbm_gnu skipped -- No module named '_gdbm'
0:02:19 [206/418/1] test_urllibnet skipped (resource denied) -- running: test_multiprocessing_fork (43 sec 988 ms), test_multiprocessing_forkserver (57 sec 196 ms), test_multiprocessing_spawn (2 min 17 sec), test_zipfile (44 sec 575 ms)
test_urllibnet skipped -- Use of the 'network' resource not enabled
0:02:20 [207/418/1] test_pipes passed -- running: test_multiprocessing_fork (45 sec 75 ms), test_multiprocessing_forkserver (58 sec 283 ms), test_multiprocessing_spawn (2 min 18 sec), test_zipfile (45 sec 662 ms)
0:02:22 [208/418/2] test_time failed -- running: test_multiprocessing_fork (46 sec 720 ms), test_multiprocessing_forkserver (59 sec 928 ms), test_multiprocessing_spawn (2 min 20 sec), test_zipfile (47 sec 307 ms)
test test_time failed -- multiple errors occurred; run in verbose mode for details
0:02:26 [209/418/2] test_hashlib passed -- running: test_multiprocessing_fork (50 sec 616 ms), test_multiprocessing_forkserver (1 min 3 sec), test_multiprocessing_spawn (2 min 24 sec), test_zipfile (51 sec 203 ms), test_tools (30 sec 546 ms)
0:02:28 [210/418/2] test_itertools passed -- running: test_multiprocessing_fork (52 sec 715 ms), test_multiprocessing_forkserver (1 min 5 sec), test_multiprocessing_spawn (2 min 26 sec), test_zipfile (53 sec 302 ms), test_tools (32 sec 645 ms)
0:02:28 [211/418/2] test_xml_etree passed -- running: test_multiprocessing_fork (52 sec 784 ms), test_multiprocessing_forkserver (1 min 5 sec), test_multiprocessing_spawn (2 min 26 sec), test_zipfile (53 sec 371 ms), test_tools (32 sec 714 ms)
0:02:28 [212/418/2] test_dynamicclassattribute passed -- running: test_multiprocessing_fork (53 sec 243 ms), test_multiprocessing_forkserver (1 min 6 sec), test_multiprocessing_spawn (2 min 27 sec), test_zipfile (53 sec 831 ms), test_tools (33 sec 174 ms)
0:02:28 [213/418/2] test_flufl passed -- running: test_multiprocessing_fork (53 sec 279 ms), test_multiprocessing_forkserver (1 min 6 sec), test_multiprocessing_spawn (2 min 27 sec), test_zipfile (53 sec 866 ms), test_tools (33 sec 209 ms)
0:02:29 [214/418/2] test_extcall passed -- running: test_io (30 sec 212 ms), test_multiprocessing_fork (53 sec 805 ms), test_multiprocessing_forkserver (1 min 7 sec), test_multiprocessing_spawn (2 min 27 sec), test_zipfile (54 sec 393 ms), test_tools (33 sec 735 ms)
0:02:34 [215/418/2] test_dis passed -- running: test_io (35 sec 312 ms), test_multiprocessing_fork (58 sec 906 ms), test_multiprocessing_forkserver (1 min 12 sec), test_multiprocessing_spawn (2 min 32 sec), test_zipfile (59 sec 493 ms), test_tools (38 sec 835 ms)
0:02:36 [216/418/2] test_grp passed -- running: test_io (37 sec 73 ms), test_multiprocessing_fork (1 min 667 ms), test_multiprocessing_forkserver (1 min 13 sec), test_multiprocessing_spawn (2 min 34 sec), test_zipfile (1 min 1 sec), test_tools (40 sec 597 ms)
0:02:36 [217/418/2] test_index passed -- running: test_io (37 sec 493 ms), test_multiprocessing_fork (1 min 1 sec), test_multiprocessing_forkserver (1 min 14 sec), test_multiprocessing_spawn (2 min 34 sec), test_zipfile (1 min 1 sec), test_tools (41 sec 17 ms)
0:02:37 [218/418/2] test_unicode_file_functions skipped -- running: test_io (37 sec 972 ms), test_multiprocessing_fork (1 min 1 sec), test_multiprocessing_forkserver (1 min 14 sec), test_multiprocessing_spawn (2 min 35 sec), test_zipfile (1 min 2 sec), test_tools (41 sec 496 ms)
test_unicode_file_functions skipped -- only NT+ and systems with Unicode-friendly filesystem encoding
0:02:37 [219/418/2] test_exception_variations passed -- running: test_io (38 sec 572 ms), test_multiprocessing_fork (1 min 2 sec), test_multiprocessing_forkserver (1 min 15 sec), test_multiprocessing_spawn (2 min 35 sec), test_zipfile (1 min 2 sec), test_tools (42 sec 96 ms)
0:02:38 [220/418/2] test_pstats passed -- running: test_io (39 sec 323 ms), test_multiprocessing_fork (1 min 2 sec), test_multiprocessing_forkserver (1 min 16 sec), test_multiprocessing_spawn (2 min 36 sec), test_zipfile (1 min 3 sec), test_tools (42 sec 847 ms)
0:02:39 [221/418/2] test_charmapcodec passed -- running: test_io (39 sec 836 ms), test_multiprocessing_fork (1 min 3 sec), test_multiprocessing_forkserver (1 min 16 sec), test_multiprocessing_spawn (2 min 37 sec), test_zipfile (1 min 4 sec), test_tools (43 sec 360 ms)
0:03:06 [222/418/2] test_io passed (1 min 6 sec) -- running: test_multiprocessing_fork (1 min 30 sec), test_multiprocessing_forkserver (1 min 44 sec), test_multiprocessing_spawn (3 min 4 sec), test_venv (37 sec 609 ms), test_zipfile (1 min 31 sec), test_pathlib (46 sec 860 ms), test_tools (1 min 10 sec), test_imaplib (44 sec 128 ms)
0:03:07 [223/418/2] test_imaplib passed (43 sec 150 ms) -- running: test_multiprocessing_fork (1 min 31 sec), test_multiprocessing_forkserver (1 min 45 sec), test_multiprocessing_spawn (3 min 5 sec), test_venv (38 sec 696 ms), test_zipfile (1 min 32 sec), test_pathlib (47 sec 946 ms), test_tools (1 min 11 sec)
0:03:12 [224/418/2] test_codecencodings_jp passed -- running: test_multiprocessing_fork (1 min 36 sec), test_multiprocessing_forkserver (1 min 50 sec), test_multiprocessing_spawn (3 min 10 sec), test_venv (43 sec 570 ms), test_subprocess (33 sec 382 ms), test_zipfile (1 min 37 sec), test_pathlib (52 sec 820 ms), test_tools (1 min 16 sec)
0:03:12 [225/418/2] test_stat passed -- running: test_multiprocessing_fork (1 min 36 sec), test_multiprocessing_forkserver (1 min 50 sec), test_multiprocessing_spawn (3 min 10 sec), test_venv (43 sec 571 ms), test_subprocess (33 sec 383 ms), test_zipfile (1 min 37 sec), test_pathlib (52 sec 821 ms), test_tools (1 min 16 sec)
0:03:14 [226/418/2] test_syslog passed -- running: test_multiprocessing_fork (1 min 38 sec), test_multiprocessing_forkserver (1 min 51 sec), test_multiprocessing_spawn (3 min 12 sec), test_venv (45 sec 299 ms), test_subprocess (35 sec 111 ms), test_zipfile (1 min 39 sec), test_pathlib (54 sec 549 ms), test_tools (1 min 18 sec)
0:03:14 [227/418/2] test_bigaddrspace passed -- running: test_multiprocessing_fork (1 min 38 sec), test_multiprocessing_forkserver (1 min 52 sec), test_multiprocessing_spawn (3 min 12 sec), test_venv (45 sec 731 ms), test_subprocess (35 sec 543 ms), test_zipfile (1 min 39 sec), test_pathlib (54 sec 982 ms), test_tools (1 min 18 sec)
0:03:15 [228/418/2] test_ioctl passed -- running: test_multiprocessing_fork (1 min 40 sec), test_multiprocessing_forkserver (1 min 53 sec), test_multiprocessing_spawn (3 min 13 sec), test_venv (46 sec 906 ms), test_subprocess (36 sec 718 ms), test_zipfile (1 min 40 sec), test_pathlib (56 sec 156 ms), test_tools (1 min 20 sec)
0:03:16 [229/418/2] test_tix skipped -- running: test_multiprocessing_fork (1 min 40 sec), test_multiprocessing_forkserver (1 min 54 sec), test_multiprocessing_spawn (3 min 14 sec), test_venv (47 sec 608 ms), test_subprocess (37 sec 420 ms), test_zipfile (1 min 41 sec), test_pathlib (56 sec 859 ms), test_tools (1 min 20 sec)
test_tix skipped -- No module named '_tkinter'
0:03:19 [230/418/2] test_tools passed (1 min 22 sec) -- running: test_multiprocessing_fork (1 min 43 sec), test_multiprocessing_forkserver (1 min 56 sec), test_multiprocessing_spawn (3 min 17 sec), test_venv (50 sec 391 ms), test_subprocess (40 sec 203 ms), test_zipfile (1 min 44 sec), test_pathlib (59 sec 641 ms)
0:03:19 [231/418/2] test_zipfile passed (1 min 32 sec) -- running: test_multiprocessing_fork (1 min 44 sec), test_multiprocessing_forkserver (1 min 57 sec), test_multiprocessing_spawn (3 min 17 sec), test_venv (50 sec 873 ms), test_subprocess (40 sec 685 ms), test_pathlib (1 min 123 ms)
0:03:20 [232/418/2] test_pathlib passed (59 sec 106 ms) -- running: test_multiprocessing_fork (1 min 44 sec), test_multiprocessing_forkserver (1 min 57 sec), test_multiprocessing_spawn (3 min 18 sec), test_venv (51 sec 312 ms), test_subprocess (41 sec 124 ms)
0:03:20 [233/418/2] test_macpath passed -- running: test_multiprocessing_fork (1 min 44 sec), test_multiprocessing_forkserver (1 min 57 sec), test_multiprocessing_spawn (3 min 18 sec), test_venv (51 sec 361 ms), test_subprocess (41 sec 173 ms)
0:03:20 [234/418/2] test_codeop passed -- running: test_multiprocessing_fork (1 min 45 sec), test_multiprocessing_forkserver (1 min 58 sec), test_multiprocessing_spawn (3 min 18 sec), test_venv (51 sec 891 ms), test_subprocess (41 sec 703 ms)
0:03:20 [235/418/2] test_gzip passed -- running: test_multiprocessing_fork (1 min 45 sec), test_multiprocessing_forkserver (1 min 58 sec), test_multiprocessing_spawn (3 min 19 sec), test_venv (51 sec 939 ms), test_subprocess (41 sec 751 ms)
0:03:23 [236/418/2] test_site passed -- running: test_multiprocessing_fork (1 min 47 sec), test_multiprocessing_forkserver (2 min 1 sec), test_multiprocessing_spawn (3 min 21 sec), test_venv (54 sec 654 ms), test_subprocess (44 sec 466 ms)
0:03:27 [237/418/2] test_threadedtempfile passed -- running: test_multiprocessing_fork (1 min 51 sec), test_multiprocessing_forkserver (2 min 4 sec), test_multiprocessing_spawn (3 min 25 sec), test_venv (58 sec 515 ms), test_subprocess (48 sec 327 ms)
0:03:34 [238/418/2] test_wait3 passed -- running: test_multiprocessing_fork (1 min 58 sec), test_multiprocessing_forkserver (2 min 11 sec), test_multiprocessing_spawn (3 min 32 sec), test_venv (1 min 5 sec), test_subprocess (54 sec 897 ms)
0:03:35 [239/418/2] test_unpack passed -- running: test_multiprocessing_fork (1 min 59 sec), test_multiprocessing_forkserver (2 min 12 sec), test_multiprocessing_spawn (3 min 33 sec), test_venv (1 min 6 sec), test_subprocess (55 sec 934 ms)
0:03:35 [240/418/2] test_trace passed -- running: test_multiprocessing_fork (1 min 59 sec), test_multiprocessing_forkserver (2 min 13 sec), test_multiprocessing_spawn (3 min 33 sec), test_venv (1 min 6 sec), test_subprocess (56 sec 572 ms)
0:03:36 [241/418/2] test_slice passed -- running: test_multiprocessing_fork (2 min 907 ms), test_multiprocessing_forkserver (2 min 14 sec), test_multiprocessing_spawn (3 min 34 sec), test_venv (1 min 7 sec), test_subprocess (57 sec 483 ms)
0:03:38 [242/418/2] test_tarfile passed -- running: test_multiprocessing_fork (2 min 2 sec), test_multiprocessing_forkserver (2 min 15 sec), test_multiprocessing_spawn (3 min 36 sec), test_venv (1 min 9 sec), test_subprocess (59 sec 116 ms)
0:03:38 [243/418/2] test_marshal passed -- running: test_multiprocessing_fork (2 min 3 sec), test_multiprocessing_forkserver (2 min 16 sec), test_multiprocessing_spawn (3 min 37 sec), test_venv (1 min 9 sec), test_subprocess (59 sec 809 ms)
0:03:39 [244/418/2] test_property passed -- running: test_multiprocessing_fork (2 min 3 sec), test_multiprocessing_forkserver (2 min 17 sec), test_multiprocessing_spawn (3 min 37 sec), test_venv (1 min 10 sec), test_subprocess (1 min 377 ms)
0:03:40 [245/418/2] test_turtle skipped -- running: test_multiprocessing_fork (2 min 4 sec), test_multiprocessing_forkserver (2 min 17 sec), test_multiprocessing_spawn (3 min 38 sec), test_venv (1 min 11 sec), test_subprocess (1 min 988 ms)
test_turtle skipped -- No module named '_tkinter'
0:03:41 [246/418/2] test_binhex passed -- running: test_multiprocessing_fork (2 min 5 sec), test_multiprocessing_forkserver (2 min 18 sec), test_multiprocessing_spawn (3 min 39 sec), test_venv (1 min 12 sec), test_subprocess (1 min 1 sec)
0:03:41 [247/418/2] test_html passed -- running: test_multiprocessing_fork (2 min 6 sec), test_multiprocessing_forkserver (2 min 19 sec), test_multiprocessing_spawn (3 min 40 sec), test_venv (1 min 13 sec), test_subprocess (1 min 2 sec)
0:03:59 [248/418/2] test_quopri passed -- running: test_multiprocessing_fork (2 min 24 sec), test_multiprocessing_forkserver (2 min 37 sec), test_multiprocessing_spawn (3 min 57 sec), test_venv (1 min 30 sec), test_subprocess (1 min 20 sec), test_regrtest (36 sec 167 ms), test_bz2 (43 sec 206 ms)
0:04:09 [249/418/2] test_sys passed -- running: test_multiprocessing_fork (2 min 33 sec), test_multiprocessing_forkserver (2 min 47 sec), test_multiprocessing_spawn (4 min 7 sec), test_venv (1 min 40 sec), test_subprocess (1 min 30 sec), test_ctypes (33 sec 64 ms), test_regrtest (46 sec 88 ms), test_buffer (31 sec 432 ms), test_bz2 (53 sec 127 ms)
0:04:23 [250/418/2] test_threading passed -- running: test_multiprocessing_fork (2 min 47 sec), test_multiprocessing_forkserver (3 min 1 sec), test_multiprocessing_spawn (4 min 21 sec), test_venv (1 min 54 sec), test_subprocess (1 min 44 sec), test_ctypes (46 sec 976 ms), test_regrtest (1 min), test_buffer (45 sec 344 ms), test_bz2 (1 min 7 sec)
0:04:26 [251/418/2] test__locale passed -- running: test_multiprocessing_fork (2 min 51 sec), test_multiprocessing_forkserver (3 min 4 sec), test_multiprocessing_spawn (4 min 25 sec), test_venv (1 min 57 sec), test_subprocess (1 min 47 sec), test_ctypes (50 sec 277 ms), test_regrtest (1 min 3 sec), test_buffer (48 sec 644 ms), test_bz2 (1 min 10 sec)
0:04:28 [252/418/2] test___future__ passed -- running: test_multiprocessing_fork (2 min 52 sec), test_multiprocessing_forkserver (3 min 5 sec), test_multiprocessing_spawn (4 min 26 sec), test_venv (1 min 59 sec), test_subprocess (1 min 49 sec), test_ctypes (51 sec 864 ms), test_regrtest (1 min 4 sec), test_buffer (50 sec 232 ms), test_bz2 (1 min 11 sec)
0:04:33 [253/418/2] test_tuple passed -- running: test_multiprocessing_fork (2 min 57 sec), test_multiprocessing_forkserver (3 min 10 sec), test_multiprocessing_spawn (4 min 31 sec), test_venv (2 min 4 sec), test_subprocess (1 min 54 sec), test_ctypes (56 sec 655 ms), test_regrtest (1 min 9 sec), test_buffer (55 sec 22 ms), test_bz2 (1 min 16 sec)
0:04:34 [254/418/3] test_ctypes failed -- running: test_multiprocessing_fork (2 min 58 sec), test_multiprocessing_forkserver (3 min 12 sec), test_multiprocessing_spawn (4 min 32 sec), test_venv (2 min 5 sec), test_subprocess (1 min 55 sec), test_regrtest (1 min 10 sec), test_buffer (56 sec 261 ms), test_bz2 (1 min 17 sec)
test test_ctypes failed -- multiple errors occurred; run in verbose mode for details
0:04:35 [255/418/3] test_codecmaps_jp passed -- running: test_multiprocessing_fork (2 min 59 sec), test_multiprocessing_forkserver (3 min 12 sec), test_multiprocessing_spawn (4 min 33 sec), test_venv (2 min 6 sec), test_subprocess (1 min 56 sec), test_regrtest (1 min 11 sec), test_buffer (57 sec 124 ms), test_bz2 (1 min 18 sec)
0:04:38 [256/418/3] test_urllib2_localnet passed -- running: test_multiprocessing_fork (3 min 1 sec), test_multiprocessing_forkserver (3 min 14 sec), test_multiprocessing_spawn (4 min 35 sec), test_venv (2 min 8 sec), test_subprocess (1 min 58 sec), test_regrtest (1 min 13 sec), test_buffer (59 sec 86 ms), test_bz2 (1 min 20 sec)
0:04:38 [257/418/3] test_future5 passed -- running: test_multiprocessing_fork (3 min 2 sec), test_multiprocessing_forkserver (3 min 15 sec), test_multiprocessing_spawn (4 min 36 sec), test_venv (2 min 9 sec), test_subprocess (1 min 58 sec), test_regrtest (1 min 14 sec), test_buffer (59 sec 810 ms), test_bz2 (1 min 21 sec)
0:04:38 [258/418/3] test_heapq passed -- running: test_multiprocessing_fork (3 min 2 sec), test_multiprocessing_forkserver (3 min 15 sec), test_multiprocessing_spawn (4 min 36 sec), test_venv (2 min 9 sec), test_subprocess (1 min 58 sec), test_regrtest (1 min 14 sec), test_buffer (59 sec 860 ms), test_bz2 (1 min 21 sec)
0:04:38 [259/418/3] test_buffer passed (58 sec 346 ms) -- running: test_multiprocessing_fork (3 min 2 sec), test_multiprocessing_forkserver (3 min 15 sec), test_multiprocessing_spawn (4 min 36 sec), test_venv (2 min 9 sec), test_subprocess (1 min 59 sec), test_regrtest (1 min 14 sec), test_bz2 (1 min 21 sec)
0:04:38 [260/418/3] test_curses skipped (resource denied) -- running: test_multiprocessing_fork (3 min 2 sec), test_multiprocessing_forkserver (3 min 16 sec), test_multiprocessing_spawn (4 min 36 sec), test_venv (2 min 9 sec), test_subprocess (1 min 59 sec), test_regrtest (1 min 15 sec), test_bz2 (1 min 22 sec)
test_curses skipped -- Use of the 'curses' resource not enabled
0:04:39 [261/418/3] test_resource passed -- running: test_multiprocessing_fork (3 min 3 sec), test_multiprocessing_forkserver (3 min 16 sec), test_multiprocessing_spawn (4 min 37 sec), test_venv (2 min 10 sec), test_subprocess (2 min 345 ms), test_regrtest (1 min 15 sec), test_bz2 (1 min 22 sec)
0:04:39 [262/418/3] test_contextlib_async passed -- running: test_multiprocessing_fork (3 min 3 sec), test_multiprocessing_forkserver (3 min 16 sec), test_multiprocessing_spawn (4 min 37 sec), test_venv (2 min 10 sec), test_subprocess (2 min 356 ms), test_regrtest (1 min 15 sec), test_bz2 (1 min 22 sec)
0:04:40 [263/418/3] test_kqueue skipped -- running: test_multiprocessing_fork (3 min 4 sec), test_multiprocessing_forkserver (3 min 17 sec), test_multiprocessing_spawn (4 min 38 sec), test_venv (2 min 11 sec), test_subprocess (2 min 953 ms), test_regrtest (1 min 16 sec), test_bz2 (1 min 23 sec)
test_kqueue skipped -- test works only on BSD
0:04:40 [264/418/3] test_robotparser passed -- running: test_multiprocessing_fork (3 min 4 sec), test_multiprocessing_forkserver (3 min 17 sec), test_multiprocessing_spawn (4 min 38 sec), test_venv (2 min 11 sec), test_subprocess (2 min 1 sec), test_regrtest (1 min 16 sec), test_bz2 (1 min 23 sec)
0:04:40 [265/418/3] test_unicode_file skipped -- running: test_multiprocessing_fork (3 min 4 sec), test_multiprocessing_forkserver (3 min 18 sec), test_multiprocessing_spawn (4 min 38 sec), test_venv (2 min 11 sec), test_subprocess (2 min 1 sec), test_regrtest (1 min 17 sec), test_bz2 (1 min 24 sec)
test_unicode_file skipped -- No Unicode filesystem semantics on this platform.
0:04:40 [266/418/3] test_super passed -- running: test_multiprocessing_fork (3 min 5 sec), test_multiprocessing_forkserver (3 min 18 sec), test_multiprocessing_spawn (4 min 38 sec), test_venv (2 min 11 sec), test_subprocess (2 min 1 sec), test_regrtest (1 min 17 sec), test_bz2 (1 min 24 sec)
0:04:41 [267/418/3] test_zlib passed -- running: test_multiprocessing_fork (3 min 5 sec), test_multiprocessing_forkserver (3 min 18 sec), test_multiprocessing_spawn (4 min 39 sec), test_venv (2 min 12 sec), test_subprocess (2 min 2 sec), test_regrtest (1 min 17 sec), test_bz2 (1 min 24 sec)
0:04:42 [268/418/3] test_list passed -- running: test_multiprocessing_fork (3 min 6 sec), test_multiprocessing_forkserver (3 min 19 sec), test_multiprocessing_spawn (4 min 40 sec), test_venv (2 min 13 sec), test_subprocess (2 min 2 sec), test_regrtest (1 min 18 sec), test_bz2 (1 min 25 sec)
0:04:42 [269/418/3] test_ntpath passed -- running: test_multiprocessing_fork (3 min 6 sec), test_multiprocessing_forkserver (3 min 19 sec), test_multiprocessing_spawn (4 min 40 sec), test_venv (2 min 13 sec), test_subprocess (2 min 3 sec), test_regrtest (1 min 18 sec), test_bz2 (1 min 25 sec)
0:04:43 [270/418/3] test_uu passed -- running: test_multiprocessing_fork (3 min 7 sec), test_multiprocessing_forkserver (3 min 20 sec), test_multiprocessing_spawn (4 min 41 sec), test_venv (2 min 14 sec), test_subprocess (2 min 4 sec), test_regrtest (1 min 19 sec), test_bz2 (1 min 26 sec)
0:04:44 [271/418/3] test_builtin passed -- running: test_multiprocessing_fork (3 min 9 sec), test_multiprocessing_forkserver (3 min 22 sec), test_multiprocessing_spawn (4 min 43 sec), test_venv (2 min 15 sec), test_subprocess (2 min 5 sec), test_regrtest (1 min 21 sec), test_bz2 (1 min 28 sec)
0:04:46 [272/418/3] test_codecs passed -- running: test_multiprocessing_fork (3 min 10 sec), test_multiprocessing_forkserver (3 min 23 sec), test_multiprocessing_spawn (4 min 44 sec), test_venv (2 min 17 sec), test_subprocess (2 min 7 sec), test_regrtest (1 min 22 sec), test_bz2 (1 min 29 sec)
0:04:46 [273/418/3] test_colorsys passed -- running: test_multiprocessing_fork (3 min 11 sec), test_multiprocessing_forkserver (3 min 24 sec), test_multiprocessing_spawn (4 min 45 sec), test_venv (2 min 17 sec), test_subprocess (2 min 7 sec), test_regrtest (1 min 23 sec), test_bz2 (1 min 30 sec)
0:04:47 [274/418/3] test_keywordonlyarg passed -- running: test_multiprocessing_fork (3 min 11 sec), test_multiprocessing_forkserver (3 min 25 sec), test_multiprocessing_spawn (4 min 45 sec), test_venv (2 min 18 sec), test_subprocess (2 min 8 sec), test_regrtest (1 min 23 sec), test_bz2 (1 min 31 sec)
0:04:47 [275/418/3] test_bz2 passed (1 min 27 sec) -- running: test_multiprocessing_fork (3 min 12 sec), test_multiprocessing_forkserver (3 min 25 sec), test_multiprocessing_spawn (4 min 45 sec), test_venv (2 min 18 sec), test_subprocess (2 min 8 sec), test_regrtest (1 min 24 sec)
0:04:48 [276/418/3] test_structseq passed -- running: test_multiprocessing_fork (3 min 12 sec), test_multiprocessing_forkserver (3 min 26 sec), test_multiprocessing_spawn (4 min 46 sec), test_venv (2 min 19 sec), test_subprocess (2 min 9 sec), test_regrtest (1 min 25 sec)
0:04:49 [277/418/3] test_code passed -- running: test_multiprocessing_fork (3 min 14 sec), test_multiprocessing_forkserver (3 min 27 sec), test_multiprocessing_spawn (4 min 48 sec), test_venv (2 min 20 sec), test_subprocess (2 min 10 sec), test_regrtest (1 min 26 sec)
0:04:50 [278/418/3] test_userstring passed -- running: test_multiprocessing_fork (3 min 14 sec), test_multiprocessing_forkserver (3 min 27 sec), test_multiprocessing_spawn (4 min 48 sec), test_venv (2 min 21 sec), test_subprocess (2 min 11 sec), test_regrtest (1 min 26 sec)
0:04:51 [279/418/3] test_dummy_threading passed -- running: test_multiprocessing_fork (3 min 15 sec), test_multiprocessing_forkserver (3 min 28 sec), test_multiprocessing_spawn (4 min 49 sec), test_venv (2 min 22 sec), test_subprocess (2 min 11 sec), test_regrtest (1 min 27 sec)
0:04:51 [280/418/3] test_dynamic passed -- running: test_multiprocessing_fork (3 min 15 sec), test_multiprocessing_forkserver (3 min 28 sec), test_multiprocessing_spawn (4 min 49 sec), test_venv (2 min 22 sec), test_subprocess (2 min 12 sec), test_regrtest (1 min 27 sec)
0:04:51 [281/418/3] test_bisect passed -- running: test_multiprocessing_fork (3 min 15 sec), test_multiprocessing_forkserver (3 min 29 sec), test_multiprocessing_spawn (4 min 49 sec), test_venv (2 min 22 sec), test_subprocess (2 min 12 sec), test_regrtest (1 min 28 sec)
0:04:52 [282/418/3] test_bool passed -- running: test_multiprocessing_fork (3 min 16 sec), test_multiprocessing_forkserver (3 min 29 sec), test_multiprocessing_spawn (4 min 50 sec), test_venv (2 min 23 sec), test_subprocess (2 min 12 sec), test_regrtest (1 min 28 sec)
0:04:52 [283/418/3] test_codecencodings_cn passed -- running: test_multiprocessing_fork (3 min 17 sec), test_multiprocessing_forkserver (3 min 30 sec), test_multiprocessing_spawn (4 min 50 sec), test_venv (2 min 23 sec), test_subprocess (2 min 13 sec), test_regrtest (1 min 29 sec)
0:04:53 [284/418/3] test_pwd passed -- running: test_multiprocessing_fork (3 min 17 sec), test_multiprocessing_forkserver (3 min 31 sec), test_multiprocessing_spawn (4 min 51 sec), test_venv (2 min 24 sec), test_subprocess (2 min 14 sec), test_regrtest (1 min 30 sec)
0:04:55 [285/418/3] test_pickletools passed -- running: test_multiprocessing_fork (3 min 19 sec), test_multiprocessing_forkserver (3 min 32 sec), test_multiprocessing_spawn (4 min 53 sec), test_venv (2 min 26 sec), test_subprocess (2 min 16 sec), test_regrtest (1 min 31 sec)
0:04:55 [286/418/3] test_tracemalloc passed -- running: test_multiprocessing_fork (3 min 20 sec), test_multiprocessing_forkserver (3 min 33 sec), test_multiprocessing_spawn (4 min 53 sec), test_venv (2 min 26 sec), test_subprocess (2 min 16 sec), test_regrtest (1 min 32 sec)
0:04:57 [287/418/3] test_pkg passed -- running: test_multiprocessing_fork (3 min 22 sec), test_multiprocessing_forkserver (3 min 35 sec), test_multiprocessing_spawn (4 min 56 sec), test_venv (2 min 28 sec), test_subprocess (2 min 18 sec), test_regrtest (1 min 34 sec)
0:04:58 [288/418/3] test_regrtest passed (1 min 33 sec) -- running: test_multiprocessing_fork (3 min 22 sec), test_multiprocessing_forkserver (3 min 35 sec), test_multiprocessing_spawn (4 min 56 sec), test_venv (2 min 29 sec), test_subprocess (2 min 19 sec)
0:04:58 [289/418/3] test_sndhdr passed -- running: test_multiprocessing_fork (3 min 22 sec), test_multiprocessing_forkserver (3 min 36 sec), test_multiprocessing_spawn (4 min 56 sec), test_venv (2 min 29 sec), test_subprocess (2 min 19 sec)
0:04:59 [290/418/3] test_sqlite skipped -- running: test_multiprocessing_fork (3 min 23 sec), test_multiprocessing_forkserver (3 min 36 sec), test_multiprocessing_spawn (4 min 57 sec), test_venv (2 min 30 sec), test_subprocess (2 min 20 sec)
test_sqlite skipped -- No module named '_sqlite3'
0:04:59 [291/418/3] test_threading_local passed -- running: test_multiprocessing_fork (3 min 23 sec), test_multiprocessing_forkserver (3 min 36 sec), test_multiprocessing_spawn (4 min 57 sec), test_venv (2 min 30 sec), test_subprocess (2 min 20 sec)
0:04:59 [292/418/3] test_symbol passed -- running: test_multiprocessing_fork (3 min 24 sec), test_multiprocessing_forkserver (3 min 37 sec), test_multiprocessing_spawn (4 min 58 sec), test_venv (2 min 30 sec), test_subprocess (2 min 20 sec)
0:05:00 [293/418/3] test_ttk_guionly skipped -- running: test_multiprocessing_fork (3 min 24 sec), test_multiprocessing_forkserver (3 min 37 sec), test_multiprocessing_spawn (4 min 58 sec), test_venv (2 min 31 sec), test_subprocess (2 min 21 sec)
test_ttk_guionly skipped -- No module named '_tkinter'
0:05:01 [294/418/3] test_genericpath passed -- running: test_multiprocessing_fork (3 min 25 sec), test_multiprocessing_forkserver (3 min 38 sec), test_multiprocessing_spawn (4 min 59 sec), test_venv (2 min 32 sec), test_subprocess (2 min 22 sec)
0:05:02 [295/418/3] test_script_helper passed -- running: test_multiprocessing_fork (3 min 26 sec), test_multiprocessing_forkserver (3 min 39 sec), test_multiprocessing_spawn (5 min 355 ms), test_venv (2 min 33 sec), test_subprocess (2 min 23 sec)
0:05:02 [296/418/3] test_isinstance passed -- running: test_multiprocessing_fork (3 min 27 sec), test_multiprocessing_forkserver (3 min 40 sec), test_multiprocessing_spawn (5 min 899 ms), test_venv (2 min 33 sec), test_subprocess (2 min 23 sec)
0:05:03 [297/418/3] test_pydoc passed -- running: test_multiprocessing_fork (3 min 27 sec), test_multiprocessing_forkserver (3 min 40 sec), test_multiprocessing_spawn (5 min 1 sec), test_venv (2 min 34 sec), test_subprocess (2 min 24 sec)
0:05:04 [298/418/3] test_typing passed -- running: test_multiprocessing_fork (3 min 28 sec), test_multiprocessing_forkserver (3 min 41 sec), test_multiprocessing_spawn (5 min 2 sec), test_venv (2 min 35 sec), test_subprocess (2 min 25 sec)
0:05:05 [299/418/3] test_ordered_dict passed -- running: test_multiprocessing_fork (3 min 29 sec), test_multiprocessing_forkserver (3 min 42 sec), test_multiprocessing_spawn (5 min 3 sec), test_venv (2 min 36 sec), test_subprocess (2 min 26 sec)
0:05:06 [300/418/3] test_math passed -- running: test_multiprocessing_fork (3 min 30 sec), test_multiprocessing_forkserver (3 min 44 sec), test_multiprocessing_spawn (5 min 4 sec), test_venv (2 min 37 sec), test_subprocess (2 min 27 sec)
0:05:07 [301/418/3] test_abstract_numbers passed -- running: test_multiprocessing_fork (3 min 31 sec), test_multiprocessing_forkserver (3 min 44 sec), test_multiprocessing_spawn (5 min 5 sec), test_venv (2 min 38 sec), test_subprocess (2 min 27 sec)
0:05:07 [302/418/3] test_funcattrs passed -- running: test_multiprocessing_fork (3 min 31 sec), test_multiprocessing_forkserver (3 min 45 sec), test_multiprocessing_spawn (5 min 5 sec), test_venv (2 min 38 sec), test_subprocess (2 min 28 sec)
0:05:09 [303/418/3] test_deque passed -- running: test_multiprocessing_fork (3 min 33 sec), test_multiprocessing_forkserver (3 min 46 sec), test_multiprocessing_spawn (5 min 7 sec), test_venv (2 min 40 sec), test_subprocess (2 min 29 sec)
0:05:10 [304/418/3] test_platform passed -- running: test_multiprocessing_fork (3 min 34 sec), test_multiprocessing_forkserver (3 min 48 sec), test_multiprocessing_spawn (5 min 8 sec), test_venv (2 min 41 sec), test_subprocess (2 min 31 sec)
0:05:10 [305/418/3] test_dbm_dumb passed -- running: test_multiprocessing_fork (3 min 35 sec), test_multiprocessing_forkserver (3 min 48 sec), test_multiprocessing_spawn (5 min 8 sec), test_venv (2 min 41 sec), test_subprocess (2 min 31 sec)
0:05:11 [306/418/3] test_ipaddress passed -- running: test_multiprocessing_fork (3 min 35 sec), test_multiprocessing_forkserver (3 min 48 sec), test_multiprocessing_spawn (5 min 9 sec), test_venv (2 min 42 sec), test_subprocess (2 min 32 sec)
0:05:11 [307/418/3] test_cmd passed -- running: test_multiprocessing_fork (3 min 36 sec), test_multiprocessing_forkserver (3 min 49 sec), test_multiprocessing_spawn (5 min 10 sec), test_venv (2 min 43 sec), test_subprocess (2 min 32 sec)
0:05:13 [308/418/3] test_dataclasses passed -- running: test_multiprocessing_fork (3 min 37 sec), test_multiprocessing_forkserver (3 min 50 sec), test_multiprocessing_spawn (5 min 11 sec), test_venv (2 min 44 sec), test_subprocess (2 min 33 sec), test_ssl (30 sec 893 ms)
0:05:13 [309/418/3] test_lltrace passed -- running: test_multiprocessing_fork (3 min 37 sec), test_multiprocessing_forkserver (3 min 51 sec), test_multiprocessing_spawn (5 min 11 sec), test_venv (2 min 44 sec), test_subprocess (2 min 34 sec), test_ssl (31 sec 590 ms)
0:05:20 [310/418/3] test_cmd_line_script passed -- running: test_multiprocessing_fork (3 min 44 sec), test_multiprocessing_forkserver (3 min 58 sec), test_multiprocessing_spawn (5 min 18 sec), test_venv (2 min 51 sec), test_subprocess (2 min 41 sec), test_ssl (38 sec 527 ms)
0:05:22 [311/418/3] test_select passed -- running: test_multiprocessing_fork (3 min 46 sec), test_multiprocessing_forkserver (3 min 59 sec), test_multiprocessing_spawn (5 min 20 sec), test_venv (2 min 53 sec), test_subprocess (2 min 43 sec), test_ssl (40 sec 263 ms)
0:05:23 [312/418/3] test_plistlib passed -- running: test_multiprocessing_fork (3 min 47 sec), test_multiprocessing_forkserver (4 min 573 ms), test_multiprocessing_spawn (5 min 21 sec), test_venv (2 min 54 sec), test_subprocess (2 min 43 sec), test_ssl (40 sec 970 ms)
0:05:23 [313/418/3] test_int_literal passed -- running: test_multiprocessing_fork (3 min 47 sec), test_multiprocessing_forkserver (4 min 981 ms), test_multiprocessing_spawn (5 min 21 sec), test_venv (2 min 54 sec), test_subprocess (2 min 44 sec), test_ssl (41 sec 378 ms)
0:05:26 [314/418/3] test_exceptions passed -- running: test_multiprocessing_fork (3 min 50 sec), test_multiprocessing_forkserver (4 min 3 sec), test_multiprocessing_spawn (5 min 24 sec), test_venv (2 min 57 sec), test_subprocess (2 min 46 sec), test_ssl (43 sec 922 ms)
0:05:29 [315/418/4] test_httpservers failed -- running: test_multiprocessing_fork (3 min 53 sec), test_multiprocessing_forkserver (4 min 6 sec), test_multiprocessing_spawn (5 min 27 sec), test_venv (3 min 434 ms), test_subprocess (2 min 50 sec), test_ssl (47 sec 275 ms)
test test_httpservers failed -- multiple errors occurred; run in verbose mode for details
0:05:30 [316/418/4] test_finalization passed -- running: test_multiprocessing_fork (3 min 54 sec), test_multiprocessing_forkserver (4 min 7 sec), test_multiprocessing_spawn (5 min 28 sec), test_venv (3 min 1 sec), test_subprocess (2 min 51 sec), test_ssl (48 sec 192 ms)
0:05:35 [317/418/4] test_file_eintr passed -- running: test_multiprocessing_fork (3 min 59 sec), test_multiprocessing_forkserver (4 min 12 sec), test_multiprocessing_spawn (5 min 33 sec), test_venv (3 min 6 sec), test_subprocess (2 min 55 sec), test_logging (32 sec 311 ms), test_ssl (52 sec 987 ms)
0:05:38 [318/418/4] test_strtod passed -- running: test_multiprocessing_fork (4 min 3 sec), test_multiprocessing_forkserver (4 min 16 sec), test_multiprocessing_spawn (5 min 37 sec), test_venv (3 min 10 sec), test_subprocess (2 min 59 sec), test_logging (36 sec 207 ms), test_ssl (56 sec 882 ms)
0:05:40 [319/418/4] test_threaded_import passed -- running: test_multiprocessing_fork (4 min 4 sec), test_multiprocessing_forkserver (4 min 18 sec), test_multiprocessing_spawn (5 min 38 sec), test_venv (3 min 11 sec), test_subprocess (3 min 1 sec), test_logging (37 sec 804 ms), test_ssl (58 sec 479 ms)
0:05:44 [320/418/4] test_logging passed (40 sec 882 ms) -- running: test_multiprocessing_fork (4 min 8 sec), test_multiprocessing_forkserver (4 min 21 sec), test_multiprocessing_spawn (5 min 42 sec), test_venv (3 min 15 sec), test_subprocess (3 min 5 sec), test_ssl (1 min 2 sec), test_multiprocessing_main_handling (30 sec 589 ms)
0:05:45 [321/418/4] test_uuid passed -- running: test_multiprocessing_fork (4 min 9 sec), test_multiprocessing_forkserver (4 min 23 sec), test_multiprocessing_spawn (5 min 43 sec), test_venv (3 min 16 sec), test_subprocess (3 min 6 sec), test_ssl (1 min 3 sec), test_multiprocessing_main_handling (31 sec 930 ms)
0:05:45 [322/418/4] test_memoryview passed -- running: test_multiprocessing_fork (4 min 10 sec), test_multiprocessing_forkserver (4 min 23 sec), test_multiprocessing_spawn (5 min 43 sec), test_venv (3 min 16 sec), test_subprocess (3 min 6 sec), test_ssl (1 min 3 sec), test_multiprocessing_main_handling (32 sec 25 ms)
0:05:46 [323/418/4] test__opcode passed -- running: test_multiprocessing_fork (4 min 11 sec), test_multiprocessing_forkserver (4 min 24 sec), test_multiprocessing_spawn (5 min 44 sec), test_venv (3 min 17 sec), test_subprocess (3 min 7 sec), test_ssl (1 min 4 sec), test_multiprocessing_main_handling (33 sec 125 ms)
0:05:47 [324/418/4] test_http_cookiejar passed -- running: test_multiprocessing_fork (4 min 11 sec), test_multiprocessing_forkserver (4 min 24 sec), test_multiprocessing_spawn (5 min 45 sec), test_venv (3 min 18 sec), test_subprocess (3 min 8 sec), test_ssl (1 min 5 sec), test_multiprocessing_main_handling (33 sec 480 ms)
0:05:47 [325/418/4] test_mimetypes passed -- running: test_multiprocessing_fork (4 min 12 sec), test_multiprocessing_forkserver (4 min 25 sec), test_multiprocessing_spawn (5 min 45 sec), test_venv (3 min 18 sec), test_subprocess (3 min 8 sec), test_ssl (1 min 5 sec), test_multiprocessing_main_handling (34 sec 187 ms)
0:05:48 [326/418/4] test_defaultdict passed -- running: test_multiprocessing_fork (4 min 12 sec), test_multiprocessing_forkserver (4 min 25 sec), test_multiprocessing_spawn (5 min 46 sec), test_venv (3 min 19 sec), test_subprocess (3 min 8 sec), test_ssl (1 min 5 sec), test_multiprocessing_main_handling (34 sec 317 ms)
0:05:48 [327/418/4] test_signal passed -- running: test_multiprocessing_fork (4 min 12 sec), test_multiprocessing_forkserver (4 min 25 sec), test_multiprocessing_spawn (5 min 46 sec), test_venv (3 min 19 sec), test_subprocess (3 min 9 sec), test_ssl (1 min 6 sec), test_multiprocessing_main_handling (34 sec 447 ms)
0:05:48 [328/418/4] test_weakset passed -- running: test_multiprocessing_fork (4 min 13 sec), test_multiprocessing_forkserver (4 min 26 sec), test_multiprocessing_spawn (5 min 46 sec), test_venv (3 min 19 sec), test_subprocess (3 min 9 sec), test_ssl (1 min 6 sec), test_multiprocessing_main_handling (35 sec 67 ms)
0:05:48 [329/418/4] test_winsound skipped (resource denied) -- running: test_multiprocessing_fork (4 min 13 sec), test_multiprocessing_forkserver (4 min 26 sec), test_multiprocessing_spawn (5 min 46 sec), test_venv (3 min 19 sec), test_subprocess (3 min 9 sec), test_ssl (1 min 6 sec), test_multiprocessing_main_handling (35 sec 156 ms)
test_winsound skipped -- Use of the 'audio' resource not enabled
0:05:49 [330/418/4] test_pprint passed -- running: test_multiprocessing_fork (4 min 13 sec), test_multiprocessing_forkserver (4 min 26 sec), test_multiprocessing_spawn (5 min 47 sec), test_venv (3 min 20 sec), test_subprocess (3 min 9 sec), test_ssl (1 min 6 sec), test_multiprocessing_main_handling (35 sec 378 ms)
0:05:49 [331/418/4] test_crypt passed -- running: test_multiprocessing_fork (4 min 13 sec), test_multiprocessing_forkserver (4 min 26 sec), test_multiprocessing_spawn (5 min 47 sec), test_venv (3 min 20 sec), test_subprocess (3 min 10 sec), test_ssl (1 min 7 sec), test_multiprocessing_main_handling (35 sec 631 ms)
0:05:49 [332/418/4] test_with passed -- running: test_multiprocessing_fork (4 min 13 sec), test_multiprocessing_forkserver (4 min 26 sec), test_multiprocessing_spawn (5 min 47 sec), test_venv (3 min 20 sec), test_subprocess (3 min 10 sec), test_ssl (1 min 7 sec), test_multiprocessing_main_handling (35 sec 734 ms)
0:05:49 [333/418/4] test_timeout skipped (resource denied) -- running: test_multiprocessing_fork (4 min 14 sec), test_multiprocessing_forkserver (4 min 27 sec), test_multiprocessing_spawn (5 min 48 sec), test_venv (3 min 20 sec), test_subprocess (3 min 10 sec), test_ssl (1 min 7 sec), test_multiprocessing_main_handling (36 sec 238 ms)
test_timeout skipped -- Use of the 'network' resource not enabled
0:05:50 [334/418/4] test_enum passed -- running: test_multiprocessing_fork (4 min 14 sec), test_multiprocessing_forkserver (4 min 28 sec), test_multiprocessing_spawn (5 min 48 sec), test_venv (3 min 21 sec), test_subprocess (3 min 11 sec), test_ssl (1 min 8 sec), test_multiprocessing_main_handling (36 sec 838 ms)
0:05:50 [335/418/4] test_memoryio passed -- running: test_multiprocessing_fork (4 min 15 sec), test_multiprocessing_forkserver (4 min 28 sec), test_multiprocessing_spawn (5 min 48 sec), test_venv (3 min 21 sec), test_subprocess (3 min 11 sec), test_ssl (1 min 8 sec), test_multiprocessing_main_handling (37 sec 105 ms)
0:05:51 [336/418/4] test_lzma skipped -- running: test_multiprocessing_fork (4 min 15 sec), test_multiprocessing_forkserver (4 min 28 sec), test_multiprocessing_spawn (5 min 49 sec), test_venv (3 min 22 sec), test_subprocess (3 min 12 sec), test_ssl (1 min 9 sec), test_multiprocessing_main_handling (37 sec 460 ms)
test_lzma skipped -- No module named '_lzma'
0:05:53 [337/418/4] test_smtplib passed -- running: test_multiprocessing_fork (4 min 17 sec), test_multiprocessing_forkserver (4 min 30 sec), test_multiprocessing_spawn (5 min 51 sec), test_venv (3 min 24 sec), test_subprocess (3 min 14 sec), test_ssl (1 min 11 sec), test_multiprocessing_main_handling (39 sec 634 ms)
0:05:54 [338/418/4] test_range passed -- running: test_multiprocessing_fork (4 min 18 sec), test_multiprocessing_forkserver (4 min 32 sec), test_multiprocessing_spawn (5 min 52 sec), test_venv (3 min 25 sec), test_subprocess (3 min 15 sec), test_ssl (1 min 12 sec), test_multiprocessing_main_handling (40 sec 909 ms)
0:05:55 [339/418/4] test_xdrlib passed -- running: test_multiprocessing_fork (4 min 19 sec), test_multiprocessing_forkserver (4 min 32 sec), test_multiprocessing_spawn (5 min 53 sec), test_venv (3 min 26 sec), test_subprocess (3 min 16 sec), test_ssl (1 min 13 sec), test_multiprocessing_main_handling (41 sec 536 ms)
0:05:56 [340/418/4] test_utf8source passed -- running: test_multiprocessing_fork (4 min 20 sec), test_multiprocessing_forkserver (4 min 33 sec), test_multiprocessing_spawn (5 min 54 sec), test_venv (3 min 27 sec), test_subprocess (3 min 16 sec), test_ssl (1 min 13 sec), test_multiprocessing_main_handling (42 sec 394 ms)
0:05:56 [341/418/4] test_zipimport_support passed -- running: test_multiprocessing_fork (4 min 20 sec), test_multiprocessing_forkserver (4 min 33 sec), test_multiprocessing_spawn (5 min 54 sec), test_venv (3 min 27 sec), test_subprocess (3 min 17 sec), test_ssl (1 min 14 sec), test_multiprocessing_main_handling (42 sec 582 ms)
0:05:56 [342/418/4] test_capi passed -- running: test_multiprocessing_fork (4 min 20 sec), test_multiprocessing_forkserver (4 min 33 sec), test_multiprocessing_spawn (5 min 54 sec), test_venv (3 min 27 sec), test_subprocess (3 min 17 sec), test_ssl (1 min 14 sec), test_multiprocessing_main_handling (42 sec 597 ms)
0:05:57 [343/418/4] test_contextlib passed -- running: test_multiprocessing_fork (4 min 21 sec), test_multiprocessing_forkserver (4 min 35 sec), test_multiprocessing_spawn (5 min 55 sec), test_venv (3 min 28 sec), test_subprocess (3 min 18 sec), test_ssl (1 min 15 sec), test_multiprocessing_main_handling (43 sec 836 ms)
0:05:57 [344/418/4] test_py_compile passed -- running: test_multiprocessing_fork (4 min 22 sec), test_multiprocessing_forkserver (4 min 35 sec), test_multiprocessing_spawn (5 min 56 sec), test_venv (3 min 29 sec), test_subprocess (3 min 18 sec), test_ssl (1 min 15 sec), test_multiprocessing_main_handling (44 sec 306 ms)
0:05:59 [345/418/4] test_configparser passed -- running: test_multiprocessing_fork (4 min 23 sec), test_multiprocessing_forkserver (4 min 36 sec), test_multiprocessing_spawn (5 min 57 sec), test_venv (3 min 30 sec), test_subprocess (3 min 19 sec), test_ssl (1 min 16 sec), test_multiprocessing_main_handling (45 sec 389 ms)
0:05:59 [346/418/4] test_aifc passed -- running: test_multiprocessing_fork (4 min 23 sec), test_multiprocessing_forkserver (4 min 37 sec), test_multiprocessing_spawn (5 min 57 sec), test_venv (3 min 30 sec), test_subprocess (3 min 20 sec), test_ssl (1 min 17 sec), test_multiprocessing_main_handling (45 sec 919 ms)
0:05:59 [347/418/4] test_getargs2 passed -- running: test_multiprocessing_fork (4 min 23 sec), test_multiprocessing_forkserver (4 min 37 sec), test_multiprocessing_spawn (5 min 57 sec), test_venv (3 min 30 sec), test_subprocess (3 min 20 sec), test_ssl (1 min 17 sec), test_multiprocessing_main_handling (45 sec 975 ms)
0:06:34 [348/418/4] test_asyncgen passed -- running: test_multiprocessing_fork (4 min 50 sec), test_multiprocessing_forkserver (5 min 12 sec), test_multiprocessing_spawn (6 min 33 sec), test_venv (4 min 5 sec), test_subprocess (3 min 55 sec), test_tokenize (33 sec 437 ms), test_ssl (1 min 52 sec), test_multiprocessing_main_handling (1 min 21 sec)
0:06:38 [349/418/4] test_popen passed -- running: test_argparse (39 sec 178 ms), test_multiprocessing_fork (5 min 3 sec), test_multiprocessing_forkserver (5 min 16 sec), test_multiprocessing_spawn (6 min 36 sec), test_venv (4 min 9 sec), test_subprocess (3 min 59 sec), test_tokenize (37 sec 283 ms), test_ssl (1 min 56 sec), test_multiprocessing_main_handling (1 min 25 sec)
0:06:40 [350/418/4] test_richcmp passed -- running: test_argparse (40 sec 987 ms), test_multiprocessing_fork (5 min 4 sec), test_multiprocessing_forkserver (5 min 18 sec), test_multiprocessing_spawn (6 min 38 sec), test_venv (4 min 11 sec), test_subprocess (4 min 1 sec), test_tokenize (39 sec 91 ms), test_ssl (1 min 58 sec), test_multiprocessing_main_handling (1 min 26 sec)
0:06:42 [351/418/4] test_msilib skipped -- running: test_argparse (42 sec 440 ms), test_multiprocessing_fork (5 min 6 sec), test_multiprocessing_forkserver (5 min 19 sec), test_multiprocessing_spawn (6 min 40 sec), test_venv (4 min 13 sec), test_subprocess (4 min 2 sec), test_tokenize (40 sec 545 ms), test_ssl (1 min 59 sec), test_multiprocessing_main_handling (1 min 28 sec)
test_msilib skipped -- No module named '_msi'
0:06:46 [352/418/4] test_context passed -- running: test_argparse (47 sec 372 ms), test_multiprocessing_fork (5 min 11 sec), test_multiprocessing_forkserver (5 min 24 sec), test_multiprocessing_spawn (6 min 45 sec), test_venv (4 min 18 sec), test_subprocess (4 min 7 sec), test_tokenize (45 sec 477 ms), test_ssl (2 min 4 sec), test_multiprocessing_main_handling (1 min 33 sec)
0:06:47 [353/418/4] test_wave passed -- running: test_argparse (48 sec 387 ms), test_multiprocessing_fork (5 min 12 sec), test_multiprocessing_forkserver (5 min 25 sec), test_multiprocessing_spawn (6 min 46 sec), test_venv (4 min 19 sec), test_subprocess (4 min 8 sec), test_tokenize (46 sec 491 ms), test_ssl (2 min 5 sec), test_multiprocessing_main_handling (1 min 34 sec)
0:06:48 [354/418/4] test_tokenize passed -- running: test_argparse (49 sec 185 ms), test_multiprocessing_fork (5 min 13 sec), test_multiprocessing_forkserver (5 min 26 sec), test_multiprocessing_spawn (6 min 46 sec), test_venv (4 min 19 sec), test_subprocess (4 min 9 sec), test_ssl (2 min 6 sec), test_multiprocessing_main_handling (1 min 35 sec)
0:06:49 [355/418/4] test_code_module passed -- running: test_argparse (49 sec 849 ms), test_multiprocessing_fork (5 min 13 sec), test_multiprocessing_forkserver (5 min 26 sec), test_multiprocessing_spawn (6 min 47 sec), test_venv (4 min 20 sec), test_subprocess (4 min 10 sec), test_ssl (2 min 7 sec), test_multiprocessing_main_handling (1 min 35 sec)
0:06:50 [356/418/4] test_httplib passed -- running: test_argparse (50 sec 914 ms), test_multiprocessing_fork (5 min 14 sec), test_multiprocessing_forkserver (5 min 28 sec), test_multiprocessing_spawn (6 min 48 sec), test_venv (4 min 21 sec), test_subprocess (4 min 11 sec), test_ssl (2 min 8 sec), test_multiprocessing_main_handling (1 min 36 sec)
0:06:51 [357/418/4] test_webbrowser passed -- running: test_argparse (51 sec 666 ms), test_multiprocessing_fork (5 min 15 sec), test_multiprocessing_forkserver (5 min 28 sec), test_multiprocessing_spawn (6 min 49 sec), test_venv (4 min 22 sec), test_subprocess (4 min 12 sec), test_ssl (2 min 9 sec), test_multiprocessing_main_handling (1 min 37 sec)
0:06:54 [358/418/4] test_hash passed -- running: test_argparse (55 sec 103 ms), test_multiprocessing_fork (5 min 19 sec), test_multiprocessing_forkserver (5 min 32 sec), test_multiprocessing_spawn (6 min 52 sec), test_venv (4 min 25 sec), test_subprocess (4 min 15 sec), test_ssl (2 min 12 sec), test_multiprocessing_main_handling (1 min 41 sec)
0:06:55 [359/418/4] test_ssl passed (2 min 12 sec) -- running: test_argparse (55 sec 673 ms), test_multiprocessing_fork (5 min 19 sec), test_multiprocessing_forkserver (5 min 32 sec), test_multiprocessing_spawn (6 min 53 sec), test_venv (4 min 26 sec), test_subprocess (4 min 16 sec), test_multiprocessing_main_handling (1 min 41 sec)
0:06:55 [360/418/4] test_multiprocessing_main_handling passed (1 min 34 sec) -- running: test_argparse (55 sec 705 ms), test_multiprocessing_fork (5 min 19 sec), test_multiprocessing_forkserver (5 min 32 sec), test_multiprocessing_spawn (6 min 53 sec), test_venv (4 min 26 sec), test_subprocess (4 min 16 sec)
0:06:55 [361/418/4] test_syntax passed -- running: test_argparse (56 sec 93 ms), test_multiprocessing_fork (5 min 19 sec), test_multiprocessing_forkserver (5 min 33 sec), test_multiprocessing_spawn (6 min 53 sec), test_venv (4 min 26 sec), test_subprocess (4 min 16 sec)
0:06:56 [362/418/4] test_eof passed -- running: test_argparse (56 sec 538 ms), test_multiprocessing_fork (5 min 20 sec), test_multiprocessing_forkserver (5 min 33 sec), test_multiprocessing_spawn (6 min 54 sec), test_venv (4 min 27 sec), test_subprocess (4 min 17 sec)
0:06:57 [363/418/4] test_argparse passed (57 sec 148 ms) -- running: test_multiprocessing_fork (5 min 21 sec), test_multiprocessing_forkserver (5 min 34 sec), test_multiprocessing_spawn (6 min 55 sec), test_venv (4 min 28 sec), test_subprocess (4 min 18 sec)
0:06:59 [364/418/4] test_unicodedata passed -- running: test_multiprocessing_fork (5 min 23 sec), test_multiprocessing_forkserver (5 min 36 sec), test_multiprocessing_spawn (6 min 57 sec), test_venv (4 min 30 sec), test_subprocess (4 min 20 sec)
0:07:23 [365/418/4] test_peepholer passed -- running: test_multiprocessing_fork (5 min 47 sec), test_multiprocessing_forkserver (6 min 1 sec), test_multiprocessing_spawn (7 min 21 sec), test_venv (4 min 54 sec), test_subprocess (4 min 44 sec)
0:07:23 [366/418/4] test_set passed -- running: test_multiprocessing_fork (5 min 47 sec), test_multiprocessing_forkserver (6 min 1 sec), test_multiprocessing_spawn (7 min 21 sec), test_venv (4 min 54 sec), test_subprocess (4 min 44 sec)
0:07:24 [367/418/4] test_contains passed -- running: test_multiprocessing_fork (5 min 49 sec), test_multiprocessing_forkserver (6 min 2 sec), test_multiprocessing_spawn (7 min 22 sec), test_venv (4 min 55 sec), test_subprocess (4 min 45 sec)
0:07:30 [368/418/4] test_mailcap passed -- running: test__xxsubinterpreters (32 sec 737 ms), test_multiprocessing_fork (5 min 54 sec), test_multiprocessing_forkserver (6 min 7 sec), test_multiprocessing_spawn (7 min 28 sec), test_venv (5 min 1 sec), test_subprocess (4 min 51 sec), test_email (34 sec 507 ms), test_c_locale_coercion (34 sec 924 ms)
0:07:30 [369/418/5] test__xxsubinterpreters failed -- running: test_multiprocessing_fork (5 min 55 sec), test_multiprocessing_forkserver (6 min 8 sec), test_multiprocessing_spawn (7 min 28 sec), test_venv (5 min 1 sec), test_subprocess (4 min 51 sec), test_email (35 sec 80 ms), test_c_locale_coercion (35 sec 496 ms)
test test__xxsubinterpreters failed -- Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/test/test__xxsubinterpreters.py", line 370, in _assert_values
    self.assertEqual(got, obj)
AssertionError: 4294967295 != -1
0:07:31 [370/418/5] test_ossaudiodev skipped (resource denied) -- running: test_multiprocessing_fork (5 min 55 sec), test_multiprocessing_forkserver (6 min 8 sec), test_multiprocessing_spawn (7 min 29 sec), test_venv (5 min 2 sec), test_subprocess (4 min 52 sec), test_email (35 sec 658 ms), test_c_locale_coercion (36 sec 75 ms)
test_ossaudiodev skipped -- Use of the 'audio' resource not enabled
0:07:32 [371/418/5] test_c_locale_coercion passed (34 sec 514 ms) -- running: test_multiprocessing_fork (5 min 57 sec), test_multiprocessing_forkserver (6 min 10 sec), test_multiprocessing_spawn (7 min 30 sec), test_venv (5 min 3 sec), test_subprocess (4 min 53 sec), test_email (37 sec 43 ms)
0:07:33 [372/418/5] test_crashers passed -- running: test_multiprocessing_fork (5 min 57 sec), test_multiprocessing_forkserver (6 min 10 sec), test_multiprocessing_spawn (7 min 31 sec), test_venv (5 min 4 sec), test_subprocess (4 min 54 sec), test_email (37 sec 582 ms)
0:07:33 [373/418/5] test_statistics passed -- running: test_multiprocessing_fork (5 min 57 sec), test_multiprocessing_forkserver (6 min 11 sec), test_multiprocessing_spawn (7 min 31 sec), test_venv (5 min 4 sec), test_subprocess (4 min 54 sec), test_email (37 sec 853 ms)
0:07:34 [374/418/5] test_optparse passed -- running: test_multiprocessing_fork (5 min 58 sec), test_multiprocessing_forkserver (6 min 11 sec), test_multiprocessing_spawn (7 min 32 sec), test_venv (5 min 5 sec), test_subprocess (4 min 54 sec), test_email (38 sec 367 ms)
0:07:34 [375/418/5] test_thread passed -- running: test_multiprocessing_fork (5 min 59 sec), test_multiprocessing_forkserver (6 min 12 sec), test_multiprocessing_spawn (7 min 33 sec), test_venv (5 min 5 sec), test_subprocess (4 min 55 sec), test_email (39 sec 227 ms)
0:07:35 [376/418/5] test_xxtestfuzz passed -- running: test_multiprocessing_fork (5 min 59 sec), test_multiprocessing_forkserver (6 min 13 sec), test_multiprocessing_spawn (7 min 33 sec), test_venv (5 min 6 sec), test_subprocess (4 min 56 sec), test_email (39 sec 822 ms)
0:07:36 [377/418/5] test_posix passed -- running: test_multiprocessing_fork (6 min 422 ms), test_multiprocessing_forkserver (6 min 13 sec), test_multiprocessing_spawn (7 min 34 sec), test_venv (5 min 7 sec), test_subprocess (4 min 56 sec), test_email (40 sec 446 ms)
0:07:36 [378/418/5] test_string passed -- running: test_multiprocessing_fork (6 min 460 ms), test_multiprocessing_forkserver (6 min 13 sec), test_multiprocessing_spawn (7 min 34 sec), test_venv (5 min 7 sec), test_subprocess (4 min 57 sec), test_email (40 sec 485 ms)
0:07:36 [379/418/5] test_setcomps passed -- running: test_multiprocessing_fork (6 min 1 sec), test_multiprocessing_forkserver (6 min 14 sec), test_multiprocessing_spawn (7 min 34 sec), test_venv (5 min 7 sec), test_subprocess (4 min 57 sec), test_email (41 sec 61 ms)
0:07:37 [380/418/5] test_sundry passed -- running: test_multiprocessing_fork (6 min 2 sec), test_multiprocessing_forkserver (6 min 15 sec), test_multiprocessing_spawn (7 min 36 sec), test_venv (5 min 8 sec), test_subprocess (4 min 58 sec), test_email (42 sec 213 ms)
0:07:39 [381/418/5] test_minidom passed -- running: test_multiprocessing_fork (6 min 3 sec), test_multiprocessing_forkserver (6 min 16 sec), test_multiprocessing_spawn (7 min 37 sec), test_venv (5 min 10 sec), test_subprocess (4 min 59 sec), test_email (43 sec 328 ms)
0:07:40 [382/418/5] test_generators passed -- running: test_multiprocessing_fork (6 min 4 sec), test_multiprocessing_forkserver (6 min 17 sec), test_multiprocessing_spawn (7 min 38 sec), test_venv (5 min 11 sec), test_subprocess (5 min 1 sec), test_email (44 sec 810 ms)
0:07:40 [383/418/5] test_email passed (43 sec 362 ms) -- running: test_multiprocessing_fork (6 min 4 sec), test_multiprocessing_forkserver (6 min 18 sec), test_multiprocessing_spawn (7 min 38 sec), test_venv (5 min 11 sec), test_subprocess (5 min 1 sec)
0:07:40 [384/418/5] test_eintr passed -- running: test_multiprocessing_fork (6 min 5 sec), test_multiprocessing_forkserver (6 min 18 sec), test_multiprocessing_spawn (7 min 39 sec), test_venv (5 min 11 sec), test_subprocess (5 min 1 sec)
0:07:41 [385/418/5] test_cgi passed -- running: test_multiprocessing_fork (6 min 6 sec), test_multiprocessing_forkserver (6 min 19 sec), test_multiprocessing_spawn (7 min 40 sec), test_venv (5 min 13 sec), test_subprocess (5 min 2 sec)
0:08:08 [386/418/5] test_enumerate passed -- running: test_multiprocessing_fork (6 min 32 sec), test_multiprocessing_forkserver (6 min 45 sec), test_multiprocessing_spawn (8 min 6 sec), test_venv (5 min 38 sec), test_subprocess (5 min 28 sec), test_multibytecodec (31 sec 751 ms), test_concurrent_futures (33 sec 861 ms)
0:08:10 [387/418/5] test_multibytecodec passed (32 sec 866 ms) -- running: test_multiprocessing_fork (6 min 34 sec), test_multiprocessing_forkserver (6 min 47 sec), test_multiprocessing_spawn (8 min 8 sec), test_venv (5 min 41 sec), test_subprocess (5 min 31 sec), test_concurrent_futures (36 sec 155 ms)
0:08:10 [388/418/5] test_generator_stop passed -- running: test_multiprocessing_fork (6 min 35 sec), test_multiprocessing_forkserver (6 min 48 sec), test_multiprocessing_spawn (8 min 8 sec), test_venv (5 min 41 sec), test_subprocess (5 min 31 sec), test_concurrent_futures (36 sec 738 ms), test_embed (30 sec 296 ms)
0:08:11 [389/418/5] test_epoll skipped -- running: test_asyncio (30 sec 453 ms), test_multiprocessing_fork (6 min 35 sec), test_multiprocessing_forkserver (6 min 48 sec), test_multiprocessing_spawn (8 min 9 sec), test_venv (5 min 42 sec), test_subprocess (5 min 32 sec), test_concurrent_futures (37 sec 337 ms), test_embed (30 sec 894 ms)
test_epoll skipped -- test works only on Linux 2.6
0:08:15 [390/418/5] test_asynchat passed -- running: test_asyncio (34 sec 801 ms), test_multiprocessing_fork (6 min 40 sec), test_multiprocessing_forkserver (6 min 53 sec), test_multiprocessing_spawn (8 min 13 sec), test_venv (5 min 46 sec), test_subprocess (5 min 36 sec), test_concurrent_futures (41 sec 685 ms), test_embed (35 sec 242 ms)
0:08:16 [391/418/6] test_embed failed -- running: test_asyncio (35 sec 964 ms), test_multiprocessing_fork (6 min 41 sec), test_multiprocessing_forkserver (6 min 54 sec), test_multiprocessing_spawn (8 min 15 sec), test_venv (5 min 47 sec), test_subprocess (5 min 37 sec), test_concurrent_futures (42 sec 847 ms)
test test_embed failed -- multiple errors occurred; run in verbose mode for details
0:08:17 [392/418/6] test_subprocess passed (5 min 34 sec) -- running: test_asyncio (36 sec 910 ms), test_multiprocessing_fork (6 min 42 sec), test_multiprocessing_forkserver (6 min 55 sec), test_multiprocessing_spawn (8 min 15 sec), test_venv (5 min 48 sec), test_concurrent_futures (43 sec 793 ms)
0:08:17 [393/418/6] test_struct passed -- running: test_asyncio (36 sec 989 ms), test_multiprocessing_fork (6 min 42 sec), test_multiprocessing_forkserver (6 min 55 sec), test_multiprocessing_spawn (8 min 16 sec), test_venv (5 min 48 sec), test_concurrent_futures (43 sec 873 ms)
0:08:18 [394/418/6] test_smtpd passed -- running: test_asyncio (37 sec 974 ms), test_multiprocessing_fork (6 min 43 sec), test_multiprocessing_forkserver (6 min 56 sec), test_multiprocessing_spawn (8 min 17 sec), test_venv (5 min 49 sec), test_concurrent_futures (44 sec 858 ms)
0:08:19 [395/418/6] test_reprlib passed -- running: test_asyncio (38 sec 942 ms), test_multiprocessing_fork (6 min 44 sec), test_multiprocessing_forkserver (6 min 57 sec), test_multiprocessing_spawn (8 min 17 sec), test_venv (5 min 50 sec), test_concurrent_futures (45 sec 825 ms)
0:08:20 [396/418/6] test_call passed -- running: test_asyncio (39 sec 528 ms), test_multiprocessing_fork (6 min 44 sec), test_multiprocessing_forkserver (6 min 57 sec), test_multiprocessing_spawn (8 min 18 sec), test_venv (5 min 51 sec), test_concurrent_futures (46 sec 412 ms)
0:08:24 [397/418/6] test_utf8_mode passed -- running: test_asyncio (43 sec 363 ms), test_multiprocessing_fork (6 min 48 sec), test_multiprocessing_forkserver (7 min 1 sec), test_multiprocessing_spawn (8 min 22 sec), test_venv (5 min 55 sec), test_concurrent_futures (50 sec 246 ms)
0:08:25 [398/418/6] test_multiprocessing_fork passed (6 min 40 sec) -- running: test_asyncio (44 sec 60 ms), test_multiprocessing_forkserver (7 min 2 sec), test_multiprocessing_spawn (8 min 23 sec), test_venv (5 min 56 sec), test_concurrent_futures (50 sec 944 ms)
0:08:25 [399/418/6] test_float passed -- running: test_asyncio (44 sec 867 ms), test_multiprocessing_forkserver (7 min 3 sec), test_multiprocessing_spawn (8 min 23 sec), test_venv (5 min 56 sec), test_concurrent_futures (51 sec 751 ms)
0:08:26 [400/418/6] test_sched passed -- running: test_asyncio (45 sec 307 ms), test_multiprocessing_forkserver (7 min 3 sec), test_multiprocessing_spawn (8 min 24 sec), test_venv (5 min 57 sec), test_concurrent_futures (52 sec 190 ms)
0:08:26 [401/418/6] test_calendar passed -- running: test_asyncio (45 sec 777 ms), test_multiprocessing_forkserver (7 min 4 sec), test_multiprocessing_spawn (8 min 24 sec), test_venv (5 min 57 sec), test_concurrent_futures (52 sec 661 ms)
0:08:27 [402/418/6] test_codecencodings_tw passed -- running: test_asyncio (46 sec 131 ms), test_multiprocessing_forkserver (7 min 4 sec), test_multiprocessing_spawn (8 min 25 sec), test_venv (5 min 58 sec), test_concurrent_futures (53 sec 14 ms)
0:08:27 [403/418/6] test_codeccallbacks passed -- running: test_asyncio (46 sec 834 ms), test_multiprocessing_forkserver (7 min 5 sec), test_multiprocessing_spawn (8 min 25 sec), test_venv (5 min 58 sec), test_concurrent_futures (53 sec 717 ms)
0:08:28 [404/418/6] test_idle skipped -- running: test_asyncio (47 sec 474 ms), test_multiprocessing_forkserver (7 min 5 sec), test_multiprocessing_spawn (8 min 26 sec), test_venv (5 min 59 sec), test_concurrent_futures (54 sec 357 ms)
test_idle skipped -- No module named '_tkinter'
0:08:29 [405/418/6] test_codecencodings_hk passed -- running: test_asyncio (48 sec 322 ms), test_multiprocessing_forkserver (7 min 6 sec), test_multiprocessing_spawn (8 min 27 sec), test_venv (6 min 311 ms), test_concurrent_futures (55 sec 206 ms)
0:08:30 [406/418/6] test_nntplib passed -- running: test_asyncio (49 sec 275 ms), test_multiprocessing_forkserver (7 min 7 sec), test_multiprocessing_spawn (8 min 28 sec), test_venv (6 min 1 sec), test_concurrent_futures (56 sec 159 ms)
0:08:30 [407/418/6] test_pdb passed -- running: test_asyncio (49 sec 771 ms), test_multiprocessing_forkserver (7 min 8 sec), test_multiprocessing_spawn (8 min 28 sec), test_venv (6 min 1 sec), test_concurrent_futures (56 sec 654 ms)
0:08:30 [408/418/6] test_userlist passed -- running: test_asyncio (49 sec 879 ms), test_multiprocessing_forkserver (7 min 8 sec), test_multiprocessing_spawn (8 min 28 sec), test_venv (6 min 1 sec), test_concurrent_futures (56 sec 763 ms)
0:08:32 [409/418/6] test_venv passed (5 min 58 sec) -- running: test_asyncio (51 sec 374 ms), test_multiprocessing_forkserver (7 min 9 sec), test_multiprocessing_spawn (8 min 30 sec), test_concurrent_futures (58 sec 258 ms)
0:08:33 [410/418/6] test_source_encoding passed -- running: test_asyncio (52 sec 333 ms), test_multiprocessing_forkserver (7 min 10 sec), test_multiprocessing_spawn (8 min 31 sec), test_concurrent_futures (59 sec 216 ms)
0:08:34 [411/418/7] test_distutils failed -- running: test_asyncio (53 sec 104 ms), test_multiprocessing_forkserver (7 min 11 sec), test_multiprocessing_spawn (8 min 32 sec), test_concurrent_futures (59 sec 988 ms)
xlc_r: 1501-218 (S) file _configtest.i contains an incorrect file suffix
test test_distutils failed -- multiple errors occurred; run in verbose mode for details
0:08:34 [412/418/7] test_selectors passed -- running: test_asyncio (53 sec 107 ms), test_multiprocessing_forkserver (7 min 11 sec), test_multiprocessing_spawn (8 min 32 sec), test_concurrent_futures (59 sec 990 ms)
0:08:39 [413/418/7] test_importlib passed -- running: test_asyncio (58 sec 278 ms), test_multiprocessing_forkserver (7 min 16 sec), test_multiprocessing_spawn (8 min 37 sec), test_concurrent_futures (1 min 5 sec)
0:08:47 [414/418/8] test_multiprocessing_forkserver failed -- running: test_asyncio (1 min 6 sec), test_multiprocessing_spawn (8 min 45 sec), test_concurrent_futures (1 min 13 sec)
Process Process-141:
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1612, in task
    self.f(*self.args)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1757, in _test_reset_f
    i = barrier.wait()
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 604, in wait
    self._enter() # Block while the barrier drains.
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 628, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Process Process-142:
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1612, in task
    self.f(*self.args)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1757, in _test_reset_f
    i = barrier.wait()
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 604, in wait
    self._enter() # Block while the barrier drains.
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 628, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Process Process-139:
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1612, in task
    self.f(*self.args)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1757, in _test_reset_f
    i = barrier.wait()
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 604, in wait
    self._enter() # Block while the barrier drains.
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 628, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Process Process-140:
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/data/prj/python/git/python3-3.8/Lib/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1612, in task
    self.f(*self.args)
  File "/data/prj/python/git/python3-3.8/Lib/test/_test_multiprocessing.py", line 1757, in _test_reset_f
    i = barrier.wait()
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 604, in wait
    self._enter() # Block while the barrier drains.
  File "/data/prj/python/git/python3-3.8/Lib/threading.py", line 628, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
test test_multiprocessing_forkserver failed -- multiple errors occurred; run in verbose mode for details
0:08:59 [415/418/9] test_socket failed -- running: test_asyncio (1 min 18 sec), test_multiprocessing_spawn (8 min 57 sec), test_concurrent_futures (1 min 24 sec)
/data/prj/python/git/python3-3.8/Lib/test/test_socket.py:2345: RuntimeWarning: received malformed or improperly-truncated ancillary data
  result = sock.recvmsg(bufsize, *args)
/data/prj/python/git/python3-3.8/Lib/test/test_socket.py:2436: RuntimeWarning: received malformed or improperly-truncated ancillary data
  result = sock.recvmsg_into([buf], *args)
test test_socket failed -- multiple errors occurred; run in verbose mode for details
0:09:08 [416/418/9] test_multiprocessing_spawn passed (9 min 2 sec) -- running: test_asyncio (1 min 27 sec), test_concurrent_futures (1 min 34 sec)
0:09:14 [417/418/10] test_asyncio failed -- running: test_concurrent_futures (1 min 40 sec)
test test_asyncio failed -- multiple errors occurred; run in verbose mode for details
running: test_concurrent_futures (2 min 10 sec)
running: test_concurrent_futures (2 min 40 sec)
running: test_concurrent_futures (3 min 10 sec)
0:11:01 [418/418/10] test_concurrent_futures passed (3 min 26 sec)

== Tests result: FAILURE ==

376 tests OK.

10 tests failed:
    test__xxsubinterpreters test_asyncio test_ctypes test_distutils
    test_embed test_httpservers test_multiprocessing_forkserver
    test_os test_socket test_time

32 tests skipped:
    test_curses test_dbm_gnu test_devpoll test_epoll test_gdb
    test_idle test_kqueue test_lzma test_msilib test_ossaudiodev
    test_readline test_smtpnet test_socketserver test_spwd test_sqlite
    test_startfile test_tcl test_timeout test_tix test_tk
    test_ttk_guionly test_ttk_textonly test_turtle test_unicode_file
    test_unicode_file_functions test_urllib2net test_urllibnet
    test_winconsoleio test_winreg test_winsound test_xmlrpc_net
    test_zipfile64

Total duration: 11 min 1 sec
Tests result: FAILURE
root at x066:[/data/prj/python/git/python3-3.8]

Script command is complete on Tue Aug 28 18:46:46 UTC 2018.

From report at bugs.python.org  Wed Aug 29 13:05:12 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Wed, 29 Aug 2018 17:05:12 +0000
Subject: [issue34541] pathlib.Path.iterdir doesn't throw an exception until
 you start iterating
In-Reply-To: <1535530821.14.0.56676864532.issue34541@psf.upfronthosting.co.za>
Message-ID: <1535562312.78.0.56676864532.issue34541@psf.upfronthosting.co.za>


Change by Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com>:


----------
pull_requests: +8470

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34541>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:06:39 2018
From: report at bugs.python.org (Paul Pinterits)
Date: Wed, 29 Aug 2018 17:06:39 +0000
Subject: [issue34541] pathlib.Path.iterdir doesn't throw an exception until
 you start iterating
In-Reply-To: <1535530821.14.0.56676864532.issue34541@psf.upfronthosting.co.za>
Message-ID: <1535562399.4.0.56676864532.issue34541@psf.upfronthosting.co.za>


Paul Pinterits <rawing7 at gmail.com> added the comment:

As an afterthought, I'd like to suggest an alternative solution: If changing the `iterdir` behavior is not possible or not desirable for some reason, please add a `Path.listdir` method that returns a list instead of an iterator. Lazy file system operations can often introduce unnecessary race conditions in the code, so I believe it would be very useful if every lazy method had an eager equivalent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34541>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:07:03 2018
From: report at bugs.python.org (Prudvi RajKumar Maddala)
Date: Wed, 29 Aug 2018 17:07:03 +0000
Subject: [issue34541] pathlib.Path.iterdir doesn't throw an exception until
 you start iterating
In-Reply-To: <1535530821.14.0.56676864532.issue34541@psf.upfronthosting.co.za>
Message-ID: <1535562423.45.0.56676864532.issue34541@psf.upfronthosting.co.za>


Prudvi RajKumar Maddala <prudhvirajnitjsr at gmail.com> added the comment:

Made changes, pathlib.Path('.').iterdir() now throws a FileNotFoundError if the path is not valid.

----------
nosy: +prudvinit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34541>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:10:25 2018
From: report at bugs.python.org (DeKrain)
Date: Wed, 29 Aug 2018 17:10:25 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535562625.17.0.56676864532.issue34543@psf.upfronthosting.co.za>


DeKrain <dawidkrainski8 at gmail.com> added the comment:

Well, sometimes when i do
>>> b = bytearray()
>>> s.pack_into(b)

application crashes (because it checks arg #1, which is not initialized).
Also, I imported from _struct, because it's where implementation of Struct really is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34543>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:13:37 2018
From: report at bugs.python.org (Shiva Saxena)
Date: Wed, 29 Aug 2018 17:13:37 +0000
Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO
In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za>
Message-ID: <1535562817.2.0.56676864532.issue32560@psf.upfronthosting.co.za>


Change by Shiva Saxena <shivasaxena911 at gmail.com>:


----------
keywords: +patch
pull_requests: +8472
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32560>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:15:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 17:15:17 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535562917.9.0.56676864532.issue34481@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Because caring of surrogates, I would prefer to first fix time.strftime() and time.strptime() for legit time zone names. Currently, Python uses the C function strfime() because the string produced by wcsftime() cannot be parsed later. We should use the native Windows API to get the time zone name properly encoded. I don't recall the details, sorry. There is maybe an open issue for that one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:17:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 17:17:19 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535563039.68.0.56676864532.issue34481@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Because caring of surrogates,

Before*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:28:21 2018
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 29 Aug 2018 17:28:21 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535563701.64.0.56676864532.issue34543@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

_struct is a private implementation detail. You shouldn't use it. You shouldn't care where the implementation "really is" in your Python code, because it could move without warning. There are no backwards-compatibility guarantees for private modules like _struct.

But regardless of where you are importing it from, why are you calling Struct.__new__(Struct) in the first place? You should be calling Struct().

I still don't see any reason to consider this a bug. I can't reproduce your report of a crash:

py> from _struct import Struct
py> s = Struct.__new__(Struct)
py> b = bytearray()
py> s.pack_into(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: null argument to internal routine


I get an exception, which is the correct behaviour. Unless this segfaults, I don't believe this is a bug that needs fixing.

(By the way, Struct doesn't even have a __new__ method. You are calling the __new__ method inherited from object, which clearly knows nothing about how to initialise a Struct.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34543>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:32:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 17:32:51 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535563971.56.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c5989cd87659acbfd4d19dc00dbe99c3a0fc9bd2 by Victor Stinner in branch 'master':
bpo-34523: Py_DecodeLocale() use UTF-8 on Windows (GH-8998)
https://github.com/python/cpython/commit/c5989cd87659acbfd4d19dc00dbe99c3a0fc9bd2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:36:48 2018
From: report at bugs.python.org (Shiva Saxena)
Date: Wed, 29 Aug 2018 17:36:48 +0000
Subject: [issue32560] [EASY C] inherit the py launcher's STARTUPINFO
In-Reply-To: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za>
Message-ID: <1535564208.01.0.56676864532.issue32560@psf.upfronthosting.co.za>


Shiva Saxena <shivasaxena911 at gmail.com> added the comment:

I am a new contributor, and happy to take this issue as my first contribution in cpython. I have sent a PR for the same. Please let me know if anything needs to be change.

----------
nosy: +GeekyShacklebolt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32560>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:37:20 2018
From: report at bugs.python.org (DeKrain)
Date: Wed, 29 Aug 2018 17:37:20 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535564240.55.0.56676864532.issue34543@psf.upfronthosting.co.za>


DeKrain <dawidkrainski8 at gmail.com> added the comment:

(I wrote that I'm importing from _struct just for this issue.)
I've seen that tp_new of PyStructType is set to s_new in Modules/_struct.c.
And that crash is most likely caused by access to uninitialized memory, so it is not guaranteed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34543>
_______________________________________

From report at bugs.python.org  Wed Aug 29 13:44:19 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 29 Aug 2018 17:44:19 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535564659.32.0.56676864532.issue34535@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Victor, that was a little overboard. By that logic, there doesn't need to be a Windows version of Python.

That said, Paul doesn't seem to understand that the real resolution limit isn't 1 ms; that's the lower limit on arguments to the API, but the real limit is the system clock, which has a granularity in the 10-16 ms range. It's a problem with Windows in general, and the cure is worse than the disease.

Per https://msdn.microsoft.com/en-us/library/windows/desktop/ms724411(v=vs.85).aspx , the resolution of the system timer is typically in the range of 10 milliseconds to 16 milliseconds.

Per https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals :

> Wait Functions and Time-out Intervals

> The accuracy of the specified time-out interval depends on the resolution of the system clock. The system clock "ticks" at a constant rate. If the time-out interval is less than the resolution of the system clock, the wait may time out in less than the specified length of time. If the time-out interval is greater than one tick but less than two, the wait can be anywhere between one and two ticks, and so on.

All the Windows synchronization primitives (e.g. WaitForSingleObjectEx https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-waitforsingleobjectex , which is what ultimately implements timed lock acquisition on Windows) are based on the system clock, so without drastic measures, it's impossible to get better granularity than the 10-16 ms of the default system clock configuration.

The link on "Wait Functions and Time-out Intervals" does mention that this granularity *can* be increased, but it recommends against fine-grained tuning (so you can't just tweak it before a wait and undo the tweak after; the only safe thing to do is change it on program launch and undo it on program exit). Even then, it's a bad idea for Python to use it; per timeBeginPeriod's own docs ( https://docs.microsoft.com/en-us/windows/desktop/api/timeapi/nf-timeapi-timebeginperiod ):

> This function affects a global Windows setting. Windows uses the lowest value (that is, highest resolution) requested by any process. Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. Setting a higher resolution does not improve the accuracy of the high-resolution performance counter.

Basically, to improve the resolution of timed lock acquisition, we'd have to change the performance profile of the entire OS while Python was running, likely increasing power usage and possibly reducing performance. Global solutions to local problems are a bad idea.

The most reasonable solution to the problem is to simply document it (maybe not for queue.Queue, but for the threading module). Possibly even provide an attribute in the threading module similar to  threading.TIMEOUT_MAX that reports the system clock's granularity for informational purposes (might need to be a function so it reports the potentially changing granularity).

Other, less reasonable solutions, would be:

1. Expose a function (with prominent warnings about not using it in a fine grained manner, and the effects on power management and performance) that would increase the system clock granularity as much as possible timeGetDevCaps reports possible (possibly limited to a user provided suggestion, so while the clock could go to 1 ms resolution, the user could request only 5 ms resolution to reduce the costs of doing so). Requires some additional state (whether timeBeginPeriod has been called, and with what values) so timeEndPeriod can be called properly before each adjustment and when Python exits. Pro is the code is *relatively* simple and would mostly fix the problem. Cons are that it wouldn't be super discoverable (unless we put notes in every place that uses timeouts, not just in threading docs), it encourages bad behavior (one application deciding its needs are more important that conserving power), and we'd have to be *really* careful to pair our calls universally (timeEndPeriod must be called, even when other cleanup is skipped, such as when calling os._exit; AFAICT, the docs imply that per-process adjustments to the clock aren't undone even when the process completes, which means failure to pair all calls would leave the system with a suboptimal system clock resolution that would remain in effect until rebooted).

2. (Likely a terrible idea, and like option 1, should be explicitly opt-in, not enabled by default) Offer the option to have Python lock timeouts only use WaitForSingleObjectEx only to sleep to within one system clock tick of the target time (and not at all if the timeout is less than the clock resolution), then, before reacquiring the GIL, perform a time slice yielding busy loop until you pass the target time (as determined by a higher resolution clock than the system clock). Bad for power management, bad for single core machines (where even with time slice yielding, you're still constantly getting scheduled), etc.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 14:01:21 2018
From: report at bugs.python.org (Paul Overing)
Date: Wed, 29 Aug 2018 18:01:21 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535565681.59.0.56676864532.issue34535@psf.upfronthosting.co.za>


Paul Overing <paulovering at gmail.com> added the comment:

Thank you to everyone for looking at my issue esp Josh.r for the detailed response. I now understand the issue and I just wanted to bring it to the group's attention for everyone's benefit.  Vstinner is correct; Linux is my solution as it is my production environment but I was using my windows laptop for dev as I've been doing frequent Asia trips lately and noticed the difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 15:17:05 2018
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Aug 2018 19:17:05 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535570225.42.0.56676864532.issue34538@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think the question is how often in real code to people want to catch all exceptions produced by a package or module but not any others. Perhaps it would be better to re-word the advice that when there are many related exceptions that it is suggested you have a base class for them?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Wed Aug 29 15:24:31 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 29 Aug 2018 19:24:31 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1535570671.62.0.56676864532.issue34522@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Eddie,

I have read the thread and still don't see why breaking existing code is a good thing to do.

As I wrote earlier there are two issues you're trying to address with one patch:

1) Not all types in the CPython tree are initialised using PyType_Ready

Fixing that is ok and the patch for that looks ok. But: I haven't checked if PyType_Ready is called before types are used, if the call to PyType_Ready is done after the type is already implicitly readied the call to PyType_Ready is purely cosmetic.

2) Using PyVarObject_HEAD_INIT(&some_type, ...) causes problems on Windows

I don't agree with the current patch for that because that *silently* changes the semantics of existing code, and hence can break existing C extensions. 

I haven't tested the patch yet, but I do have C extensions that use this pattern and where "&some_type" is not equivalent to NULL.

The correct change for the CPython tree is to change all instances of PyVarObject_HEAD_INIT(&some_type, ...) to PyVarObject_HEAD_INIT(NULL, ...), and then add explicit code to set the type of the type instance where "some_type" is not PyType_Type (AFAIK there aren't any of those in the CPython tree, but there are outside of CPython).


Another reason why changing PyVarObject_HEAD_INIT is not correct is that this can be used to initialize more than just PyTypeObject structs, as the name suggests it is used to initialize PyVarObject values and not just PyTypeObject values. Changing the macro also breaks those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34522>
_______________________________________

From report at bugs.python.org  Wed Aug 29 15:40:17 2018
From: report at bugs.python.org (Tatyana)
Date: Wed, 29 Aug 2018 19:40:17 +0000
Subject: [issue34495] excess_args asserts if args == nullptr
In-Reply-To: <1535178135.11.0.56676864532.issue34495@psf.upfronthosting.co.za>
Message-ID: <1535571617.89.0.56676864532.issue34495@psf.upfronthosting.co.za>


Tatyana <tatyana at synopsys.com> added the comment:

So, user has to do

	PyObject *empty_args = PyTuple_New(0);
	inst = PyBaseObject_Type.tp_new(type_obj, empty_args, Py_None);
	Py_DECREF(empty_args);


when type_obj doesn't require arguments for constructing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34495>
_______________________________________

From report at bugs.python.org  Wed Aug 29 16:21:41 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 20:21:41 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535574101.8.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 3d4226a832cabc630402589cc671cc4035d504e5 by Victor Stinner in branch 'master':
bpo-34523: Support surrogatepass in locale codecs (GH-8995)
https://github.com/python/cpython/commit/3d4226a832cabc630402589cc671cc4035d504e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 16:29:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 20:29:00 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535574540.97.0.56676864532.issue34485@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 16:33:36 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 Aug 2018 20:33:36 +0000
Subject: [issue34495] excess_args asserts if args == nullptr
In-Reply-To: <1535178135.11.0.56676864532.issue34495@psf.upfronthosting.co.za>
Message-ID: <1535574816.75.0.56676864532.issue34495@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The third argument of tp_new() should be a dict or NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34495>
_______________________________________

From report at bugs.python.org  Wed Aug 29 16:55:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 20:55:09 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535576109.05.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 16:56:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 20:56:09 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535576169.63.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset cf21504194927b2f22132f48effea69eb8ade751 by Victor Stinner in branch 'master':
bpo-34485: Emit C locale coercion warning later (GH-9002)
https://github.com/python/cpython/commit/cf21504194927b2f22132f48effea69eb8ade751


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Wed Aug 29 17:22:58 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 29 Aug 2018 21:22:58 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535577778.74.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Interestingly, everything points to something special in the glibc version of the buildbot. Usually the end of the stack for threads is:

(gdb)
#22 0x00007ffff7f82a9d in start_thread () from /usr/lib/libpthread.so.0
(gdb)
#23 0x00007ffff7d23a43 in clone () from /usr/lib/libc.so.6

but in this buildbot we get:

#24 0x000003fffde88b22 in start_thread () from /lib64/libpthread.so.0
(gdb)
#25 0x000003fffdb7164a in thread_start () from /lib64/libc.so.6
(gdb)
PC not saved

I think that the combination of glibc + gdb is producing this problem probably because the optimization level of glibc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Wed Aug 29 17:27:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 21:27:00 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535578020.29.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset de427556746aa41a8b5198924ce423021bc0c718 by Victor Stinner in branch 'master':
bpo-34523: Py_FileSystemDefaultEncoding NULL by default (GH-9003)
https://github.com/python/cpython/commit/de427556746aa41a8b5198924ce423021bc0c718


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:01:36 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 29 Aug 2018 22:01:36 +0000
Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of
 deprecated functions and macros
In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za>
Message-ID: <1535580096.39.0.56676864532.issue19569@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19569>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:02:46 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 29 Aug 2018 22:02:46 +0000
Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of
 deprecated functions and macros
In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za>
Message-ID: <1535580166.44.0.56676864532.issue19569@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19569>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:08:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 22:08:34 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535580514.81.0.56676864532.issue34523@psf.upfronthosting.co.za>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +8476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:35:56 2018
From: report at bugs.python.org (Cabu)
Date: Wed, 29 Aug 2018 22:35:56 +0000
Subject: [issue34528] Windows installer: Failed to run untrusted mode.
In-Reply-To: <1535453399.16.0.56676864532.issue34528@psf.upfronthosting.co.za>
Message-ID: <1535582156.64.0.56676864532.issue34528@psf.upfronthosting.co.za>


Cabu <cabuzelth at yahoo.com> added the comment:

Knowing the IT department, I will receive a nice letter saying that they don't care because it is not an approved software and that I could use Java for my development needs. I wanted to develop some interesting tools in python that could be used by a lot of colleagues to force their hand in approving it in a quicker way, else it will be like they have done for php and in 5 years they will finnally approve the use of python 2.7 (without pip to install non approved libraries) as a standard tool :(

If I want the latest and greatest Python environment, it would be easier for me to copy a working installation from my computer and update the registry and environment variables like the installer should do. For that purpose, do you have somewhere the list of registry keys and environment variables to insert/update?

In the meantime I have found a 'workaround': Install Anaconda. I will not have python 3.7, but 3.6.3 is better than nothing :/ But still a pity to install 600MB of cruft for the 30MB of Python goodies :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34528>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:50:51 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 22:50:51 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535583051.73.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fbca90856d96273fd87c0b126f6e7966af7fbf7b by Victor Stinner in branch 'master':
bpo-34523: Use _PyCoreConfig instead of globals (GH-9005)
https://github.com/python/cpython/commit/fbca90856d96273fd87c0b126f6e7966af7fbf7b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:51:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 22:51:48 +0000
Subject: [issue34523] Choose the filesystem encoding before Python
 initialization (add _PyCoreConfig.filesystem_encoding)
In-Reply-To: <1535413443.13.0.56676864532.issue34523@psf.upfronthosting.co.za>
Message-ID: <1535583108.23.0.56676864532.issue34523@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

It was much more complicated than expected to implement this idea, but it seems like it's now working! I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34523>
_______________________________________

From report at bugs.python.org  Wed Aug 29 18:53:19 2018
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 29 Aug 2018 22:53:19 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535583199.88.0.56676864532.issue34535@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Changing the system timer resolution doesn't appear to help, given the current design combined with what looks like a bug in Windows (at least in Windows 10). We can set the system clock resolution below a millisecond via NtSetTimerResolution. I tested at 0.4882 ms, which allowed sleeping for 0.5 ms via NtDelayExectution. (NT interval resolution is 100 ns, nominally). But Python's threading Lock timeout is still limited to about 15-16 ms. I'd expect 1 ms resolution given we're ultimately calling WaitForSingleObjectEx via PyCOND_TIMEDWAIT -> _PyCOND_WAIT_MS.

It appears the problem is that GetTickCount[64] continues to increment by 15.625 ms (i.e. by 15 to 16), which looks like a bug to me, but may be a compatibility behavior. We use the tick count in EnterNonRecursiveMutex in the following block of code:

    } else if (milliseconds != 0) {
        /* wait at least until the target */
        DWORD now, target = GetTickCount() + milliseconds;
        while (mutex->locked) {
            if (PyCOND_TIMEDWAIT(&mutex->cv, &mutex->cs, (long long)milliseconds*1000) < 0) {
                result = WAIT_FAILED;
                break;
            }
            now = GetTickCount();
            if (target <= now)
                break;
            milliseconds = target-now;
        }
    }

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 19:05:12 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 29 Aug 2018 23:05:12 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535583912.17.0.56676864532.issue34481@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

@p-ganssle

> I'm finding it very difficult to reconcile these things.

Paul, this issue was only about reconciling C and Python implementations of datetime module -- not fixing time.strftime(), which both of them delegate to. While the latter is certainly more important, it's also much more difficult, and IMO needs another issue report (maybe merged with #34512). As for the former, it seems that you've already fixed it in your PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Wed Aug 29 19:06:13 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2018 23:06:13 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
In-Reply-To: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>
Message-ID: <1535583973.05.0.56676864532.issue34539@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If this is only present in 3.7.0 and not in the current branches, it implies there was an exec() or ceval-loop bug in that release and it has been already fixed.

This bug report may be out-of-date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Wed Aug 29 19:11:19 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2018 23:11:19 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535584279.71.0.56676864532.issue34529@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> The main difference between Json and new line delimited json is that new line contains valid json in each line. 

It is up to Bob to decide whether this feature request is within the scope of the module.

----------
assignee:  -> bob.ippolito
components: +Library (Lib)
nosy: +bob.ippolito
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Wed Aug 29 19:19:15 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 23:19:15 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535584755.85.0.56676864532.issue34535@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I dislike the idea of documentation the Windows clocks in the queue documentation, it's not the right place. I dislike the idea of documentating Windows "internals" in the Python documentation. You should see Python as a "thin wrapper" to the operating system. If you have an issue on a platform, you should look at the platform documentation. Python already provides time.get_clock_info('monotonic').

>From what I read, changing the system clock resolution is a bad idea, since the Windows kernel is not designed for that, and it can reduce the battery life.

About Windows vs Linux, as I wrote, you are looking at the wrong way. queue.get() is not a bottleneck if you use threads, asyncio, multiprocessing or whatever.

Again, this issue is not a bug. And I dislike the idea of documentating the behaviour. So I still consider that the issue should be closed as "not a bug". But I leave it open since it seems like you want to use it to discuss Windows clocks ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Wed Aug 29 19:28:53 2018
From: report at bugs.python.org (Bob Ippolito)
Date: Wed, 29 Aug 2018 23:28:53 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535585333.76.0.56676864532.issue34529@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I think the best start would be to add a bit of documentation with an example of how you could work with newline delimited json using the existing module as-is. On the encoding side you need to ensure that it's a compact representation without embedded newlines, e.g.:

    for obj in objs:
        yield json.dumps(obj, separators=(',', ':')) + '\n'

I don't think it would make sense to support this directly from dumps, as it's really multiple documents rather than the single document that every other form of dumps will output.

On the read side it would be something like:

    for doc in lines:
        yield json.loads(doc)

I'm not sure if this is common enough (and separable enough from I/O and error handling constraints) to be worth adding the functionality directly into json module. I think it would be more appropriate in the short to medium term that the each service (e.g. BigQuery) would have its own module with helper functions or framework that encapsulates the protocol that the particular service speaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Wed Aug 29 19:37:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Aug 2018 23:37:46 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
Message-ID: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

It seems like my recent work on Python initialization broke Python on FreeBSD. Many test_c_locale_coerce tests now fail with:

"Fatal Python error: get_locale_encoding: failed to get the locale encoding: nl_langinfo(CODESET) failed"

Example of failed buildbot build:

https://buildbot.python.org/all/#/builders/87/builds/1340

It seems like this buildbot started to fail at this build:

https://buildbot.python.org/all/#/builders/87/builds/1332

This build has been triggered by this change:

commit 177d921c8c03d30daa32994362023f777624b10d
Author: Victor Stinner <vstinner at redhat.com>
Date:   Wed Aug 29 11:25:15 2018 +0200

    bpo-34485, Windows: LC_CTYPE set to user preference (GH-8988)
    
    On Windows, the LC_CTYPE is now set to the user preferred locale at
    startup: _Py_SetLocaleFromEnv(LC_CTYPE) is now called during the
    Python initialization. Previously, the LC_CTYPE locale was "C" at
    startup, but changed when calling setlocale(LC_CTYPE, "") or
    setlocale(LC_ALL, "").
    
    pymain_read_conf() now also calls _Py_SetLocaleFromEnv(LC_CTYPE) to
    behave as _Py_InitializeCore(). Moreover, it doesn't save/restore the
    LC_ALL anymore.
    
    On Windows, standard streams like sys.stdout now always use
    surrogateescape error handler by default (ignore the locale).

test_c_locale_coerce tests invalid locales like LANG="invalid.ascii". It seems like Python supported such configuration before my changes.

My recent work:

* bpo-34523: filesystem encoding/errors
* bpo-34485: stdio encoding/errors

----------
components: Interpreter Core
messages: 324361
nosy: vstinner
priority: normal
severity: normal
status: open
title: FreeBSD: Fatal Python error: get_locale_encoding: failed to get the locale encoding: nl_langinfo(CODESET) failed
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34544>
_______________________________________

From report at bugs.python.org  Wed Aug 29 21:38:55 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Aug 2018 01:38:55 +0000
Subject: [issue34528] Windows installer: Failed to run untrusted mode.
In-Reply-To: <1535453399.16.0.56676864532.issue34528@psf.upfronthosting.co.za>
Message-ID: <1535593135.96.0.56676864532.issue34528@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

We're totally okay with you using a different installer if you want. We know and trust Anaconda, and while they do things differently, if that model works for you then it'll be fine.

Python 3.7 shouldn't need any registry settings or environment variables to operate correctly for the most part - I fixed those dependencies in 3.6. You may need to "python -m pip install --force pip" after copying it though, if you want to use the plain "pip" command ("python -m pip" will work). You also won't get the py.exe launcher unless you copy that from C:\Windows.

Good luck!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34528>
_______________________________________

From report at bugs.python.org  Thu Aug 30 00:26:04 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Aug 2018 04:26:04 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535603164.7.0.56676864532.issue34529@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This format is known as JSON Lines: http://jsonlines.org/. Its support in the user code is trivial -- just one or two lines of code.

Writing:

    for item in items:
        json.dump(item, file)

or

    jsondata = ''.join(json.dumps(item) for item in items)

Reading:

    items = [json.loads(line) for line in file]

or

    items = [json.loads(line) for line in jsondata.splitlines()]

See also issue31553 and issue34393. I think all these propositions should be rejected.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Thu Aug 30 00:31:25 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Aug 2018 04:31:25 +0000
Subject: [issue30618] readlink for pathlib paths
In-Reply-To: <1497052559.7.0.422106710991.issue30618@psf.upfronthosting.co.za>
Message-ID: <1535603485.81.0.56676864532.issue30618@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

The resolve() method already solves symlinks, but I think this is a reasonable feature request. I've just reviewed PR 8285.

----------
nosy: +berker.peksag, pitrou
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30618>
_______________________________________

From report at bugs.python.org  Thu Aug 30 00:37:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Aug 2018 04:37:57 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1535603877.07.0.56676864532.issue1529353@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I partly answered questions already.

1. Yes.  Always show.  Fix delay at 80 until we decide on something better.

2. No.  Max should be enough.  I once printed over 500_000 short lines to see if scrolling remained responsive.  It did.  I could have set min to 1_000_000 for that experiment.  Am I correct in presuming that only one block of output, between code imputs, can be squeezed?

Converting extensions to features mostly removed the option to omit features.

3. No, if not gone already.  I don't want to proliferate keyboard shortcuts, at least not until we get rid of some that must be nearly unused.

I want to make revising the use of keys within output blocks a separate issue.

4. Maybe nnnn chars would be better.

'a'*1000 currently wraps to 13 80-char lines.  (This would change if we add horizontal scrollbar, as has been requested.)  The viewer does not wrap.  I think it should as there is now no way to see entire line.  Or it needs a scrollbar.  Viewer is modal, but does it need to be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Thu Aug 30 00:42:05 2018
From: report at bugs.python.org (Noah Haasis)
Date: Thu, 30 Aug 2018 04:42:05 +0000
Subject: [issue34545] error in the repl due to indentation
Message-ID: <1535604125.2.0.56676864532.issue34545@psf.upfronthosting.co.za>


New submission from Noah Haasis <haasis_noah at yahoo.de>:

Pressing the tab key in the python REPL in my command line (cmder on windows 10 32bit) causes an exception:
>>> Readline internal error                                                                                                                       
Traceback (most recent call last):                                                                                                                
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\console\console.py", line 768, in hook_wrapper_23   
    res = ensure_str(readline_hook(prompt))                                                                                                       
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\rlmain.py", line 571, in readline                   
    self._readline_from_keyboard()                                                                                                                
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\rlmain.py", line 536, in _readline_from_keyboard    
    if self._readline_from_keyboard_poll():                                                                                                       
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\rlmain.py", line 556, in _readline_from_keyboard_pol
    result = self.mode.process_keyevent(event.keyinfo)                                                                                            
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\modes\emacs.py", line 243, in process_keyevent      
    r = self.process_keyevent_queue[-1](keyinfo)                                                                                                  
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\modes\emacs.py", line 286, in _process_keyevent     
    r = dispatch_func(keyinfo)                                                                                                                    
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\modes\basemode.py", line 257, in complete           
    completions = self._get_completions()                                                                                                         
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\site-packages\pyreadline\modes\basemode.py", line 200, in _get_completions   
    r = self.completer(ensure_unicode(text), i)                                                                                                   
  File "C:\Users\leinw\AppData\Local\Programs\Python\Python36-32\lib\rlcompleter.py", line 80, in complete                                        
    readline.redisplay()                                                                                                                          
AttributeError: module 'readline' has no attribute 'redisplay'                                                                              

This happens even if python expects indentation.

----------
components: Windows
messages: 324366
nosy: noah.haasis, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: error in the repl due to indentation
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34545>
_______________________________________

From report at bugs.python.org  Thu Aug 30 00:59:25 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 30 Aug 2018 04:59:25 +0000
Subject: [issue34540] shutil._call_external_zip should use subprocess
In-Reply-To: <1535519418.39.0.56676864532.issue34540@psf.upfronthosting.co.za>
Message-ID: <1535605165.87.0.56676864532.issue34540@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d8b103b8b3ef9644805341216963a64098642435 by Benjamin Peterson in branch '2.7':
closes bpo-34540: Convert shutil._call_external_zip to use subprocess rather than distutils.spawn. (GH-8985)
https://github.com/python/cpython/commit/d8b103b8b3ef9644805341216963a64098642435


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34540>
_______________________________________

From report at bugs.python.org  Thu Aug 30 01:00:32 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 30 Aug 2018 05:00:32 +0000
Subject: [issue34495] excess_args asserts if args == nullptr
In-Reply-To: <1535178135.11.0.56676864532.issue34495@psf.upfronthosting.co.za>
Message-ID: <1535605232.9.0.56676864532.issue34495@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34495>
_______________________________________

From report at bugs.python.org  Thu Aug 30 01:25:57 2018
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 30 Aug 2018 05:25:57 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1535606757.34.0.56676864532.issue34542@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset e6dac0077996b1e1f886f036d6f2606237fa4c85 by Christian Heimes in branch 'master':
bpo-34542: Update test certs and keys (GH-8997)
https://github.com/python/cpython/commit/e6dac0077996b1e1f886f036d6f2606237fa4c85


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Thu Aug 30 01:26:15 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Aug 2018 05:26:15 +0000
Subject: [issue34542] [TLS] Update test certs to future proof settings
In-Reply-To: <1535552236.3.0.56676864532.issue34542@psf.upfronthosting.co.za>
Message-ID: <1535606775.52.0.56676864532.issue34542@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8477

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34542>
_______________________________________

From report at bugs.python.org  Thu Aug 30 02:16:29 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Aug 2018 06:16:29 +0000
Subject: [issue34545] error in the repl due to indentation
In-Reply-To: <1535604125.2.0.56676864532.issue34545@psf.upfronthosting.co.za>
Message-ID: <1535609789.29.0.56676864532.issue34545@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this related to pyreadline? I can see an upstream issue with similar traceback and an open PR with some discussion.

GitHub issue : https://github.com/pyreadline/pyreadline/issues/49
Open PR : https://github.com/pyreadline/pyreadline/pull/51

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34545>
_______________________________________

From report at bugs.python.org  Thu Aug 30 03:28:57 2018
From: report at bugs.python.org (ron)
Date: Thu, 30 Aug 2018 07:28:57 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535614137.49.0.56676864532.issue34529@psf.upfronthosting.co.za>


ron <ron at mailinator.com> added the comment:

I'm a bit confused here.

On one hand you say it's two lines of code. On other hand you suggest that each service provider will implement it's own functions.

What's the harm from adding - small , unbreakable functionality? 

Your points for small code could have also been raised against implementing reverse() - yet Python still implemented it - saved the 2 line code from the developer.

At the end.. small change or not.. This is a new format.
Conversion between formats are required from any programming language..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Thu Aug 30 04:00:11 2018
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 30 Aug 2018 08:00:11 +0000
Subject: [issue34529] add the option for json.dumps to return newline
 delimited json
In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za>
Message-ID: <1535616011.14.0.56676864532.issue34529@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I suggested that each module would likely implement its own functions tailored to that project's IO and error handling requirements. The implementation may differ slightly depending on the protocol. This is consistent with how JSON is typically dealt with from a web framework, for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34529>
_______________________________________

From report at bugs.python.org  Thu Aug 30 04:40:25 2018
From: report at bugs.python.org (=?utf-8?b?5aSn6YeO6ZqG5byY?=)
Date: Thu, 30 Aug 2018 08:40:25 +0000
Subject: [issue34546] Zipfile encryption function
Message-ID: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>


New submission from ???? <oono0114 at gmail.com>:

from https://mail.python.org/pipermail/python-ideas/2018-August/053081.html

I would like to use zipfile encryption as python standard library.
https://github.com/python/cpython/blob/master/Lib/zipfile.py

Below document says "currently" cannot.
https://github.com/python/cpython/blob/master/Doc/library/zipfile.rst
"but it currently cannot create an encrypted file."

Current pythonians like me have to use 3rd party like below, but I believe it is worth to include.
https://pypi.org/project/pyminizip/
https://github.com/wllm-rbnt/py-zipcrypt

----------
components: Library (Lib)
messages: 324372
nosy: ????
priority: normal
severity: normal
status: open
title: Zipfile encryption function
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34546>
_______________________________________

From report at bugs.python.org  Thu Aug 30 05:28:13 2018
From: report at bugs.python.org (Petter S)
Date: Thu, 30 Aug 2018 09:28:13 +0000
Subject: [issue33965] [Windows WSL] Fatal Python error:
 _Py_InitializeMainInterpreter: can't initialize time, after year 2038
In-Reply-To: <1530000340.86.0.56676864532.issue33965@psf.upfronthosting.co.za>
Message-ID: <1535621293.06.0.56676864532.issue33965@psf.upfronthosting.co.za>


Petter S <petter.strandmark at gmail.com> added the comment:

I am updating this bug since someone may find it.

The problem lies with WSL. After having my computer running for many days, this is the result of the uptime command:

$ uptime
 11:23:19 up -24855 days, -3:-14,  0 users,  load average: 0.52, 0.58, 0.59

Restarting the computer fixes this and the Python issue discussed in this thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33965>
_______________________________________

From report at bugs.python.org  Thu Aug 30 05:36:49 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 30 Aug 2018 09:36:49 +0000
Subject: [issue1529353] Squeezer - squeeze large output in IDLE's shell
Message-ID: <1535621809.28.0.56676864532.issue1529353@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

> 1. Yes.  Always show.  Fix delay at 80 until we decide on something better.

Done.

> 2. No.  Max should be enough.

Done.

> I once printed over 500_000 short lines to see if scrolling remained responsive.  It did.  I could have set min to 1_000_000 for that experiment.  Am I correct in presuming that only one block of output, between code imputs, can be squeezed?

Indeed.

> 3. No, if not gone already.  I don't want to proliferate keyboard shortcuts, at least not until we get rid of some that must be nearly unused.

Done.

> 4. Maybe nnnn chars would be better.

I'm still not sure, that just leads to very large numbers, where it's hard to judge what is excessive, e.g., "is 100,000 chars too much"?  With lines, I feel it is more obvious: "1,000 lines? That's way too much!"

> The viewer does not wrap.  I think it should as there is now no way to see entire line.  Or it needs a scrollbar.

Wrapping is the major cause of the text widget slowing down, which is why I've made the viewer support controlling the wrapping mode, and made Squeezer use no wrapping.  I've now added a horizontal scrollbar, and also made the scrollbars in the viewer appear only when needed.  Now, scrolling horizontally with very long lines is still slow, but at least just the viewer is affected.

> Viewer is modal, but does it need to be?

No, good catch, changed to non-modal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1529353>
_______________________________________

From report at bugs.python.org  Thu Aug 30 06:17:15 2018
From: report at bugs.python.org (Petter S)
Date: Thu, 30 Aug 2018 10:17:15 +0000
Subject: [issue34547] Wsgiref server does not handle closed connections
 gracefully
Message-ID: <1535624235.67.0.56676864532.issue34547@psf.upfronthosting.co.za>


New submission from Petter S <petter.strandmark at gmail.com>:

The server in the wsgiref module is actually used a lot. For example, it is the server Django uses for development.

A very common thing that happens during Django development is that the web browser closes the connection for some reason. Then very long stack traces appear in the Django logs:

    [30/Aug/2018 12:10:38] "POST /login/ HTTP/1.1" 200 3964
    Traceback (most recent call last):
      File "d:\python37\Lib\wsgiref\handlers.py", line 138, in run
        self.finish_response()
      File "d:\python37\Lib\wsgiref\handlers.py", line 180, in finish_response
        self.write(data)
      File "d:\python37\Lib\wsgiref\handlers.py", line 274, in write
        self.send_headers()
      File "d:\python37\Lib\wsgiref\handlers.py", line 332, in send_headers
        self.send_preamble()
      File "d:\python37\Lib\wsgiref\handlers.py", line 255, in send_preamble
        ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
      File "d:\python37\Lib\wsgiref\handlers.py", line 453, in _write
        result = self.stdout.write(data)
      File "d:\python37\Lib\socketserver.py", line 796, in write
        self._sock.sendall(b)
    ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine
    [30/Aug/2018 12:10:38] "POST /login/ HTTP/1.1" 500 59
    ----------------------------------------
    Exception happened during processing of request from ('127.0.0.1', 50112)
    Traceback (most recent call last):
      File "d:\python37\Lib\wsgiref\handlers.py", line 138, in run
        self.finish_response()
      File "d:\python37\Lib\wsgiref\handlers.py", line 180, in finish_response
        self.write(data)
      File "d:\python37\Lib\wsgiref\handlers.py", line 274, in write
        self.send_headers()
      File "d:\python37\Lib\wsgiref\handlers.py", line 332, in send_headers
        self.send_preamble()
      File "d:\python37\Lib\wsgiref\handlers.py", line 255, in send_preamble
        ('Date: %s\r\n' % format_date_time(time.time())).encode('iso-8859-1')
      File "d:\python37\Lib\wsgiref\handlers.py", line 453, in _write
        result = self.stdout.write(data)
      File "d:\python37\Lib\socketserver.py", line 796, in write
        self._sock.sendall(b)
    ConnectionAbortedError: [WinError 10053] An established connection was aborted by the software in your host machine

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "d:\python37\Lib\wsgiref\handlers.py", line 141, in run
        self.handle_error()
      File "D:\Virtualenvs\ledev-X6wd5Q8f\lib\site-packages\django\core\servers\basehttp.py", line 86, in handle_error
        super().handle_error()
      File "d:\python37\Lib\wsgiref\handlers.py", line 368, in handle_error
        self.finish_response()
      File "d:\python37\Lib\wsgiref\handlers.py", line 180, in finish_response
        self.write(data)
      File "d:\python37\Lib\wsgiref\handlers.py", line 274, in write
        self.send_headers()
      File "d:\python37\Lib\wsgiref\handlers.py", line 331, in send_headers
        if not self.origin_server or self.client_is_modern():
      File "d:\python37\Lib\wsgiref\handlers.py", line 344, in client_is_modern
        return self.environ['SERVER_PROTOCOL'].upper() != 'HTTP/0.9'
    TypeError: 'NoneType' object is not subscriptable

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "d:\python37\Lib\socketserver.py", line 647, in process_request_thread
        self.finish_request(request, client_address)
      File "d:\python37\Lib\socketserver.py", line 357, in finish_request
        self.RequestHandlerClass(request, client_address, self)
      File "d:\python37\Lib\socketserver.py", line 717, in __init__
        self.handle()
      File "D:\Virtualenvs\ledev-X6wd5Q8f\lib\site-packages\django\core\servers\basehttp.py", line 154, in handle
        handler.run(self.server.get_app())
      File "d:\python37\Lib\wsgiref\handlers.py", line 144, in run
        self.close()
      File "d:\python37\Lib\wsgiref\simple_server.py", line 35, in close
        self.status.split(' ',1)[0], self.bytes_sent
    AttributeError: 'NoneType' object has no attribute 'split'
    ----------------------------------------


Obviously, this is a bit annoying when developing with Django daily. Since Django simply uses the wsgiref server, I though the best solution was to handle closed connections more gracefully there.

I think the best solution is to simply add another except clause here: https://github.com/python/cpython/blob/e6dac0077996b1e1f886f036d6f2606237fa4c85/Lib/wsgiref/handlers.py#L142 . We should catch ConnectionAbortedError here and return from the function.

I am happy to create a PR if this is what we want to do.

----------
components: Library (Lib)
messages: 324375
nosy: Petter S
priority: normal
severity: normal
status: open
title: Wsgiref server does not handle closed connections gracefully
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34547>
_______________________________________

From report at bugs.python.org  Thu Aug 30 06:17:31 2018
From: report at bugs.python.org (Petter S)
Date: Thu, 30 Aug 2018 10:17:31 +0000
Subject: [issue34547] Wsgiref server does not handle closed connections
 gracefully
In-Reply-To: <1535624235.67.0.56676864532.issue34547@psf.upfronthosting.co.za>
Message-ID: <1535624251.51.0.56676864532.issue34547@psf.upfronthosting.co.za>


Change by Petter S <petter.strandmark at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34547>
_______________________________________

From report at bugs.python.org  Thu Aug 30 06:26:43 2018
From: report at bugs.python.org (ernest ruiz)
Date: Thu, 30 Aug 2018 10:26:43 +0000
Subject: [issue33803] contextvars: hamt_alloc() must initialize h_root and
 h_count fields
In-Reply-To: <1528415094.5.0.592728768989.issue33803@psf.upfronthosting.co.za>
Message-ID: <1535624803.84.0.56676864532.issue33803@psf.upfronthosting.co.za>


Change by ernest ruiz <rernest893 at gmail.com>:


----------
type: crash -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33803>
_______________________________________

From report at bugs.python.org  Thu Aug 30 07:13:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Aug 2018 11:13:12 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1535627592.17.0.56676864532.issue26901@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Pablo, Serhiy: there are now 2 PR (one written by Pablo, one by me). Would you mind to have a look and tell me what is your preferred PR? My PR is based on Pablo's PR, I just changed how the tests are run to make sure that they are run on *all* CIs, not just Travis CI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26901>
_______________________________________

From report at bugs.python.org  Thu Aug 30 07:23:33 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Aug 2018 11:23:33 +0000
Subject: [issue33803] contextvars: hamt_alloc() must initialize h_root and
 h_count fields
In-Reply-To: <1528415094.5.0.592728768989.issue33803@psf.upfronthosting.co.za>
Message-ID: <1535628213.7.0.56676864532.issue33803@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
type: enhancement -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33803>
_______________________________________

From report at bugs.python.org  Thu Aug 30 07:44:42 2018
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 30 Aug 2018 11:44:42 +0000
Subject: [issue34545] error in the repl due to indentation
In-Reply-To: <1535604125.2.0.56676864532.issue34545@psf.upfronthosting.co.za>
Message-ID: <1535629482.77.0.56676864532.issue34545@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34545>
_______________________________________

From report at bugs.python.org  Thu Aug 30 07:47:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Aug 2018 11:47:52 +0000
Subject: [issue33965] [Windows WSL] Fatal Python error:
 _Py_InitializeMainInterpreter: can't initialize time, after year 2038
In-Reply-To: <1530000340.86.0.56676864532.issue33965@psf.upfronthosting.co.za>
Message-ID: <1535629672.9.0.56676864532.issue33965@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> 11:23:19 up -24855 days, -3:-14,  0 users,  load average: 0.52, 0.58, 0.59

Impressive uptime!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33965>
_______________________________________

From report at bugs.python.org  Thu Aug 30 07:56:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Aug 2018 11:56:10 +0000
Subject: [issue34544] FreeBSD: Fatal Python error: get_locale_encoding: failed
 to get the locale encoding: nl_langinfo(CODESET) failed
In-Reply-To: <1535585866.04.0.56676864532.issue34544@psf.upfronthosting.co.za>
Message-ID: <1535630170.46.0.56676864532.issue34544@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

I cannot reproduce the issue on my FreeBSD 11.1 VM. I cannot reproduce the issue on Koobs's "CURRENT-amd64%" buildbot neither :-(

Example:

CURRENT-amd64% env -i LC_ALL=invalid LC_CTYPE=invalid LANG=invalid PYTHONUTF8=0 PYTHONCOERCECLOCALE=0 ./python -X utf8=0 -c pass      

(no error)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34544>
_______________________________________

From report at bugs.python.org  Thu Aug 30 07:59:33 2018
From: report at bugs.python.org (Sergey G. Brester)
Date: Thu, 30 Aug 2018 11:59:33 +0000
Subject: [issue34489] subprocess: execution of batch-files (.cmd/.bat) is
 vulnerable in python for windows / insufficient escape
In-Reply-To: <1535139850.17.0.56676864532.issue34489@psf.upfronthosting.co.za>
Message-ID: <1535630373.95.0.56676864532.issue34489@psf.upfronthosting.co.za>


Sergey G. Brester <serg.brester at sebres.de> added the comment:

I have extended the PR a bit (more tests and corresponding documentation part).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34489>
_______________________________________

From report at bugs.python.org  Thu Aug 30 08:32:37 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Aug 2018 12:32:37 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1535632357.63.0.56676864532.issue34530@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

find_executable() always searches executables from the current directory. This effectively equivalent having os.curdir at the start of path. shutil.which() does this only on Windows. This change LGTM, but it potentially can break user code, thus it may be not safe to make it in maintained versions.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34530>
_______________________________________

From report at bugs.python.org  Thu Aug 30 08:39:32 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 30 Aug 2018 12:39:32 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
Message-ID: <1535632772.52.0.56676864532.issue34548@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
assignee: taleinat
components: IDLE
nosy: taleinat, terry.reedy
priority: low
severity: normal
status: open
title: IDLE: Make TextView use the configured theme colors
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Thu Aug 30 08:45:47 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 30 Aug 2018 12:45:47 +0000
Subject: [issue34548] IDLE: Make TextView use the configured theme colors
Message-ID: <1535633147.36.0.56676864532.issue34548@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
keywords: +patch
pull_requests: +8478
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34548>
_______________________________________

From report at bugs.python.org  Thu Aug 30 09:15:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Aug 2018 13:15:19 +0000
Subject: [issue34530] distutils: find_executable() fails if the PATH
 environment variable is not set
In-Reply-To: <1535460451.64.0.56676864532.issue34530@psf.upfronthosting.co.za>
Message-ID: <1535634919.65.0.56676864532.issue34530@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> find_executable() always searches executables from the current directory.

Oh! I didn't notice that!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34530>
_______________________________________

From report at bugs.python.org  Thu Aug 30 09:50:02 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Aug 2018 13:50:02 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
In-Reply-To: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>
Message-ID: <1535637002.77.0.56676864532.issue34539@psf.upfronthosting.co.za>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Thu Aug 30 09:53:23 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 30 Aug 2018 13:53:23 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535637203.47.0.56676864532.issue34485@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, there were some good reasons I went with the relatively brute force option of provideding Blender with a new config API call back in bpo-16129 - as we've seen, actually fixing it properly has been a multi-year multi-person effort :)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Thu Aug 30 10:04:19 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 30 Aug 2018 14:04:19 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1535637859.75.0.56676864532.issue21145@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This has now been merged.

Thanks for the multiple iterations on the implementation Carl, and thanks for the original proposal, Omer!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Thu Aug 30 10:46:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Aug 2018 14:46:23 +0000
Subject: [issue34485] _PyCoreConfig: add stdio_encoding and stdio_errors
In-Reply-To: <1535067849.47.0.56676864532.issue34485@psf.upfronthosting.co.za>
Message-ID: <1535640383.91.0.56676864532.issue34485@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> Yeah, there were some good reasons I went with the relatively brute force option of provideding Blender with a new config API call back in bpo-16129 - as we've seen, actually fixing it properly has been a multi-year multi-person effort :)

Yeah, I see ;-) Thanks for Py_SetStandardStreamEncoding(), it fixed Blender use case!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34485>
_______________________________________

From report at bugs.python.org  Thu Aug 30 10:48:07 2018
From: report at bugs.python.org (Nick)
Date: Thu, 30 Aug 2018 14:48:07 +0000
Subject: [issue34549] unittest docs could use another header
Message-ID: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>


New submission from Nick <manifes7o at gmail.com>:

I find myself reaching for a list of the assert methods in the unittest library often. There are several methods but no clear way to link a URL via a header if you intend to bookmark or send it out.

I have been using the method above the section in the meantime

https://docs.python.org/3.7/library/unittest.html#unittest.TestCase.debug

Would be great to have an `Assert Methods` header or some other equivalent.

Thank you!

----------
assignee: docs at python
components: Documentation
messages: 324385
nosy: docs at python, napsterinblue
priority: normal
severity: normal
status: open
title: unittest docs could use another header
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34549>
_______________________________________

From report at bugs.python.org  Thu Aug 30 11:42:41 2018
From: report at bugs.python.org (Carl Meyer)
Date: Thu, 30 Aug 2018 15:42:41 +0000
Subject: [issue21145] Add the @cached_property decorator
In-Reply-To: <1396520932.53.0.707047361064.issue21145@psf.upfronthosting.co.za>
Message-ID: <1535643761.46.0.56676864532.issue21145@psf.upfronthosting.co.za>


Carl Meyer <carl at oddbird.net> added the comment:

Thanks everyone for the thoughtful and careful reviews! Patch is much improved from where it started. And thanks Nick for merging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21145>
_______________________________________

From report at bugs.python.org  Thu Aug 30 11:44:17 2018
From: report at bugs.python.org (=?utf-8?q?=C3=81lvaro_Justen?=)
Date: Thu, 30 Aug 2018 15:44:17 +0000
Subject: [issue34539] namedtuple's exec() throws segmentation fault
In-Reply-To: <1535516450.51.0.56676864532.issue34539@psf.upfronthosting.co.za>
Message-ID: <1535643857.24.0.56676864532.issue34539@psf.upfronthosting.co.za>


?lvaro Justen <alvarojusten at gmail.com> added the comment:

Yes, I think it was fixed in https://bugs.python.org/issue34087 (didn't see the commits), I just wanted to report it because I don't know if a test for this specific case is needed (the other bug is not related to namedtuples).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34539>
_______________________________________

From report at bugs.python.org  Thu Aug 30 11:54:19 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Aug 2018 15:54:19 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535644459.93.0.56676864532.issue34538@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

See https://bugs.python.org/issue443559 and "git log -p 13af42822cd".

One other example from real code:  requests.RequestException

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Thu Aug 30 11:55:48 2018
From: report at bugs.python.org (Tao Chen)
Date: Thu, 30 Aug 2018 15:55:48 +0000
Subject: [issue34550] UnicodeDecodeError when invoke method configure() of
 Menu instance
Message-ID: <1535644548.51.0.56676864532.issue34550@psf.upfronthosting.co.za>


New submission from Tao Chen <sbellct at 163.com>:

[Brief Description]
Python 3.7.0 IDLE. After create one Menu instance, and invoke it's config() or configure() method without any parameter, python print UnicodeDecodeError.


[Walk around]
menubar = Menu(root)
menubar.config(font=('Arial'))



[LOG]
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> from tkinter import *
>>> root = Tk()
>>> menubar = Menu(root)
>>> menubar.config()
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    menubar.config()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 2: invalid continuation byte


>>> menubar.cget('font')
Traceback (most recent call last):
  File "<pyshell#15>", line 1, in <module>
    menubar.cget('font')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 2: invalid continuation byte

>>> platform.uname()
uname_result(system='Windows', node='xxx', release='7', version='6.1.7601', machine='AMD64', processor='Intel64 Family 6 Model 78 Stepping 3, GenuineIntel')

----------
components: Tkinter
messages: 324389
nosy: sbellct
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when invoke method configure() of Menu instance
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34550>
_______________________________________

From report at bugs.python.org  Thu Aug 30 12:10:36 2018
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Aug 2018 16:10:36 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535645436.65.0.56676864532.issue34538@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm not questioning if people have ever created a base exception for an entire package, I'm just asking how often it's actually used when the base exception didn't make sense outside of the rule-of-thumb Nathaniel is pointing out?

For instance, it could makes sense in requests' case to have a base exception to help facilitate catching network-related errors but let through e.g. TypeError. But does that extend to most packages such that users regularly write an 'except' clause catching that package's common base exception type? That's my question and I personally don't have an answer beyond reflecting on this and not really remembering a case where I have (I _can_ remember following this pattern simply because it's habit at this point for some unknown reason :) .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Thu Aug 30 12:17:30 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 30 Aug 2018 16:17:30 +0000
Subject: [issue34200] importlib: python -m test test_pkg -m test_7 fails
 randomly
In-Reply-To: <1532349909.53.0.56676864532.issue34200@psf.upfronthosting.co.za>
Message-ID: <1535645850.48.0.56676864532.issue34200@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given that importlib is essentially just doing "listdir", it would be interesting to know how the following behaves in a tight loop on affected systems:
    
    # Write a file
    f = open(os.path.join(dirname, "testname.py"), "w")
    f.write("text\n")
    f.close()
    # Make a directory
    os.mkdir(os.path.join(dirname, "testname"))
    # List the directory
    os.listdir(dirname)

The core assumption that test_pkg is indirectly making is that the directory listing in importlib will always list both entries created by the test suite without any special care being needed at the application level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34200>
_______________________________________

From report at bugs.python.org  Thu Aug 30 12:34:36 2018
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 30 Aug 2018 16:34:36 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535646876.16.0.56676864532.issue34538@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

For some empirical data, I went through some popular packages that follow this pattern and searched for usage of their base exception classes:

Requests: https://github.com/search?q=except+requests.RequestException&type=Code

PyYaml: https://github.com/search?q=except+yaml.YAMLError&type=Code

Jinja2: https://github.com/search?q=%22except+jinja2.TemplateError%22&type=Code

https://github.com/search?q=%22except+jinja2.exceptions.TemplateError%22&type=Code

https://github.com/search?q=%22except+TemplateError%22&type=Code

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Thu Aug 30 12:56:20 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Aug 2018 16:56:20 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1535648180.49.0.56676864532.issue34427@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 1b5f9c9653f348b0aa8b7ca39f8a9361150f7dfc by Raymond Hettinger (Naris R) in branch 'master':
bpo-34427: Fix infinite loop when calling MutableSequence.extend() on self (GH-8813)
https://github.com/python/cpython/commit/1b5f9c9653f348b0aa8b7ca39f8a9361150f7dfc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Thu Aug 30 12:56:54 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Aug 2018 16:56:54 +0000
Subject: [issue34427] calling MutableSequence.extend on self produces infinite
 loop
In-Reply-To: <1534586311.51.0.56676864532.issue34427@psf.upfronthosting.co.za>
Message-ID: <1535648214.92.0.56676864532.issue34427@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for the patch.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34427>
_______________________________________

From report at bugs.python.org  Thu Aug 30 13:17:17 2018
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 30 Aug 2018 17:17:17 +0000
Subject: [issue27923] PEP 467 -- Minor API improvements for binary sequences
In-Reply-To: <1472691379.75.0.669592694643.issue27923@psf.upfronthosting.co.za>
Message-ID: <1535649437.31.0.56676864532.issue27923@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27923>
_______________________________________

From report at bugs.python.org  Thu Aug 30 13:17:20 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Aug 2018 17:17:20 +0000
Subject: [issue34550] UnicodeDecodeError when invoke method configure() of
 Menu instance
In-Reply-To: <1535644548.51.0.56676864532.issue34550@psf.upfronthosting.co.za>
Message-ID: <1535649440.26.0.56676864532.issue34550@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34550>
_______________________________________

From report at bugs.python.org  Thu Aug 30 13:27:21 2018
From: report at bugs.python.org (Eric Lippert)
Date: Thu, 30 Aug 2018 17:27:21 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
Message-ID: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>


New submission from Eric Lippert <ericlippert at gmail.com>:

In _PyFunction_FastCallDict we have local nk assigned to be the size of a dictionary, and then local i is assigned to twice the size of the same dictionary, and then nk is assigned to half of i, which it already is:

   nk = (kwargs != NULL) ? PyDict_GET_SIZE(kwargs) : 0;
   if (nk != 0) {
     ...
     pos = i = 0;
     while (PyDict_Next(kwargs, &pos, &k[i], &k[i+1])) {
       ...
       i += 2;
     }
     nk = i / 2;

I am attempting to understand the performance characteristics of this hot path, and I spent far too long trying to figure out why nk was being assigned a value it already has. :)

I propose that the redundant store be replaced with an assertion that i/2 is equal to nk.

I will submit a pull request presently.

----------
components: Interpreter Core
messages: 324395
nosy: Eric Lippert
priority: normal
severity: normal
status: open
title: Redundant store can be removed from _PyFunction_FastCallDict
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Thu Aug 30 13:51:25 2018
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Aug 2018 17:51:25 +0000
Subject: [issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms,
 Ubuntu: 0.063ms
In-Reply-To: <1535484021.65.0.56676864532.issue34535@psf.upfronthosting.co.za>
Message-ID: <1535651485.63.0.56676864532.issue34535@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Agreed with not putting platform-specific details everywhere, but in this case we can probably have a generic wording for "Blocks for `timeout` seconds as best as is available on the current operating system".

It is a general problem across all timeouts, so someone probably ought to do a full pass to find anywhere it matters. I'm not volunteering for that though!

About the only other possible fix is to figure out the current resolution, and replace any waits with shorter timeouts with a spin-lock. But in general I would rather leave this to the operating system and just document that we can't always overrule decisions made by the OS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34535>
_______________________________________

From report at bugs.python.org  Thu Aug 30 14:02:07 2018
From: report at bugs.python.org (Eric Lippert)
Date: Thu, 30 Aug 2018 18:02:07 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535652126.99.0.56676864532.issue34551@psf.upfronthosting.co.za>


Change by Eric Lippert <ericlippert at gmail.com>:


----------
keywords: +patch
pull_requests: +8479
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Thu Aug 30 14:08:40 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 30 Aug 2018 18:08:40 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535652520.37.0.56676864532.issue34481@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

@izbyshev That's totally fair and I wouldn't want to make it a condition of merging the existing fixes - I've already made great progress in fixing the time.strftime part as well.

The main reason it relates here is that I generally find the tests to be among the hardest part about writing a good PR, and if we can't make assertions about the behavior of strftime outputs, I think it makes it hard to prevent regressions. I figured if I can solve the problem all the way down the stack in one go, I might as well.

That said, Victor makes an *extremely* good point that this is an outsized effort for the bug it's fixing. No one really *needs* support for unpaired surrogates in their strftime as far as I can tell. The main reason I'm still working on it is that I'm curious to see if it's even possible to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Thu Aug 30 14:54:26 2018
From: report at bugs.python.org (Grant Jenks)
Date: Thu, 30 Aug 2018 18:54:26 +0000
Subject: [issue34445] asyncio support in doctests
In-Reply-To: <1534786239.59.0.56676864532.issue34445@psf.upfronthosting.co.za>
Message-ID: <1535655266.28.0.56676864532.issue34445@psf.upfronthosting.co.za>


Grant Jenks <grant.jenks at gmail.com> added the comment:

This is not a bug in Python. The SyntaxError matches expected behavior. According to the Python grammar, you can't have "await" outside of a function. You have "await" at the globals scope which is not permitted. You may only "await" functions from within other functions.

Doctest is designed to emulate what you would type into the Python shell. Your doctest snippet does not work there either:


```
$ python3
Python 3.7.0 (default, Jun 28 2018, 05:55:06) 
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> async def hello_world():
...     return "Hello, world!"
... 
>>> await hello_world()
  File "<stdin>", line 1
SyntaxError: 'await' outside function
```

To make your doctests work, use ``asyncio.run`` like so:


```
import asyncio


async def hello_world():
    """
    Will greet the world with a friendly hello.

    >>> asyncio.run(hello_world())
    'hello world'

    """
    return "hello world"


if __name__ == "__main__":
    import doctest
    doctest.testmod()
```

Stefan, you may get a quicker answer next time from a forum like StackOverflow.

Yury, it's probably a good idea to cover this case in your upcoming asyncio docs improvements.

----------
nosy: +grantjenks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34445>
_______________________________________

From report at bugs.python.org  Thu Aug 30 14:57:02 2018
From: report at bugs.python.org (Michael Osipov)
Date: Thu, 30 Aug 2018 18:57:02 +0000
Subject: [issue34519] Add additional aliases for HP Roman 8
In-Reply-To: <1535377191.85.0.56676864532.issue34519@psf.upfronthosting.co.za>
Message-ID: <1535655422.72.0.56676864532.issue34519@psf.upfronthosting.co.za>


Michael Osipov <1983-01-06 at gmx.net> added the comment:

Wikipedia references it: https://en.wikipedia.org/wiki/HP_Roman#Roman-8
as well as IBM on its pages: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.wmqfte.doc/codepages.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34519>
_______________________________________

From report at bugs.python.org  Thu Aug 30 14:58:24 2018
From: report at bugs.python.org (Tercio Gaudencio Filho)
Date: Thu, 30 Aug 2018 18:58:24 +0000
Subject: [issue34226] cgi.parse_multipart() requires undocumented
 CONTENT-LENGTH in Python 3.7
In-Reply-To: <1532530540.72.0.56676864532.issue34226@psf.upfronthosting.co.za>
Message-ID: <1535655504.91.0.56676864532.issue34226@psf.upfronthosting.co.za>


Change by Tercio Gaudencio Filho <terciofilho at gmail.com>:


----------
nosy: +Tercio Gaudencio Filho

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34226>
_______________________________________

From report at bugs.python.org  Thu Aug 30 16:07:14 2018
From: report at bugs.python.org (Stefan Tjarks)
Date: Thu, 30 Aug 2018 20:07:14 +0000
Subject: [issue34445] asyncio support in doctests
In-Reply-To: <1534786239.59.0.56676864532.issue34445@psf.upfronthosting.co.za>
Message-ID: <1535659634.08.0.56676864532.issue34445@psf.upfronthosting.co.za>


Stefan Tjarks <stefan.tjarks at eventbase.com> added the comment:

Thanks Grant! I expected that I am missing something.

You are right that I could have posted in many places to get help about this. Before posting I tried to find a doctest for asyncio but my google magic failed me. At the end I just felt that, at the very least, the bug tracker would show that the doctest documentation could be updated to cover this.

That doctest emulate a Python shell helps me understand its limitations a bit more.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34445>
_______________________________________

From report at bugs.python.org  Thu Aug 30 16:50:02 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 30 Aug 2018 20:50:02 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1535662202.94.0.56676864532.issue22872@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +8480
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Thu Aug 30 16:56:27 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 30 Aug 2018 20:56:27 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1535662587.17.0.56676864532.issue22872@psf.upfronthosting.co.za>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Thu Aug 30 19:10:49 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 30 Aug 2018 23:10:49 +0000
Subject: [issue34481] Different behavior of C and Python impls of
 datetime.strftime with non-UTF-8-encodable strings
In-Reply-To: <1535046057.5.0.56676864532.issue34481@psf.upfronthosting.co.za>
Message-ID: <1535670649.33.0.56676864532.issue34481@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> if we can't make assertions about the behavior of strftime outputs, I think it makes it hard to prevent regressions.

Ironically, some of the changes we may have to make to fix time.strftime() inconsistencies may appear like regressions to some users. For example, regarding dropping wcsftime() on all platforms, 'man strftime' on macOS contains the following warning in BUGS section: "The strftime() function does not correctly handle multibyte characters in the format argument.". (I'm not sure what "incorrect handling" means here). That's not to discourage you, just to point out that we should be extra careful at this point when there might be users relying on every variety of the current behavior. And that's also why I don't want to mix the fix for C vs. Python issue (low risk) with changes in time.strftime() (high risk).

Also, while I certainly agree with "the outsized effort" point, it seems that your PR goes far beyond supporting surrogates because falling back to escaping allows one to bypass checks in wcsftime()/strftime() and round-trip any code point regardless of the current locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34481>
_______________________________________

From report at bugs.python.org  Thu Aug 30 19:15:27 2018
From: report at bugs.python.org (orlnub123)
Date: Thu, 30 Aug 2018 23:15:27 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1535670927.94.0.56676864532.issue34443@psf.upfronthosting.co.za>


Change by orlnub123 <orlnub123 at gmail.com>:


----------
pull_requests: +8481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Thu Aug 30 19:22:46 2018
From: report at bugs.python.org (orlnub123)
Date: Thu, 30 Aug 2018 23:22:46 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1535671366.88.0.56676864532.issue34443@psf.upfronthosting.co.za>


orlnub123 <orlnub123 at gmail.com> added the comment:

I've created a separate PR that also changes the __str__s.

----------
nosy: +orlnub123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Thu Aug 30 19:58:31 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Aug 2018 23:58:31 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535673511.9.0.56676864532.issue34551@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> vstinner
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Fri Aug 31 01:37:52 2018
From: report at bugs.python.org (Windson Yang)
Date: Fri, 31 Aug 2018 05:37:52 +0000
Subject: [issue34552] Clarify built-in types comparisons
Message-ID: <1535693872.67.0.56676864532.issue34552@psf.upfronthosting.co.za>


New submission from Windson Yang <wiwindson at gmail.com>:

In https://docs.python.org/3.5/library/stdtypes.html#comparisons 

"some types (for example, function objects) support only a degenerate notion of comparison where any two objects of that type are unequal."

We had some discussion at zulipchat already:

"more seriously: I think we can just delete that sentence. The next sentence makes clear that < and friends arne't always defined, and the sentence after that notes that == defaults to is if there's nothing better." - by Nathaniel J. Smith

IMO, I think we should also clarify the relationship between "==", "is" and "__eq__".

----------
assignee: docs at python
components: Documentation
messages: 324403
nosy: Windson Yang, docs at python, gvanrossum, njs, zach.ware
priority: normal
severity: normal
status: open
title: Clarify built-in types comparisons
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34552>
_______________________________________

From report at bugs.python.org  Fri Aug 31 01:43:56 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Fri, 31 Aug 2018 05:43:56 +0000
Subject: [issue32502] uuid1() fails if only 64-bit interface addresses are
 available
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <1535694236.79.0.56676864532.issue32502@psf.upfronthosting.co.za>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Could the fix be backported to 2.7 branch? Apparently on macOS 2.7 is also affected https://github.com/macports/macports-ports/pull/2456

----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From report at bugs.python.org  Fri Aug 31 02:45:35 2018
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 31 Aug 2018 06:45:35 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1535697935.0.0.56676864532.issue34461@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +8482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34461>
_______________________________________

From report at bugs.python.org  Fri Aug 31 03:19:44 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 31 Aug 2018 07:19:44 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535699984.05.0.56676864532.issue34538@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I didn't claim this pattern is not used anymore.
My point is "should we suggest this pattern for tutorial readers?"

* Is this pattern recommended blindly?  -- I think no.
* How / when this pattern is recommended?  -- When there is use case people want to catch the base exception.
* Should it be in tutorial?  -- I doubt it.  This topic requires some experience to understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Fri Aug 31 03:47:44 2018
From: report at bugs.python.org (Vijay)
Date: Fri, 31 Aug 2018 07:47:44 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
Message-ID: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>


New submission from Vijay <vijay.ramdass at gmail.com>:

MailItem.SentOn or MailItem.ReceivedTime, Python crashes with windows showing "Python has stopped working" dialog window. What can be the cause of this issue?

import win32com.client
import os
import datetime
from datetime import timedelta
outlook = win32com.client.Dispatch("Outlook.Application").GetNamespace("MAPI")
inbox = outlook.GetDefaultFolder(6)
messages=inbox.Items
message = messages.GetLast()

print(type(message))

t = message.ReceivedTime   ---- crashes when the script is reached this line.

Attached the screenshot for your reference.

----------
files: python crash.PNG
messages: 324406
nosy: vijay
priority: normal
severity: normal
status: open
title: Python Crashes when trying to access any date related fields in MailItem
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file47774/python crash.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Fri Aug 31 04:26:09 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 08:26:09 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535703969.53.0.56676864532.issue34551@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Technically it's possible that the dictionary mutates itself during iterating and so that it's size change, so "nk = i / 2;" make sure that we pass the proper length to the function call.

Maybe I'm wrong, but we would need an unit test for that.

While I reworked a lot of code in call.c (and I moved code to call.c ;-)), this specific statement already existed before my work. I moved it from somewhere else. Extract of Objects/funcobject.c:

static PyObject *
function_call(PyObject *func, PyObject *arg, PyObject *kw)
{
    ...
    if (kw != NULL && PyDict_Check(kw)) {
        ...
        while (PyDict_Next(kw, &pos, &k[i], &k[i+1])) {
            Py_INCREF(k[i]);
            Py_INCREF(k[i+1]);
            i += 2;
        }
        nk = i/2;
    }
    ...
}

It seems like the code is quite old :-)

commit 6d6c1a35e08b95a83dbe47dbd9e6474daff00354
Author: Tim Peters <tim.peters at gmail.com>
Date:   Thu Aug 2 04:15:00 2001 +0000

    Merge of descr-branch back into trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Fri Aug 31 04:48:49 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 31 Aug 2018 08:48:49 +0000
Subject: [issue34538] Remove encouragement to author a base class for all
 Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1535705329.02.0.56676864532.issue34538@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> https://github.com/search?q=%22except+TemplateError%22&type=Code

For example, I found flask_mako's TemplateException in this search result.

Strictly speaking, this is not base exception class.  It is wraps exception during template rendering.  But "why this class is useful?" is very similar to base exception class.

It provides better traceback for mako template.  They use this class for "particular reason", not because it's generally recommended practice.

And this "particular reason" shouldn't be in Python tutorial, clearly.

---

If we really need exception class hierarchy in tutorial, I think OSError is the best example.  When opening a file, `except OSError:` is much better than `except (PermissionError, FileNotFound, ...)`.  It's the most clear example when common base class for some distinct exceptions is useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34538>
_______________________________________

From report at bugs.python.org  Fri Aug 31 05:19:16 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Aug 2018 09:19:16 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535707156.64.0.56676864532.issue34347@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

The buildbots seem happy. This may be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Fri Aug 31 05:24:37 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Aug 2018 09:24:37 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1535707477.04.0.56676864532.issue34490@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Even if it is just in the spirit of issue29972 I hope this can be given a quick review and have yet one less test failing on the AIX bots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Fri Aug 31 05:27:33 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Aug 2018 09:27:33 +0000
Subject: [issue34382] test_os.test_mode fails when directory base directory
 has g+s set
In-Reply-To: <1533990666.21.0.56676864532.issue34382@psf.upfronthosting.co.za>
Message-ID: <1535707653.04.0.56676864532.issue34382@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

For now, backport only means, imho to 3.7 and maybe 3.6. More could be merrier - but the goal is to clear the buildbots for regression testing.

This one is quite simple - so adding 2.7 to the list of backports would be great.

----------
versions: +Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34382>
_______________________________________

From report at bugs.python.org  Fri Aug 31 05:29:06 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Aug 2018 09:29:06 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>
Message-ID: <1535707746.4.0.56676864532.issue34373@psf.upfronthosting.co.za>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Would be very nice to get this to clear on the build bots!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Fri Aug 31 05:42:11 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 31 Aug 2018 09:42:11 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535708531.71.0.56676864532.issue34551@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it is technically not possible. Neither PyDict_Next() nor Py_INCREF() mutate the dict, call the user code or release GIL. If it could be possible, we would have a potential writing out of a buffer here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Fri Aug 31 05:47:56 2018
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Aug 2018 09:47:56 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535708876.42.0.56676864532.issue34282@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

For versions 3.6 and 3.7 the solution is to modify the shadow check at line 236 so only DynamicClassAttributes are /not/ shadowed (meaning the _convert method would be shadowed by an _convert member).

For 3.8 we can move _convert to the metaclass: I wasn't originally supportive of this idea, but I can see it being useful for other Enum mix-ins such as str.  However, I will want to include a check that such a mix-in is there -- probably by checking that the Enum type is a subclass of the first member's type... something like:

    if not issubclass(cls, members[0]):
       raise TypeError(...)
While we're making that change we can also check that members is not empty and issue a friendlier error message.

We can also rename _convert to _convert_ in 3.8, but we'll need to have _convert also on the metaclass and have it trigger a warning that _convert_ is now the right way, and _convert will go away in 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34282>
_______________________________________

From report at bugs.python.org  Fri Aug 31 06:01:30 2018
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Aug 2018 10:01:30 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535709690.23.0.56676864532.issue34282@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
Removed message: https://bugs.python.org/msg324414

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34282>
_______________________________________

From report at bugs.python.org  Fri Aug 31 06:01:42 2018
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Aug 2018 10:01:42 +0000
Subject: [issue34282] Enum._convert shadows members named _convert
In-Reply-To: <1532972199.25.0.56676864532.issue34282@psf.upfronthosting.co.za>
Message-ID: <1535709702.87.0.56676864532.issue34282@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

For versions 3.6 and 3.7 the solution is to modify the shadow check at line 236 so only DynamicClassAttributes are /not/ shadowed (meaning the _convert method would be shadowed by an _convert member).

For 3.8 we can move _convert to the metaclass: I wasn't originally supportive of this idea, but I can see it being useful for other Enum mix-ins such as str.  However, I will want to include a check that such a mix-in is there -- probably by checking that the Enum type is a subclass of the first member's type... something like:

    if not issubclass(cls, members[0]):
       raise TypeError(...)

While we're making that change we can also check that members is not empty and issue a friendlier error message.

We can also rename _convert to _convert_ in 3.8, but we'll need to have _convert also on the metaclass and have it trigger a warning that _convert_ is now the right way, and _convert will go away in 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34282>
_______________________________________

From report at bugs.python.org  Fri Aug 31 08:24:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 12:24:35 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1535718275.19.0.56676864532.issue17239@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

This issue didn't get much attention in 5 years. The XML documentation starts with a big red warning:
https://docs.python.org/dev/library/xml.html

The warning is present in 2.7 and 3.4 as well:
https://docs.python.org/2.7/library/xml.html
https://docs.python.org/3.4/library/xml.html

It seems like XML is getting less popular because of JSON becoming more popular (JSON obviously comes with its own set of security issues). It seems like less core developers care about XML.

I suggest to:

* close bpo-17318 as a duplicate of this issue (bpo-17239)
* close bpo-24238
* close this issue

We just have to accept that core developers have limited availability and that documenting security issues is an acceptable tradeoff. I don't see any value of keeping these 3 issues open.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Fri Aug 31 08:54:08 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Aug 2018 12:54:08 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1535720048.21.0.56676864532.issue34553@psf.upfronthosting.co.za>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There is a very similar SO question https://stackoverflow.com/questions/51885734/python-crashes-when-i-am-trying-to-access-any-date-related-fields-in-mailitem-co which points to an AttributeError. Is this a case where Python segfaults or there is some stacktrace? Any chance you can provide the message or a reproducible script for this? I also hope this is something related specifically to Windows and someone might add in here about this.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Fri Aug 31 09:18:07 2018
From: report at bugs.python.org (Vijay)
Date: Fri, 31 Aug 2018 13:18:07 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1535721487.04.0.56676864532.issue34553@psf.upfronthosting.co.za>


Vijay <vijay.ramdass at gmail.com> added the comment:

i have already added the script. try to run in the python3.7. python is getting crashed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:17:50 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 14:17:50 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1535725070.39.0.56676864532.issue34347@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> The buildbots seem happy. This may be closed.

Cool, thank you for checking, and thanks for your fix! I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:19:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 14:19:52 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535725192.08.0.56676864532.issue34551@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

> I think it is technically not possible. Neither PyDict_Next() nor Py_INCREF() mutate the dict, call the user code or release GIL. If it could be possible, we would have a potential writing out of a buffer here.

When I read PyDict_Next(), I'm thinking at the Python level which can execute arbitrary code. But it seems like you are right: the exact C implementation of PyDict_Next() doesn't seem to modify the dictionary.

PR 9009 seems safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:20:56 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 31 Aug 2018 14:20:56 +0000
Subject: [issue34553] Python Crashes when trying to access any date related
 fields in MailItem
In-Reply-To: <1535701663.99.0.56676864532.issue34553@psf.upfronthosting.co.za>
Message-ID: <1535725256.89.0.56676864532.issue34553@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

win32com is part of pywin32, which is a 3th-party extension. Please check with that project first (if there is bug it is probably on that side).

----------
components: +Windows
nosy: +paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
resolution:  -> third party

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34553>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:22:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 14:22:46 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1535725366.75.0.56676864532.issue1230540@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

My concern is more about backward compatibility. Documentation is one thing, but usually users rely on the actual implementation, not on the documentation, to define what is the Python behaviour.

Would you mind to open a thread on python-dev about this change?

I don't want to take the responsibility alone of such change :-) Moreover, I don't really have the bandwidth to work on this specific issue :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:27:15 2018
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 31 Aug 2018 14:27:15 +0000
Subject: [issue34543] _struct.Struct: calling functions without calling
 __init__ results in SystemError
In-Reply-To: <1535559532.49.0.56676864532.issue34543@psf.upfronthosting.co.za>
Message-ID: <1535725635.36.0.56676864532.issue34543@psf.upfronthosting.co.za>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34543>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:43:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 14:43:38 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1535726618.65.0.56676864532.issue34097@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 77b112cd56a50232abcdbf28f9aba88dc5d33ad3 by Victor Stinner (Marcel Plch) in branch 'master':
bpo-34097: Polish API design (GH-8725)
https://github.com/python/cpython/commit/77b112cd56a50232abcdbf28f9aba88dc5d33ad3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:44:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Aug 2018 14:44:46 +0000
Subject: [issue34097] ZIP does not support timestamps before 1980
In-Reply-To: <1531319758.26.0.56676864532.issue34097@psf.upfronthosting.co.za>
Message-ID: <1535726686.51.0.56676864532.issue34097@psf.upfronthosting.co.za>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Petr Viktorin for reporting this issue and thanks Marcel Plch for the fix!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34097>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:45:23 2018
From: report at bugs.python.org (mokhalid)
Date: Fri, 31 Aug 2018 14:45:23 +0000
Subject: [issue34554] add match built in function
Message-ID: <1535726723.83.0.56676864532.issue34554@psf.upfronthosting.co.za>


New submission from mokhalid <mohammedkhaildson at gmail.com>:

match built-in function feature request:

what is the match function do?
the match function is doing something like if but with quick easy syntax that even beginners can use.

possible syntax:

match(list or string or dictionary):
  condition: event here
  condition: event here
#all conditions are applied at the same time as if not elif and else
#but you use elif or else.

ex:
match(list or string or dictionary):
  condition: event here
  condition: event here
    elif condition: event here
    else: event here
 

example of what I mean:
match([2,5,4,'Hello']):
  2: print('here is 2')
  6: print('here is 6')
    elif 'Hello': ('Hello world')
  8:print('here is 8')
    elif 'python': ('Hello world')
    else: print('MoKhalid')

the output should look like:
here is 2
Hello world
MoKhalid

----------
components: Regular Expressions
messages: 324425
nosy: MoKhaild, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: add match built in function
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34554>
_______________________________________

From report at bugs.python.org  Fri Aug 31 10:57:04 2018
From: report at bugs.python.org (mokhalid)
Date: Fri, 31 Aug 2018 14:57:04 +0000
Subject: [issue34554] add match built in function
In-Reply-To: <1535726723.83.0.56676864532.issue34554@psf.upfronthosting.co.za>
Message-ID: <1535727424.08.0.56676864532.issue34554@psf.upfronthosting.co.za>


mokhalid <mohammedkhaildson at gmail.com> added the comment:

sorry I forget to print text i mean:
match([2,5,4,'Hello']):
  2: print('here is 2')
  6: print('here is 6')
    elif 'Hello': print('Hello world')
  8:print('here is 8')
    elif 'python': print('Hello world')
    else: print('MoKhalid')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34554>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:04:26 2018
From: report at bugs.python.org (mokhalid)
Date: Fri, 31 Aug 2018 15:04:26 +0000
Subject: [issue34554] Add match built in functio
In-Reply-To: <1535726723.83.0.56676864532.issue34554@psf.upfronthosting.co.za>
Message-ID: <1535727866.91.0.56676864532.issue34554@psf.upfronthosting.co.za>


Change by mokhalid <mohammedkhaildson at gmail.com>:


----------
title: add match built in function -> Add match built in functio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34554>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:04:45 2018
From: report at bugs.python.org (mokhalid)
Date: Fri, 31 Aug 2018 15:04:45 +0000
Subject: [issue34554] Add match built-in function
In-Reply-To: <1535726723.83.0.56676864532.issue34554@psf.upfronthosting.co.za>
Message-ID: <1535727885.27.0.56676864532.issue34554@psf.upfronthosting.co.za>


Change by mokhalid <mohammedkhaildson at gmail.com>:


----------
title: Add match built in functio -> Add match built-in function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34554>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:12:14 2018
From: report at bugs.python.org (Thomas Herzog)
Date: Fri, 31 Aug 2018 15:12:14 +0000
Subject: [issue34555] AF_VSOCK not unset because of wrong nesting
Message-ID: <1535728334.14.0.56676864532.issue34555@psf.upfronthosting.co.za>


New submission from Thomas Herzog <tom at therzog.net>:

If ./configure runs with the following result...

checking for linux/vm_sockets.h... no
checking for sockaddr_alg... no

...then the result of the first check is treated as if it was "yes". This is because the logic for disabling the vm_sockets functionality is nested inside an #ifdef HAVE_SOCKADDR_ALG.

This leads to compilation errors:

In file included from ./Modules/socketmodule.c:283:0:
./Modules/socketmodule.h:206:24: error: field ?vm? has incomplete type
     struct sockaddr_vm vm;
                        ^

----------
components: Extension Modules
messages: 324427
nosy: mcduke
priority: normal
severity: normal
status: open
title: AF_VSOCK not unset because of wrong nesting
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34555>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:15:11 2018
From: report at bugs.python.org (Eric Snow)
Date: Fri, 31 Aug 2018 15:15:11 +0000
Subject: [issue34554] Add match built-in function
In-Reply-To: <1535726723.83.0.56676864532.issue34554@psf.upfronthosting.co.za>
Message-ID: <1535728511.44.0.56676864532.issue34554@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for the proposal.  At first glance I actually kind of like the idea, though I can't offer much more feedback than that without taking some time to think it through. :)

That said, proposals like this for new syntax and other new language features are best suited for the python-ideas at python.org mailing list. [1]  I recommend you make a post there.  I'm closing the issue as "rejected" because it belongs on python-ideas instead of here, not because we're rejecting the idea. :)

Thanks again!  I hope you post something about this to python-ideas.

[1] https://mail.python.org/mailman/listinfo/python-ideas

----------
nosy: +eric.snow
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34554>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:15:47 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 31 Aug 2018 15:15:47 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1535728547.14.0.56676864532.issue34062@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset aada63b20ec64bbfc4f2fb0718fc563eedbdd36a by Steve Dower (Brendan Gerrity) in branch 'master':
bpo-34062: Add missing launcher argument and make behavior consistent between short and long arguments (GH-8827)
https://github.com/python/cpython/commit/aada63b20ec64bbfc4f2fb0718fc563eedbdd36a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:16:02 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 15:16:02 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1535728562.71.0.56676864532.issue34062@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:17:48 2018
From: report at bugs.python.org (mokhalid)
Date: Fri, 31 Aug 2018 15:17:48 +0000
Subject: [issue34554] Add match built-in function
In-Reply-To: <1535726723.83.0.56676864532.issue34554@psf.upfronthosting.co.za>
Message-ID: <1535728668.37.0.56676864532.issue34554@psf.upfronthosting.co.za>


mokhalid <mohammedkhaildson at gmail.com> added the comment:

Thanks so much, I will do it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34554>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:24:57 2018
From: report at bugs.python.org (Thomas Herzog)
Date: Fri, 31 Aug 2018 15:24:57 +0000
Subject: [issue34555] AF_VSOCK not unset because of wrong nesting
In-Reply-To: <1535728334.14.0.56676864532.issue34555@psf.upfronthosting.co.za>
Message-ID: <1535729097.92.0.56676864532.issue34555@psf.upfronthosting.co.za>


Change by Thomas Herzog <tom at therzog.net>:


----------
keywords: +patch
pull_requests: +8484
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34555>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:25:51 2018
From: report at bugs.python.org (Cooper Lees)
Date: Fri, 31 Aug 2018 15:25:51 +0000
Subject: [issue34556] Add --upgrade to venv module
Message-ID: <1535729151.14.0.56676864532.issue34556@psf.upfronthosting.co.za>


New submission from Cooper Lees <me at cooperlees.com>:

I'd like to propose add a `--upgrade` to venv module to automatically update pip and potentially setuptools if supplied. This will allow ensuring you have the latest and greatest of these core components.

Example Usage:
python3 -m venv --upgrade /tmp/awesome_venv

This will allow me to skip my next command that I usually always do:
/tmp/awesome_venv/bin/pip install --upgrade pip setuptools

Thoughts? If people are happy, I will look at doing the PR. 

I would envision I'll either import (which seems to be a no no from pip maintainers) the upgrade code or just fork pip ...

----------
components: Library (Lib)
messages: 324431
nosy: cooperlees
priority: normal
severity: normal
status: open
title: Add --upgrade to venv module
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34556>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:32:26 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 15:32:26 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1535729546.77.0.56676864532.issue34062@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5df3658f2db1585607d41c25093a2a7d2a4de347 by Miss Islington (bot) in branch '3.7':
bpo-34062: Add missing launcher argument and make behavior consistent between short and long arguments (GH-8827)
https://github.com/python/cpython/commit/5df3658f2db1585607d41c25093a2a7d2a4de347


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:42:45 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 31 Aug 2018 15:42:45 +0000
Subject: [issue34556] Add --upgrade to venv module
In-Reply-To: <1535729151.14.0.56676864532.issue34556@psf.upfronthosting.co.za>
Message-ID: <1535730165.88.0.56676864532.issue34556@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This sounds good to me; my `python -m venv venv` commands are also almost always followed up by `venv/bin/python -m pip install -U pip setuptools wheel`.  I wouldn't get the `wheel` from this, but it's not always necessary anyway.

Rather than importing or forking, I would expect this could just be done by invoking the venv's pip as a subprocess.

Also, it would need to be a different flag than `--upgrade`, which already exists.

----------
nosy: +vinay.sajip, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34556>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:56:39 2018
From: report at bugs.python.org (Steve Dower)
Date: Fri, 31 Aug 2018 15:56:39 +0000
Subject: [issue34062] Python launcher on Windows does not work with --list or
 --list-paths
In-Reply-To: <1530900810.19.0.56676864532.issue34062@psf.upfronthosting.co.za>
Message-ID: <1535730999.89.0.56676864532.issue34062@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Brendan!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34062>
_______________________________________

From report at bugs.python.org  Fri Aug 31 11:59:04 2018
From: report at bugs.python.org (Cooper Lees)
Date: Fri, 31 Aug 2018 15:59:04 +0000
Subject: [issue34556] Add --upgrade to venv module
In-Reply-To: <1535729151.14.0.56676864532.issue34556@psf.upfronthosting.co.za>
Message-ID: <1535731144.63.0.56676864532.issue34556@psf.upfronthosting.co.za>


Cooper Lees <me at cooperlees.com> added the comment:

Thanks for hi-lighting, yes, sorry. I should of been clearer here.

What should we use other than `--upgrade`? I just wanted the topic to be generic:
- `-U`
- `--upgrade-modules`
- `--pip-upgrade`
- `--pull-latest`

In regards to using subprocess, it calls exec or fork to run the child process/command, so that's what I wished to communicate via the term 'fork'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34556>
_______________________________________

From report at bugs.python.org  Fri Aug 31 13:01:00 2018
From: report at bugs.python.org (Christoph Reiter)
Date: Fri, 31 Aug 2018 17:01:00 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1535734860.78.0.56676864532.issue1230540@psf.upfronthosting.co.za>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

To add one more use case for this:

concurrent.futures.Future.add_done_callback() currently ignores exceptions for the callback and just logs them which is easy to miss. I assume because it's not clear when and in which thread it gets called, and there is no "right" way to handle it.

It would be nice if it would call something like sys.excepthook instead.

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1230540>
_______________________________________

From report at bugs.python.org  Fri Aug 31 13:02:16 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Aug 2018 17:02:16 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535734936.58.0.56676864532.issue34551@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Fri Aug 31 13:02:24 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 31 Aug 2018 17:02:24 +0000
Subject: [issue34465] ipaddress should accept bytearray in addition to bytes
In-Reply-To: <1534967280.44.0.56676864532.issue34465@psf.upfronthosting.co.za>
Message-ID: <1535734944.06.0.56676864532.issue34465@psf.upfronthosting.co.za>


Xiang Zhang <angwerzx at 126.com> added the comment:

I'm -1 on this change. I think the workaround is easy and direct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34465>
_______________________________________

From report at bugs.python.org  Fri Aug 31 13:18:27 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 31 Aug 2018 17:18:27 +0000
Subject: [issue34496] Argparse library: parse --set type
In-Reply-To: <1535179890.87.0.56676864532.issue34496@psf.upfronthosting.co.za>
Message-ID: <1535735907.0.0.56676864532.issue34496@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In my experience, a more common way to say ?stop parsing and take the remaining arguments as one value? is using `--`.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34496>
_______________________________________

From report at bugs.python.org  Fri Aug 31 13:21:23 2018
From: report at bugs.python.org (Eric Lippert)
Date: Fri, 31 Aug 2018 17:21:23 +0000
Subject: [issue34551] Redundant store can be removed from
 _PyFunction_FastCallDict
In-Reply-To: <1535650041.35.0.56676864532.issue34551@psf.upfronthosting.co.za>
Message-ID: <1535736083.77.0.56676864532.issue34551@psf.upfronthosting.co.za>


Eric Lippert <ericlippert at gmail.com> added the comment:

If it were possible that the interpreter iterating over a dictionary could cause the dictionary to change size then I suspect that this would be a rich source of bugs to mine. :-) 

It would be great if we could make it a documented, enforced invariant that the interpreter reading a dictionary never produces a side effect visible to the interpreter.

Re: "this specific statement already existed before my work."

Thanks for the historical note; the first thing I thought when I read this line was "that's got to be a copy-paste left over from an earlier version of the algorithm."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34551>
_______________________________________

From report at bugs.python.org  Fri Aug 31 14:00:53 2018
From: report at bugs.python.org (James Campbell)
Date: Fri, 31 Aug 2018 18:00:53 +0000
Subject: [issue34557] When sending binary file to a Microsoft FTP server over
 FTP TLS, the SSL unwind method hangs
Message-ID: <1535738453.08.0.56676864532.issue34557@psf.upfronthosting.co.za>


New submission from James Campbell <james at printtapp.com>:

When using the FTP library to transfer a binary file to a Microsoft FTP server using TLS, then the library will hang when unwinding the connection until it finally times out.

The storbinary method calls conn.unwind which seems to have an issue with SSL connections with a Microsoft server. If we terminate the connection early the file is successfully transferred so it's just the unwind procedure that crashes and hangs our server until it times out.


We are able to work around it by creating our own version of the storbinary method which just closes the connection and doesn't do the unwind step.

It's not clear why the library does this step since we never need to drop down to an unencrypted connection so it should be enough to just close it once done.

You can read more information on this by somebody else with Python 3.2
http://www.sami-lehtinen.net/blog/python-32-ms-ftps-ssl-tls-lockup-fix

----------
components: Library (Lib)
messages: 324440
nosy: James Campbell2
priority: normal
severity: normal
status: open
title: When sending binary file to a Microsoft FTP server over FTP TLS, the SSL unwind method hangs
type: crash
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34557>
_______________________________________

From report at bugs.python.org  Fri Aug 31 15:24:42 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Aug 2018 19:24:42 +0000
Subject: [issue34558] ctypes.find_library processing - missing parenthesis
 prevents subprocess from getting a returncode
Message-ID: <1535743482.34.0.56676864532.issue34558@psf.upfronthosting.co.za>


New submission from Michael Felt <aixtools at felt.demon.nl>:

With AIX I have seen the following messages repeatedly:

root at x066:[/data/prj/python/python3-3.8]./python ../git/*3.8/Lib/ctypes/test/test_loading.py
/data/prj/python/git/python3-3.8/Lib/subprocess.py:852: ResourceWarning: subprocess 11796734 is still running
  ResourceWarning, source=self)
/data/prj/python/git/python3-3.8/Lib/subprocess.py:852: ResourceWarning: subprocess 11796480 is still running
  ResourceWarning, source=self)

There is python2 to python3 missed change typo that is preventing the returncode from ever being determined

diff --git a/Lib/ctypes/_aix.py b/Lib/ctypes/_aix.py
index 463f60a284..190cac6507 100644
--- a/Lib/ctypes/_aix.py
+++ b/Lib/ctypes/_aix.py
@@ -115,7 +115,7 @@ def get_ld_headers(file):
         else:
             break
     p.stdout.close()
-    p.wait
+    p.wait()
     return ldr_headers

 def get_shared(ld_headers):

PR will be posted.

----------
components: Library (Lib), Tests
messages: 324441
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: ctypes.find_library processing - missing parenthesis prevents subprocess from getting a returncode
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34558>
_______________________________________

From report at bugs.python.org  Fri Aug 31 15:30:03 2018
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Aug 2018 19:30:03 +0000
Subject: [issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum
 object is a returned
In-Reply-To: <1535485064.24.0.56676864532.issue34536@psf.upfronthosting.co.za>
Message-ID: <1535743803.3.0.56676864532.issue34536@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34536>
_______________________________________

From report at bugs.python.org  Fri Aug 31 15:34:18 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Aug 2018 19:34:18 +0000
Subject: [issue34558] ctypes.find_library processing - missing parenthesis
 prevents subprocess from getting a returncode
In-Reply-To: <1535743482.34.0.56676864532.issue34558@psf.upfronthosting.co.za>
Message-ID: <1535744058.4.0.56676864532.issue34558@psf.upfronthosting.co.za>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +8485
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34558>
_______________________________________

From report at bugs.python.org  Fri Aug 31 15:54:40 2018
From: report at bugs.python.org (orlnub123)
Date: Fri, 31 Aug 2018 19:54:40 +0000
Subject: [issue34443] enum repr should use __qualname__
In-Reply-To: <1534782868.03.0.56676864532.issue34443@psf.upfronthosting.co.za>
Message-ID: <1535745280.03.0.56676864532.issue34443@psf.upfronthosting.co.za>


orlnub123 <orlnub123 at gmail.com> added the comment:

After some thinking I've come to the conclusion that making the __str__s use the fully qualified name was a bad idea. I've closed my PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34443>
_______________________________________

From report at bugs.python.org  Fri Aug 31 16:34:35 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 31 Aug 2018 20:34:35 +0000
Subject: [issue34499] Extend registering of single-dispatch functions to
 parametrized generic pseudo-types
In-Reply-To: <1535200728.53.0.56676864532.issue34499@psf.upfronthosting.co.za>
Message-ID: <1535747675.43.0.56676864532.issue34499@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34499>
_______________________________________

From report at bugs.python.org  Fri Aug 31 17:16:09 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 31 Aug 2018 21:16:09 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535750169.62.0.56676864532.issue34007@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +8486
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 17:40:37 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 31 Aug 2018 21:40:37 +0000
Subject: [issue34521] test_socket.RecvmsgIntoSCMRightsStreamTest fails on
 AMD64 FreeBSD CURRENT Debug 3.x
In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za>
Message-ID: <1535751637.1.0.56676864532.issue34521@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This error happens a lot in the same buildbot in different tests:

raceback (most recent call last):
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/test/_test_multiprocessing.py", line 3335, in child_access
    w = conn.recv()
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/connection.py", line 251, in recv
    return _ForkingPickler.loads(buf.getbuffer())
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/connection.py", line 960, in rebuild_connection
    fd = df.detach()
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/resource_sharer.py", line 58, in detach
    return reduction.recv_handle(conn)
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/reduction.py", line 185, in recv_handle
    return recvfds(s, 1)[0]
  File "/usr/home/buildbot/python/3.7.koobs-freebsd-current/build/Lib/multiprocessing/reduction.py", line 161, in recvfds
    len(ancdata))
RuntimeError: received 0 items of ancdata

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34521>
_______________________________________

From report at bugs.python.org  Fri Aug 31 17:49:38 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 31 Aug 2018 21:49:38 +0000
Subject: [issue34408] possible null pointer dereference in pystate.c
In-Reply-To: <1534277378.73.0.56676864532.issue34408@psf.upfronthosting.co.za>
Message-ID: <1535752178.67.0.56676864532.issue34408@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 95d630e2213fb0ffc197ec440efa3ae3dbb74f8d by Pablo Galindo in branch 'master':
bpo-34408: Prevent a null pointer dereference and resource leakage in `PyInterpreterState_New()` (GH-8767)
https://github.com/python/cpython/commit/95d630e2213fb0ffc197ec440efa3ae3dbb74f8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34408>
_______________________________________

From report at bugs.python.org  Fri Aug 31 17:56:05 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Aug 2018 21:56:05 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1535752565.47.0.56676864532.issue25711@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think Serhiy's PR is basically done, so now the question is do we want to merge it in and drop the C code? ;)

I obviously say yes because this is I/O-bound code and so the switch shouldn't be enough of a performance hit to warrant blocking the gain in maintainability long-term (especially if we try to clean the module up slowly).

Barry, since I know you work with zip files a lot at work did you want to check to make sure perf won't be an issue for your use-case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Fri Aug 31 17:59:55 2018
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Aug 2018 21:59:55 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1535752795.74.0.56676864532.issue34546@psf.upfronthosting.co.za>


Change by Brett Cannon <brett at python.org>:


----------
title: Zipfile encryption function -> Add encryption support to zipfile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34546>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:04:50 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 31 Aug 2018 22:04:50 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535753090.78.0.56676864532.issue34007@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset f2ef51f8bec525b21e52988880c8a029642795ed by Pablo Galindo in branch 'master':
bpo-34007: Skip traceback tests if the Program Counter is not available. (GH-9018)
https://github.com/python/cpython/commit/f2ef51f8bec525b21e52988880c8a029642795ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:16:52 2018
From: report at bugs.python.org (natedogith1)
Date: Fri, 31 Aug 2018 22:16:52 +0000
Subject: [issue34559] multiprocessing AuthenticationError when nesting with
 non-default authkey
Message-ID: <1535753812.06.0.56676864532.issue34559@psf.upfronthosting.co.za>


New submission from natedogith1 <natedogith1 at gmail.com>:

If you nest shared objects on a manager that doesn't use the default authkey, you get an AuthenticationError.

import multiprocessing.managers
a = multiprocessing.managers.SyncManager(authkey=b'')
a.start()
b = a.list()
b.append(a.list())
_ = b[0]

----------
components: Library (Lib)
messages: 324447
nosy: natedogith1
priority: normal
severity: normal
status: open
title: multiprocessing AuthenticationError when nesting with non-default authkey
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34559>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:21:38 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 22:21:38 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535754098.23.0.56676864532.issue34007@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8487

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:21:44 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 22:21:44 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535754104.65.0.56676864532.issue34007@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:21:50 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 22:21:50 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535754110.73.0.56676864532.issue34007@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8489

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:23:30 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 31 Aug 2018 22:23:30 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535754210.44.0.56676864532.issue34007@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:32:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 31 Aug 2018 22:32:40 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1535754760.38.0.56676864532.issue18307@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The patch for the Python implementation of zipimport (see issue25711) is much simpler (see the attached sample patch). But it requires adding a way of modifying co_filename. Currently code objects are immutable.

This issue looks as a part of the larger problem. Zipimport is not the only source of precompiled bytecode which needs updating co_filename. For example the tree of py and pyc files can be moved to other place. Also, since co_filename contains system depended path, it doesn't make sense when load pyc files on other system (for example if they were created on Linux and ran on Windows). On other side, the import machinery tries to load pyc and py files, therefore it should know the path of corresponding py file when load a pyc file. Maybe it be better to not save co_filename in a pyc file (note that all code object in a file have the same co_filename, but it is saved for every code object), but set co_filename after unmarshalling the module bytecode by the import machinery in all loaders.

----------
Added file: https://bugs.python.org/file47775/pyzipimport-code-filename.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:33:42 2018
From: report at bugs.python.org (Riccardo Mottola)
Date: Fri, 31 Aug 2018 22:33:42 +0000
Subject: [issue34560] Backport of uuid1() failure fix
Message-ID: <1535754822.12.0.56676864532.issue34560@psf.upfronthosting.co.za>


New submission from Riccardo Mottola <multix at gmail.com>:

Backport proposal of fix for closed issue 32502 

The patch was directly adapted from
https://github.com/python/cpython/commit/d69794f4df81de731cc66dc82136e28bee691e1e


applied to 2.7 and tested working for me.

Discussion ongoing MacPorts requested to share said patch upstream

https://github.com/macports/macports-ports/pull/2456

----------
components: Library (Lib)
files: uuid-64bit.patch
keywords: patch
messages: 324449
nosy: Riccardo Mottola
priority: normal
severity: normal
status: open
title: Backport of uuid1() failure fix
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47776/uuid-64bit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34560>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:43:30 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 22:43:30 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535755410.66.0.56676864532.issue34007@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5d594f3106aff6cea00234c88051427ae511cdd8 by Miss Islington (bot) in branch '2.7':
bpo-34007: Skip traceback tests if the Program Counter is not available. (GH-9018)
https://github.com/python/cpython/commit/5d594f3106aff6cea00234c88051427ae511cdd8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:47:24 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Aug 2018 22:47:24 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535755644.66.0.56676864532.issue34007@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4da71814b327cb2ad47a01710360cd21ba636352 by Miss Islington (bot) in branch '3.7':
bpo-34007: Skip traceback tests if the Program Counter is not available. (GH-9018)
https://github.com/python/cpython/commit/4da71814b327cb2ad47a01710360cd21ba636352


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:53:50 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 31 Aug 2018 22:53:50 +0000
Subject: [issue34007] test_gdb fails in s390x SLES buildbots
In-Reply-To: <1530318299.83.0.56676864532.issue34007@psf.upfronthosting.co.za>
Message-ID: <1535756030.7.0.56676864532.issue34007@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +8490

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34007>
_______________________________________

From report at bugs.python.org  Fri Aug 31 18:54:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 31 Aug 2018 22:54:38 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1535756078.78.0.56676864532.issue34546@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

>From the official ZIP files specification:

    This form of encryption is considered weak by today's standards
    and its use is recommended only for situations with
    low security needs or for compatibility with older .ZIP
    applications.

I think that the support of encrypting ZIP files using the traditional PKWARE encryption was intentionally omitted in the zipfile module, because we don't want to encourage using such weak encryption method. If you need to add encrypted data in the ZIP file, use third-party tools for encrypting it before adding to the ZIP file or encrypting the whole ZIP file after creating.

I'm -1 for adding support of weak encrypting.

Of course, adding support for the strong (AES) encryption in ZIP files would be nice. But this task is much more difficult.

----------
nosy: +alanmcintyre, serhiy.storchaka, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34546>
_______________________________________

From report at bugs.python.org  Fri Aug 31 20:08:03 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 01 Sep 2018 00:08:03 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1535760483.1.0.56676864532.issue25711@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Not sure if I'll have time before the core sprints to check the implementation with shiv, but I can give it a try then.  Do you mind waiting until then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Fri Aug 31 20:33:49 2018
From: report at bugs.python.org (=?utf-8?b?5aSn6YeO6ZqG5byY?=)
Date: Sat, 01 Sep 2018 00:33:49 +0000
Subject: [issue34546] Add encryption support to zipfile
In-Reply-To: <1535618425.84.0.56676864532.issue34546@psf.upfronthosting.co.za>
Message-ID: <1535762029.23.0.56676864532.issue34546@psf.upfronthosting.co.za>


???? <oono0114 at gmail.com> added the comment:

Agree, we should not enhance weak encryption to the world.
But unfortunately, MS Windows supports only this type of encryption as far as I researched.
https://blogs.msdn.microsoft.com/oldnewthing/20180515-00/?p=98755

That is the my first motivation of Traditional PKWARE encryption(a.k.a  ZipCrypto/Standard Zip 2.0 encryption) support.
If this big platform supports AES, we don't have any reason to support. But unfortunately not.


On the other hand, encryption algorithm compromising happens forever.
I believe python developers must have ability to make decision of suitable algorithm because "We are all (consenting) adults here".(I love this phrase)

Also implementing other algo (including AES) support must affect to decryption of zipfile module. 
As we can imagine it should be big task and should be divided.

These are the background of my suggestion.

In summary, 
 1. We don't have to support "weak" encryption like DES/RC2 although they are on the document.
 2. But Traditional PKWare Encryption is special enough to support because of the circumstances.
 3. Other algo support in both decrypt/encrypt should be implemented sooner or later.

Any feedback is welcome.


FYI  : All candidate of Zip encryption
---------
(Traditional PKWARE encryption)
+
0x6601 - DES
0x6602 - RC2 (version needed to extract < 5.2)
0x6603 - 3DES 168
0x6609 - 3DES 112
0x660E - AES 128 
0x660F - AES 192 
0x6610 - AES 256 
0x6702 - RC2 (version needed to extract >= 5.2)
0x6720 - Blowfish
0x6721 - Twofish
0x6801 - RC4

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
7.2.3.2 AlgId

---------

FYI 2. Other languages/tools support

Perl : "Support Encryption" is in TODO 
https://metacpan.org/pod/Archive::Zip

Go : Both (AES/Traditional) encryption is going to be integrated( discussion was suspended?)
https://github.com/golang/go/issues/12081

Ruby : Supports as experimental
https://github.com/rubyzip/rubyzip/blob/master/README.md


WinZip : Supports but not recommended.
http://kb.winzip.com/help/help_encryption.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34546>
_______________________________________

From report at bugs.python.org  Fri Aug 31 21:22:04 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 01 Sep 2018 01:22:04 +0000
Subject: [issue34561] Replace list sorting merge_collapse()?
Message-ID: <1535764924.6.0.56676864532.issue34561@psf.upfronthosting.co.za>


New submission from Tim Peters <tim at python.org>:

The invariants on the run-length stack are uncomfortably subtle.  There was a flap a while back when an attempt at a formal correctness proof uncovered that the _intended_ invariants weren't always maintained.  That was easily repaired (as the researchers suggested), but it remains hard to grasp why it's always correct now.  The Java variant didn't take the suggested fix, instead boosting its stack size.  But it turns out that's still not enough, because the original researchers made a different mistake in their own paper ;-)

http://drops.dagstuhl.de/opus/volltexte/2018/9467/

Buss & Knop recently published results on different ways of managing the stack, and I think they're worth investigating for "real life" use:

https://arxiv.org/abs/1801.04641

Offhand, their "2-merge" looks quite appealing to me.  The only invariant it maintains is that each run on the stack is at least twice the length of the run one above it on the stack, which can be maintained just by checking the topmost two stack entries in the loop.  So, e.g., where merge_collapse() is currently happy with runs of lengths 150 and 100 ending the stack, 2-merge would force a merge (it's not the case that 150 >= 2*100).  Both are happy if the stack ends with runs of lengths 200 and 100.

This is much easier to reason about, simpler to code, and would allow reducing the size of the stack (worst-case size is proportional to the log (of the largest possible array) to the base 2 instead of to the current base phi (~1.62)).  They developed some formal measures showing that its "merge cost" (an overall measure abstracting some from real-life behavior) is significantly better than timsort's current strategy.  And a little thought convinced me it preserves that, for random data, it would continue to strongly tend towared triggering perfectly balanced merges (merging runs of the same size).

When I was developing this code, virtually all the time was spent making merging itself as fast as possible; the stack-management code was just the first thing I tried that "worked well".  But turns out that's the only part researchers care about ;-) I'd be pleased if it could be replaced with something both better and simpler, or even just simpler but no worse.  But the devil's in the details ...

----------
messages: 324455
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: Replace list sorting merge_collapse()?
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34561>
_______________________________________

From report at bugs.python.org  Fri Aug 31 22:18:36 2018
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 01 Sep 2018 02:18:36 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1535768316.62.0.56676864532.issue25711@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm personally in no rush and I assume Serhiy isn't either with 3.8 cut-off quite a ways out, so I see no rush.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Fri Aug 31 22:31:11 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 01 Sep 2018 02:31:11 +0000
Subject: [issue34558] ctypes.find_library processing - missing parenthesis
 prevents subprocess from getting a returncode
In-Reply-To: <1535743482.34.0.56676864532.issue34558@psf.upfronthosting.co.za>
Message-ID: <1535769071.4.0.56676864532.issue34558@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 172a71f19bb5e9624651850b315f403c460b9699 by Mariatta (Michael Felt) in branch 'master':
bpo-34558: Add missing parentheses in _aix.py (GH-9017)
https://github.com/python/cpython/commit/172a71f19bb5e9624651850b315f403c460b9699


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34558>
_______________________________________

From report at bugs.python.org  Fri Aug 31 22:31:40 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 01 Sep 2018 02:31:40 +0000
Subject: [issue34558] ctypes.find_library processing - missing parenthesis
 prevents subprocess from getting a returncode
In-Reply-To: <1535743482.34.0.56676864532.issue34558@psf.upfronthosting.co.za>
Message-ID: <1535769100.46.0.56676864532.issue34558@psf.upfronthosting.co.za>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +8491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34558>
_______________________________________

From report at bugs.python.org  Fri Aug 31 22:36:46 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 01 Sep 2018 02:36:46 +0000
Subject: [issue34558] ctypes.find_library processing - missing parenthesis
 prevents subprocess from getting a returncode
In-Reply-To: <1535743482.34.0.56676864532.issue34558@psf.upfronthosting.co.za>
Message-ID: <1535769406.18.0.56676864532.issue34558@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34558>
_______________________________________

From report at bugs.python.org  Fri Aug 31 22:46:37 2018
From: report at bugs.python.org (miss-islington)
Date: Sat, 01 Sep 2018 02:46:37 +0000
Subject: [issue34558] ctypes.find_library processing - missing parenthesis
 prevents subprocess from getting a returncode
In-Reply-To: <1535743482.34.0.56676864532.issue34558@psf.upfronthosting.co.za>
Message-ID: <1535769997.0.0.56676864532.issue34558@psf.upfronthosting.co.za>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 89c9043ee09d89c99f70e61d8fc0ba45e255b055 by Miss Islington (bot) in branch '3.7':
bpo-34558: Add missing parentheses in _aix.py (GH-9017)
https://github.com/python/cpython/commit/89c9043ee09d89c99f70e61d8fc0ba45e255b055


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34558>
_______________________________________