[issue30917] IDLE: Add idlelib.config.IdleConf unittest

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:


New changeset 65c24c846797b93d7adb72fc400f95a570f43fa9 by terryjreedy in branch 
'3.6':
[3.6] bpo-30917: IDLE: Add config.IdleConf unittests (GH-2691) (#2753)
https://github.com/python/cpython/commit/65c24c846797b93d7adb72fc400f95a570f43fa9


--

___
Python tracker 

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



[issue30917] IDLE: Add idlelib.config.IdleConf unittest

2017-07-19 Thread Terry J. Reedy

Changes by Terry J. Reedy :


--
pull_requests: +2828

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:

Fix worked: test_idle passed in build 897.
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/897/steps/test/logs/stdio
I also included the fix of PR2769 in PR2753 (3.6 backport).

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

___
Python tracker 

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



[issue30973] Regular expression "hangs" interpreter

2017-07-19 Thread T Trindad

New submission from T Trindad:

The following code "hangs" the interpreter:

import re
re.search(r"/\*\*((?:[^*]+|\*[^/])*)\*/", """   /** Copy Constructor **/
private EvaluationContext (EvaluationContext base) {""")



Changing the regex to r"/\*\*((?:[^*]|\*[^/])*)\*/" makes it work normally.

--
components: Regular Expressions
messages: 298705
nosy: T Trindad, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regular expression "hangs" interpreter
type: crash
versions: Python 2.7

___
Python tracker 

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



[issue30940] Documentation for round() is incorrect.

2017-07-19 Thread Serhiy Storchaka

Serhiy Storchaka added the comment:

The documentation should be updated before converting round() to Argument 
Clinic, because this update should be backported to 3.6 and 3.5, while the 
conversion can be made only in 3.7.

--
keywords: +easy
stage:  -> needs patch

___
Python tracker 

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



[issue29144] Implicit namespace packages in Python 3.6

2017-07-19 Thread Nick Coghlan

Nick Coghlan added the comment:

At the Python level, the rules are simple: the first directory on sys.path that 
contains an __init__.py file is identified as a self-contained package. It is 
then up to that __init__.py file to emulate namespace package behaviour (by 
extending __path__) if that's what the author intended.

Nothing changed in Python 3.6 in terms of that, and it's been that way ever 
since native namespace packages were introduced.

So if there's a behavioural change in the pkg_resources namespace emulation in 
going from Python 3.5 to 3.6 that occurs with both old & new versions of 
setuptools, then I see two main possible candidates for that:

1. Something changed in one of the APIs that setuptools uses to recalculate 
__path__

2. Something changed in importlib where we're not respecting runtime changes to 
__path__ properly, and are instead relying on either 
__spec__.submodule_search_locations or a stale cached version of __path__

Neither of those is something we *intended* to change in 3.6, so I think it's 
reasonable to categorise this as 3.6 regression at the standard library level 
(even though setuptools will likely need to work around it anyway, given the 
earliest we'll be able to fix it is in 3.6.3)

--
keywords: +3.6regression
stage:  -> needs patch

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Louie Lu

Louie Lu added the comment:

Yes, Terry's patch fixed this.

--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:


New changeset 9f9192afbb4e45d09f0d3d717b457d157dc46398 by terryjreedy in branch 
'master':
bpo-30968: Fix test_get_font in IDLE's test_config.  (#2769)
https://github.com/python/cpython/commit/9f9192afbb4e45d09f0d3d717b457d157dc46398


--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Terry J. Reedy

Changes by Terry J. Reedy :


--
pull_requests: +2827

___
Python tracker 

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



[issue29403] mock's autospec's behavior on method-bound builtin functions is broken

2017-07-19 Thread Berker Peksag

Changes by Berker Peksag :


--
stage: patch review -> backport needed

___
Python tracker 

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



[issue30883] test_urllib2net failed on s390x Debian 3.6: ftp.debian.org error, too many connections from your internet address

2017-07-19 Thread Berker Peksag

Berker Peksag added the comment:

Thanks, Ammar!

--
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

___
Python tracker 

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



[issue30883] test_urllib2net failed on s390x Debian 3.6: ftp.debian.org error, too many connections from your internet address

2017-07-19 Thread Berker Peksag

Berker Peksag added the comment:


New changeset ae4dca7701ca77a37aa8c956450ff8e21fe6883e by Berker Peksag (Ammar 
Askar) in branch '3.6':
[3.6] bpo-30883: Use pythontest.net instead of debian.org in test_urllib2net 
(GH-2755)
https://github.com/python/cpython/commit/ae4dca7701ca77a37aa8c956450ff8e21fe6883e


--

___
Python tracker 

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



[issue30883] test_urllib2net failed on s390x Debian 3.6: ftp.debian.org error, too many connections from your internet address

2017-07-19 Thread Berker Peksag

Berker Peksag added the comment:


New changeset aca493b7a337338fa20395fbc2d1895cb8093826 by Berker Peksag (Ammar 
Askar) in branch '3.5':
[3.5] bpo-30883: Use pythontest.net instead of debian.org in test_urllib2net 
(GH-2755)
https://github.com/python/cpython/commit/aca493b7a337338fa20395fbc2d1895cb8093826


--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:

Louie, I am fixing this (I believe).

--

___
Python tracker 

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



[issue30333] test_multiprocessing_forkserver: poll() failed on AMD64 FreeBSD CURRENT Non-Debug 3.5

2017-07-19 Thread Kubilay Kocak

Changes by Kubilay Kocak :


--
nosy: +koobs

___
Python tracker 

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



[issue29403] mock's autospec's behavior on method-bound builtin functions is broken

2017-07-19 Thread Berker Peksag

Berker Peksag added the comment:


New changeset 856cbcc12f2e4cca93af5dc7ed6bcea4dd942f10 by Berker Peksag (Aaron 
Gallagher) in branch 'master':
bpo-29403: Fix mock's broken autospec behavior on method-bound builtin 
functions (GH-3)
https://github.com/python/cpython/commit/856cbcc12f2e4cca93af5dc7ed6bcea4dd942f10


--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:

I merged pr2754 in pr2753, the 3.6 backport of pr2691.  To avoid breaking 3.6 
buildbots more than one test, I will hold off merging pr2753 until a fix is 
available.

--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Terry J. Reedy

Changes by Terry J. Reedy :


--
pull_requests: +2826

___
Python tracker 

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



[issue30917] IDLE: Add idlelib.config.IdleConf unittest

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:


New changeset ed014f7e135fe021837208960237d6c37afde5be by terryjreedy (Louie 
Lu) in branch 'master':
bpo-30917: IDLE: Fix mock_config deepcopy to read_string (#2754)
https://github.com/python/cpython/commit/ed014f7e135fe021837208960237d6c37afde5be


--

___
Python tracker 

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



[issue30972] Event loop incorrectly inherited in child processes.

2017-07-19 Thread Elvis Pranskevichus

New submission from Elvis Pranskevichus:

The attached example shows that `asyncio.get_event_loop` still returns parent 
process' event loop in some cases.  It appears that the fix in issue #29703 was 
incomplete:

PARENT PID: 21947, LOOP: <_UnixSelectorEventLoop running=True closed=False 
debug=False> at 0x7f0fbe7cfd68
WORKER PID: 21948, LOOP: <_UnixSelectorEventLoop running=True closed=False 
debug=False> at 0x7f0fbe7cfd68
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/lib64/python3.6/concurrent/futures/process.py", line 175, in 
_process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
  File "test.py", line 13, in worker
return loop.run_until_complete(worker_coro())
  File "/usr/lib64/python3.6/asyncio/base_events.py", line 454, in 
run_until_complete
self.run_forever()
  File "/usr/lib64/python3.6/asyncio/base_events.py", line 408, in run_forever
raise RuntimeError('This event loop is already running')
RuntimeError: This event loop is already running
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "test.py", line 25, in 
loop.run_until_complete(main())
  File "/usr/lib64/python3.6/asyncio/base_events.py", line 466, in 
run_until_complete
return future.result()
  File "test.py", line 21, in main
return await loop.run_in_executor(executor, worker)
RuntimeError: This event loop is already running

--
components: asyncio
files: test.py
messages: 298693
nosy: Elvis.Pranskevichus, yselivanov
priority: normal
severity: normal
status: open
title: Event loop incorrectly inherited in child processes.
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file47024/test.py

___
Python tracker 

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



[issue30971] Improve code readability of json.tool

2017-07-19 Thread Berker Peksag

Berker Peksag added the comment:

I don't think most of the changes improve readability of json.tool. Everyone 
has their own preferences and it's usually not enough to justify code churn.

Also, we don't need to add comments when the code itself is pretty descriptive:

# Output JSON
with options.outfile as outfile:
json.dump(obj, outfile, sort_keys=options.sort_keys, indent=4)
outfile.write('\n')

IMO, the only acceptable change is the correct use of 'default' parameter for 
'infile' and 'outfile'.

--
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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



[issue30971] Improve code readability of json.tool

2017-07-19 Thread R. David Murray

R. David Murray added the comment:

However, our general policy is that we don't make such changes unless we are 
also touching the code for other reasons.  So I think using this PR as a base 
for your feature PRs, and then committing everything together if they are 
accepted, would be the way to go.  I don't know if it would work to actually 
use it as a base for the other PRs in github, or if it would work better to 
just make it the initial commit in a commit series.  The github workflow is too 
new for us to have definite answers to such questions :)

--
nosy: +r.david.murray

___
Python tracker 

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



[issue27099] IDLE: turn builting extensions into regular modules

2017-07-19 Thread Terry J. Reedy

Terry J. Reedy added the comment:

Either the hard-coding in the config test will have to be changed or it will 
have to be replaced by something adaptive.  I have not quite decided yet.  Once 
the new tests are merged, I expect to do some followup improvements.

Equal important for this issue is minimal testing of each extension converted.  
They do not have to be complete, but should demonstrate that the extension is 
present in the menu and basically runs.  Testing for presence in the menu has 
to be worked out.  There should be one or more separate issues that will be 
dependencies of this.  Does your patch put menu entries in the same place?  I 
will want to move some, but that can be a followup issue, which will require 
change in the test.  Ditto for combining some of the small files into fewer 
files.

--

___
Python tracker 

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



[issue29144] Implicit namespace packages in Python 3.6

2017-07-19 Thread Brett Cannon

Brett Cannon added the comment:

Without looking into what changed, I say Python 3.6 being more strict in what 
is a namespace package is reasonable and setuptools needs to be better about 
installing pkg_resources-using __init__.py files.

--

___
Python tracker 

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



[issue30490] Allow pass an exception to the Event.set method

2017-07-19 Thread pfreixes

pfreixes added the comment:

More info about why here 
https://github.com/python/cpython/pull/1824#issuecomment-315903808

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

___
Python tracker 

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



[issue27099] IDLE: turn builting extensions into regular modules

2017-07-19 Thread Charles Wohlganger

Charles Wohlganger added the comment:

Changes to master have introduced tests with hardcoded values for what 
extensions are expected to be loaded by IDLE. Given that this patch turn all 
current extensions into mainlined modules, none of them are loaded as 
extensions and all of the related tests fail. What should I do about this?

--

___
Python tracker 

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



[issue30971] Improve code readability of json.tool

2017-07-19 Thread Daniel Himmelstein

New submission from Daniel Himmelstein:

In https://github.com/python/cpython/pull/2720, I propose code changes to the 
json.tool command line utility. These changes are entirely non-functional and 
instead focus on improving code readability, style, brevity, extensibility, and 
maintainability.

These changes mainly came up during the implementation of two enhancements of 
json.tool:

+ https://github.com/python/cpython/pull/345 to add indentation / whitespace 
options (bpo-29636).

+ https://github.com/python/cpython/pull/201 to display non-ascii characters 
(bpo-27413).

These issues and pull requests are currently awaiting further consensus around 
their design and desirability. Therefore, I wanted to separate the 
non-functional code improvements from these PRs into a distinct PR.

This has the benefit of allowing the future enhancement PRs to focus solely on 
adding features rather than the readability changes.

--
components: Library (Lib)
messages: 298686
nosy: dhimmel
priority: normal
pull_requests: 2824
severity: normal
status: open
title: Improve code readability of json.tool
versions: Python 3.7

___
Python tracker 

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



[issue24459] Mention PYTHONFAULTHANDLER in the man page

2017-07-19 Thread Joshua Jay Herman

Joshua Jay Herman added the comment:

Was this ever merged? I'm not sure whats happening.

--

___
Python tracker 

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



[issue30945] loop.create_server does not detect if the interface is IPv6 enabled

2017-07-19 Thread Yury Selivanov

Yury Selivanov added the comment:

> Better than trying to detect IPv6 compatibility beforehand would probably to 
> recognize the error and simply ignore it.


+1

--

___
Python tracker 

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



[issue30945] loop.create_server does not detect if the interface is IPv6 enabled

2017-07-19 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Better than trying to detect IPv6 compatibility beforehand would probably to 
recognize the error and simply ignore it.

Note: errno 99 is EADDRNOTAVAIL.

Something like this could work (untested):

diff --git a/Lib/asyncio/base_events.py b/Lib/asyncio/base_events.py
index 33b8f48..413161a 100644
--- a/Lib/asyncio/base_events.py
+++ b/Lib/asyncio/base_events.py
@@ -1038,6 +1038,11 @@ class BaseEventLoop(events.AbstractEventLoop):
 try:
 sock.bind(sa)
 except OSError as err:
+if err.errno == errno.EADDRNOTAVAIL:
+# See bpo-30945
+sockets.pop()
+sock.close()
+continue
 raise OSError(err.errno, 'error while attempting '
   'to bind on address %r: %s'
   % (sa, err.strerror.lower())) from None

--
nosy: +pitrou
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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



[issue30931] Race condition in asyncore may access the wrong dispatcher

2017-07-19 Thread Nir Soffer

Nir Soffer added the comment:

Adding more info after discussion in github.

After polling readable/writeable dispatchers, asyncore.poll(2) receive a list 
of ready file descriptors, and invoke callbacks on the dispatcher objects.

If a dispatchers is closed and and a new dispatcher is created, the new 
dispatcher may get the same file descriptor. If the file descriptor was in the 
ready list returned from poll()/select(), asyncore may try to invoke one of the 
callbacks (e.g. handle_write) on the new dispatcher.

Here is an example in asycore.poll()

r, w, e = select.select(r, w, e, timeout)

for fd in r:
obj = map.get(fd)
if obj is None:
continue
read(obj)

read close obj, removing fd from map, then creates a new one
getting the same fd...

for fd in w:
obj = map.get(fd)

this get the new object from the map, instead of the closed one.

if obj is None:
continue
write(obj)

invoke write on the wrong socket, which is not writable

for fd in e:
obj = map.get(fd)

same issue here

if obj is None:
continue
_exception(obj)


asyncore.poll2() has same issue:

r = pollster.poll(timeout)
for fd, flags in r:
obj = map.get(fd)
if obj is None:
continue
readwrite(obj, flags)

fd may have been closed and recreated by in a previous iteration of the loop.

This issue is demonstrated in the failing test:
https://github.com/python/cpython/pull/2707/commits/5aeb0098d2347984f3a89cf036c305edd2b8382b

--
title: Race condition in asyncore wrongly closes channel -> Race condition in 
asyncore may access the wrong dispatcher

___
Python tracker 

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



[issue30931] Race condition in asyncore wrongly closes channel

2017-07-19 Thread Jaume

Changes by Jaume :


--
pull_requests: +2823

___
Python tracker 

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



[issue28638] Optimize namedtuple creation

2017-07-19 Thread Guido van Rossum

Guido van Rossum added the comment:

Yeah, it looks like the standard `_pickle` and `pickle` solution would work
here.

--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread Louie Lu

Louie Lu added the comment:

After checking source code, I found that is my fault on the test code. After 
the blocker PR 2754 been merged, I'll fix this issue.

--

___
Python tracker 

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



[issue30965] Unexpected behavior of operator "in"

2017-07-19 Thread Mihai Cara

Mihai Cara added the comment:

I am sure that some time ago I read that `in` is a comparison operator but I 
forgot it and I was thinking that (x in y) would be equivalent to (replaced 
with) the return value of y.__contains__(x).

--

___
Python tracker 

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



[issue30965] Unexpected behavior of operator "in"

2017-07-19 Thread Mihai Cara

Mihai Cara added the comment:

Thank you! It was my fault: I was not expecting `in` to be a comparison 
operator.

--

___
Python tracker 

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



[issue30970] return-value of filecmp.dircmp.report_*

2017-07-19 Thread R. David Murray

R. David Murray added the comment:

Thanks for wanting to improve Python.  However, the purpose of those function 
is to *print* the result.  They intentionally do not have return values.

All of the values that you would have these functions return are accessible via 
attributes already.

--
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

2017-07-19 Thread Masayuki Yamamoto

Masayuki Yamamoto added the comment:

oh, I found a mistake.
- replace Py_LIMITED_API with Py_BUILD_CORE on Include/pythread.h Py_tss_t 
definition

--

___
Python tracker 

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



[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`

2017-07-19 Thread R. David Murray

R. David Murray added the comment:

I think you change is appropriate given that the "equivalent to" for the built 
in iterators contains the 'is' expression.

However, I also think we should drop that second whole paragraph, and in the 
previous paragraph say "...but are :term:`iterable`...".  Because conceptually 
what we do is iterate whatever we're given if iter doesn't return a TypeError, 
and it is iter that handles the fallback to the older __getitem__ protocol.  I 
don't see why we should re-explain the iteration protocol in the docs for 'in'. 
 (I haven't looked at how this is actually implemented, but the implementation 
ought to be equivalent to that or we will eventually run into bugs.)  I don't 
think this would result in any loss of precision or understandability, and in 
fact I think it would make it easier to understand.

See also issue 27605, which also wants to edit this section slightly.

--
nosy: +r.david.murray, rhettinger

___
Python tracker 

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



[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX

2017-07-19 Thread Masayuki Yamamoto

Masayuki Yamamoto added the comment:

Nick and Erik, thank you for the comments! I merged proposal into the PR.

Well, I'm interested in the hide implementation detail for TSS API (lately, 
I've read the python-ideas thread "PEP: Hide implementation details in the C 
API" which Victor opened [1]).

Present, the draft of new API has given two methods for thread key 
initialization for the non-limited API (i.e. Py_tss_NEEDS_INIT for statically, 
PyThread_tss_alloc for dynamic). The static initialization needs implementation 
detail for thread key, but Py_tss_t is designed as an opaque data type based on 
the stable ABI and we don't feel like to open the implementation detail to the 
API client. On the other hand, we'd provide newly thread key (de-)allocation 
functions for the limited API, the API client is able to get an initialized 
value without knowing thread key detail. And also the functions can be used on 
the non-limited API.

Therefore, I think it makes more sense that all API clients use 
PyThread_tss_(alloc|free) regardless of the limited API. The reason is which 
are (1) Py_tss_t behaves as an opaque data type as expected for any API client 
(cannot read and write directly the fields in any case), (2) the API gets more 
consistency (just one method for key initialization on the API client).

TL;DR: I'd suggest to make key type strict, what do you think about below 
changes?

- replace Py_LIMITED_API with Py_BUILD_CORE on Python/pythread.h Py_tss_t 
definition
- use PyThread_tss_(alloc|free) in Modules/_tracemalloc.c
- also use in Modules/_testcapimodule.c

[1] https://mail.python.org/pipermail/python-ideas/2017-July/046399.html

--

___
Python tracker 

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



[issue30970] return-value of filecmp.dircmp.report_*

2017-07-19 Thread Mihály Mirk

New submission from Mihály Mirk:

The functions: 
filecmp.dircmp.report()
filecmp.dircmp.report_partial_closure()
filecmp.dircmp.report_full_closure()

do not have return values

--
messages: 298673
nosy: Mihály Mirk
priority: normal
pull_requests: 2822
severity: normal
status: open
title: return-value of filecmp.dircmp.report_*
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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



[issue30576] http.server should support HTTP compression (gzip)

2017-07-19 Thread R. David Murray

R. David Murray added the comment:

Getting input from python ideas is a great idea :)

--

___
Python tracker 

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



[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`

2017-07-19 Thread Antti Haapala

Changes by Antti Haapala :


--
pull_requests: +2820

___
Python tracker 

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



[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`

2017-07-19 Thread Antti Haapala

New submission from Antti Haapala:

The doc reference/expressions.srt says that

> For user-defined classes which do not define __contains__() but do 
> define __iter__(), x in y is True if some value z with x == z is 
> produced while iterating over y. If an exception is raised during the 
> iteration, it is as if in raised that exception.

and

> Lastly, the old-style iteration protocol is tried: if a class defines 
> __getitem__(), x in y is True if and only if there is a non-negative 
> integer index i such that x == y[i], and all lower integer indices do 
> not raise IndexError exception. (If any other exception is raised, it 
> is as if in raised that exception).

The documentation doesn't match the implementation, which clearly does `x is y 
or x == y` to check if `x` is the element `y` from a container. Both the 
`__iter__` and the index-iteration method test the elements using `is` first. 
While the document says that `x is x` means that `x == x` should be true, it is 
not true for example in the case of `nan`:

--
assignee: docs@python
components: Documentation
messages: 298671
nosy: docs@python, ztane
priority: normal
severity: normal
status: open
title: Docs should say that `x is z or x == z` is used for `x in y` in 
containers that do not implement `__contains__`
type: enhancement

___
Python tracker 

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



[issue28638] Optimize namedtuple creation

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

General note about this issue: while the issie title is "Optimize namedtuple 
creation", it would be *nice* to not only optimization the creation but also 
attribute access by name:
http://bugs.python.org/issue28638#msg298499

Maybe we can have a very fast C implementation using structseq, and a fast 
Python implementation (faster than the current Python implementation) fallback 
for non-CPython.

--

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
assignee:  -> terry.reedy
components: +IDLE
nosy: +louielu, terry.reedy

___
Python tracker 

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



[issue30917] IDLE: Add idlelib.config.IdleConf unittest

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

Please see bpo-30968: "test_get_font 
(idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x".

--
nosy: +haypo

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
components: +Tests, Windows
keywords: +buildbot
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.7

___
Python tracker 

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



[issue30968] test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on x86 Windows7 3.x

2017-07-19 Thread STINNER Victor

New submission from STINNER Victor:

The build only contains one change:

commit f776eb0f0e046f2fa3a96540bb42d8cf970f6c55

bpo-30917: IDLE: Add config.IdleConf unittests (#2691) Patch by Louie Lu.

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/893/steps/test/logs/stdio

==
FAIL: test_get_font (idlelib.idle_test.test_config.IdleConfTest)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\idlelib\idle_test\test_config.py",
 line 605, in test_get_font
(f['family'], 10 if f['size'] < 10 else f['size'], f['weight']))
AssertionError: Tuples differ: ('Courier New', 9, 'normal') != ('Courier New', 
10, 'normal')

First differing element 1:
9
10

- ('Courier New', 9, 'normal')
? ^

+ ('Courier New', 10, 'normal')
? ^^

--
messages: 298668
nosy: haypo
priority: normal
severity: normal
status: open
title: test_get_font (idlelib.idle_test.test_config.IdleConfTest) failure on 
x86 Windows7 3.x

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

> Anyone who thinks those objects stay alive too long can submit a PR for 
> SimpleQueue and Pool to close them eagerly.

I started with SimpleQueue for the master branch:
https://github.com/python/cpython/pull/2760

--

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
pull_requests: +2819

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread Elvis Stansvik

Elvis Stansvik added the comment:

So feel free to close this issue. The use case was quite marginal anyway, and 
we can always instruct developers to run `build_ext --inplace` when they intend 
to use the distribution out of the source directory (and not have inplace=1 in 
setup.cfg, to allow for installation as well).

If anyone should want to try to remove the limitation wrt installation with 
inplace extensions, I think they're in for quite a bit of work.

--

___
Python tracker 

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



[issue30967] Crash in PyThread_ReInitTLS() in the child process after os.fork() on CentOS 6.5 (Python 2.7.13)

2017-07-19 Thread Thomas Mortensson

Thomas Mortensson added the comment:

Indeed, #29640 seems remarkably similar. Will attempt to run attached POC code. 
Thank you very much for your help.

--

___
Python tracker 

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



[issue30822] Python implementation of datetime module is not being tested correctly.

2017-07-19 Thread Utkarsh Upadhyay

Utkarsh Upadhyay added the comment:

So it seems that running the experiments without `-utzdata` would be an 
acceptable fix (assuming that there are no other interesting time-zones worthy 
of explicit testing)?

Can I help in the resolution of this issue, since resolution of 
http://bugs.python.org/issue30302 is tangentially conditioned on it. (-:

--

___
Python tracker 

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



[issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination

2017-07-19 Thread Antoine Pitrou

Antoine Pitrou added the comment:

I think this issue is mistaken.  The reader and writer objects are closed 
automatically when they are destroyed (see Connection.__del__).  The only thing 
that may lack is a way to close them more eagerly.

In any case, I'm closing as a duplicate of issue 30966.

--
dependencies:  -multiprocessing.queues.SimpleQueue leaks 2 fds
nosy: +pitrou
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> multiprocessing.queues.SimpleQueue leaks 2 fds

___
Python tracker 

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



[issue30171] Emit ResourceWarning in multiprocessing Queue destructor

2017-07-19 Thread Antoine Pitrou

Antoine Pitrou added the comment:

I'm willing to close this issue, as I don't think a ResourceWarning is 
appropriate here.

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

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread Antoine Pitrou

Antoine Pitrou added the comment:

Anyone who thinks those objects stay alive too long can submit a PR for 
SimpleQueue and Pool to close them eagerly.

--

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
versions:  -Python 3.3, Python 3.4

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

This issue is marked as also affecting Python 3.7. I don't see a 
SimpleQueue.close() method in master, but I don't remind any resource warning 
when running tests on master neither.

Does it mean that our test runner miss such file descriptor leak? Or worse, 
that SimpleQueue is not tested? I see a TestSimpleQueue test case in 
Lib/test/_test_multiprocessing.py.

haypo@selma$ ./python -m test test_multiprocessing_spawn -m TestSimpleQueue -R 
3:3
(...)
Tests result: SUCCESS


> This is needed to explicitly release the two file descriptors of the Pipe 
> used internally.  Without it, the file descriptors leak if a reference to the 
> SimpleQueue object happens to stay around for longer than expected (e.g. in a 
> reference cycle, or with PyPy).

Oh ok, the garbage collector is able to close the file descriptors. The bug is 
when a SimpleQueue is not collected.

So again, I consider that a ResourceWarning is needed here. The purpose of a 
ResourceWarning is to warn when a leak may be kept alive longer than expected 
if it's not closed explicitly.

--

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread INADA Naoki

INADA Naoki added the comment:

Sorry, I'm not packaging expert.  Please wait for expert for right direction.

--

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread Elvis Stansvik

Elvis Stansvik added the comment:

Okay, so it seems my "fix" is not complete at all.

Not even `setup.py install` works with plain distutils, since it just copies 
the build dir. Back when I created this issue, I must have (accidentally) 
tested `setup.py install` using setuptools. With setuptools it _does_ work when 
my fix for get_outputs() is applied, but only because (I think) then the egg 
creation code from setuptools is used, which is somehow helped by my fix to 
get_outputs(). Note that it doesn't even work with setuptools if 
--single-version-externally-managed is used (bypassing egg creation). So my 
"fix" only really helped for a very specific case.

So, hm. I guess a more involved fix is necessary in order to get this to work 
for all relevant commands of plain distutils.

Sorry for the noise, I guess I'll close my PR.

--

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

See also my bpo-30171: "Emit ResourceWarning in multiprocessing Queue 
destructor".

--

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
nosy: +davin, pitrou

___
Python tracker 

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



[issue30967] Crash in PyThread_ReInitTLS() in the child process after os.fork() on CentOS 6.5 (Python 2.7.13)

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

Anoter previous change related to PyThread_ReInitTLS(), issue #13817, unlikely 
related to your bug.

commit e0e88b0483d73c925e8f1809d24031acd6bfdf01
Author: Charles-François Natali 
Date:   Thu Feb 2 19:57:19 2012 +0100

Issue #13817: After fork(), reinit the ad-hoc TLS implementation earlier to 
fix
a random deadlock when fork() is called in a multithreaded process in debug
mode, and make PyOS_AfterFork() more robust.

This commit is part of Python 2.7 since Python 2.7.3.

--

___
Python tracker 

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



[issue29640] _PyThreadState_Init and fork race leads to inconsistent key list

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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



[issue30967] Crash in PyThread_ReInitTLS() in the child process after os.fork() on CentOS 6.5 (Python 2.7.13)

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

This bug seems similar to issue #29640. Good news: it contains a fix (not 
merged yet) :-)

--

___
Python tracker 

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



[issue30967] Crash in PyThread_ReInitTLS() in the child process after os.fork() on CentOS 6.5 (Python 2.7.13)

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

Python 2.7 uses its own implementation of Thread Local Storage: see find_key() 
in Python/thread.c. This implementation uses a lock and a chained list. A fork 
only clones the current thread in the child process, all other threads are 
"removed", so Python has to manually remove all TLS variables of the other 
threads using PyThread_ReInitTLS().

I don't think that Python 3 is affected by such bug, since Python 3 uses native 
TLS APIs like pthread pthread_{get,set}specific() on UNIX/BSD.

--
nosy: +haypo
title: Python core crash during os.fork() on CentOS 6.5 (Python 2.7.13) -> 
Crash in PyThread_ReInitTLS() in the child process after os.fork() on CentOS 
6.5 (Python 2.7.13)

___
Python tracker 

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



[issue28638] Optimize namedtuple creation

2017-07-19 Thread INADA Naoki

INADA Naoki added the comment:

I didn't say "let's not do it".
I just want to focus on pure Python implementation at this issue,
because this thread is too long already.
Feel free to open new issue about C implementation.

Even if C implementation is added later, pure Python optimization
can boost PyPy performance. 
(https://github.com/python/cpython/pull/2736#issuecomment-316014866)

--

___
Python tracker 

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



[issue30967] Python core crash during os.fork() on CentOS 6.5 (Python 2.7.13)

2017-07-19 Thread Thomas Mortensson

Thomas Mortensson added the comment:

Unsure if related to:
https://bugs.python.org/issue10517
or
https://bugs.python.org/issue13156

--

___
Python tracker 

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



[issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination

2017-07-19 Thread Xiang Zhang

Changes by Xiang Zhang :


--
dependencies: +multiprocessing.queues.SimpleQueue leaks 2 fds

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

STINNER Victor added the comment:

On Python 3.6+, regrtest is able to detect file descriptor leaks when using 
--huntrleaks. Is someone interested to backport this feature to 3.5 and/or 2.7 
which would mean fix all FD leaks in our test suite?

If someone wants to work on that, I would suggest to first fix all bugs, and 
when the test suite is fine: modify regrtest.

--

___
Python tracker 

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



[issue30967] Python core crash during os.fork() on CentOS 6.5 (Python 2.7.13)

2017-07-19 Thread Thomas Mortensson

New submission from Thomas Mortensson:

Unsure how to re-produce. Have a CoreDump file with the below backtrace. Our 
module is socc, we were running a Twisted application and Python core dumped 
giving us the following backtrace.

Looks like we failed to spawn a process wsing os.fork() due to a double free in 
PyThread_ReInitTLS.

System Details:
CentOS 6.5
Kernel - 2.6.32-696.el6.x86_64
Python 2.7.13 (default, Feb  6 2017, 15:27:35) 
[GCC 4.8.3 20140911 (Red Hat 4.8.3-10)] on linux2
GDB - GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-64.el6


File "/usr/local/lib/python2.7/site-packages/socc/cloudTransport/transport.py", 
line 128, in executeProcessInThread

line +128
ret = reactor.spawnProcess(execProtocol, args[0], args, env=os.environ, 
childFDs={0: "w", 1: "r", 2: "r"})


Python backtrace:

(gdb) py-bt
Traceback (most recent call first):
  File "/usr/local/lib/python2.7/site-packages/twisted/internet/process.py", 
line 382, in _fork
self.pid = os.fork()
  File "/usr/local/lib/python2.7/site-packages/twisted/internet/process.py", 
line 677, in __init__
self._fork(path, uid, gid, executable, args, environment, fdmap=fdmap)
  File "/usr/local/lib/python2.7/site-packages/twisted/internet/posixbase.py", 
line 345, in spawnProcess
processProtocol, uid, gid, childFDs)
  File 
"/usr/local/lib/python2.7/site-packages/socc/cloudTransport/transport.py", line 
128, in executeProcessInThread
  File "/usr/local/lib/python2.7/site-packages/twisted/python/context.py", line 
81, in callWithContext
return func(*args,**kw)
  File "/usr/local/lib/python2.7/site-packages/twisted/python/context.py", line 
118, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/local/lib/python2.7/site-packages/twisted/python/threadpool.py", 
line 196, in _worker
result = context.call(ctx, function, *args, **kwargs)
  File "/usr/local/lib/python2.7/threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/local/lib/python2.7/threading.py", line 801, in __bootstrap_inner
self.run()
  File "/usr/local/lib/python2.7/threading.py", line 774, in __bootstrap
self.__bootstrap_inner()

/* Forget everything not associated with the current thread id.
 * This function is called from PyOS_AfterFork().  It is necessary
 * because other thread ids which were in use at the time of the fork
 * may be reused for new threads created in the forked process.
 */
void
PyThread_ReInitTLS(void)
{
long id = PyThread_get_thread_ident();
struct key *p, **q;

if (!keymutex)
return;

/* As with interpreter_lock in PyEval_ReInitThreads()
   we just create a new lock without freeing the old one */
keymutex = PyThread_allocate_lock();

/* Delete all keys which do not match the current thread id */
q = &keyhead;
while ((p = *q) != NULL) {
if (p->id != id) {
*q = p->next;
free((void *)p); <-FAILED HERE
/* NB This does *not* free p->value! */
}
else
q = &p->next;
}
}

Installed
python27-Logbook-debuginfo-0.9.1-1.el6_7.x86_64.rpm
python27-PyYAML-debuginfo-3.12-1.x86_64.rpm
python27-Twisted-debuginfo-14.0.0-1.x86_64.rpm
python27-cffi-debuginfo-1.9.1-1.el6_7.x86_64.rpm
python27-cryptography-debuginfo-1.7.2-1.el6_7.x86_64.rpm
python27-debuginfo-2.7.13-2.el6_7.x86_64.rpm
python27-psutil-debuginfo-5.1.3-1.x86_64.rpm
python27-simplejson-debuginfo-3.10.0-1.el6_7.el6_7.x86_64.rpm
python27-zope-interface-debuginfo-4.3.3-1.x86_64.rpm

Backtrace is:

#0  0x76db0625 in raise () from /lib64/libc.so.6
#1  0x76db1e05 in abort () from /lib64/libc.so.6
#2  0x76dee537 in __libc_message () from /lib64/libc.so.6
#3  0x76df3f4e in malloc_printerr () from /lib64/libc.so.6
#4  0x76df6cad in _int_free () from /lib64/libc.so.6
#5  0x77b082a9 in PyThread_ReInitTLS () at Python/thread.c:413
#6  0x77b0fbb4 in PyOS_AfterFork () at Modules/signalmodule.c:1004
#7  0x77b12cf6 in posix_fork (self=, noargs=) at Modules/posixmodule.c:3875
#8  0x77ac8460 in call_function (oparg=, 
pp_stack=0x7fffdc043fb0) at Python/ceval.c:4336
#9  PyEval_EvalFrameEx (f=f@entry=0x36bb930, throwflag=throwflag@entry=0) at 
Python/ceval.c:2989
#10 0x77ac9d0d in PyEval_EvalCodeEx (co=, 
globals=, locals=locals@entry=0x0, args=, 
argcount=argcount@entry=7, kws=kws@entry=0x36b54d0, kwcount=1, defs=0x0, 
defcount=0, closure=0x0)
at Python/ceval.c:3584
#11 0x77ac8800 in fast_function (nk=, na=7, n=, pp_stack=0x7fffdc0441f0, func=) at Python/ceval.c:4447
#12 call_function (oparg=, pp_stack=0x7fffdc0441f0) at 
Python/ceval.c:4372
#13 PyEval_EvalFrameEx (f=f@entry=0x36b5270, throwflag=throwflag@entry=0) at 
Python/ceval.c:2989
#14 0x77ac9d0d in PyEval_EvalCodeEx (co=, 
globals=, locals=locals@entry=0x0, 
args=args@entry=0x7fffdeaa5e38, argcount=10, kws=kws@entry=0x0, 
kwcount=kwcoun

[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread STINNER Victor

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread Xiang Zhang

Xiang Zhang added the comment:

Get this solved then we could also solve #23267, which reports pipes leak in 
pool due to using SimpleQueue.

--
nosy: +xiang.zhang

___
Python tracker 

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



[issue28638] Optimize namedtuple creation

2017-07-19 Thread Giampaolo Rodola'

Giampaolo Rodola' added the comment:

> While "40x faster" is more 10x faster than "4x faster", C 
> implementation can boost only CPython and makes maintenance more harder.

As a counter argument against "let's not do it because it'll be harder to 
maintain" I'd like to point out that namedtuple API is already kind of over 
engineered (see: "verbose", "rename", "module" and "_source") and as such it 
seems likely it will remain pretty much the same in the future. So why not 
treat namedtuple like any other basic data structure, boost its internal 
implementation and simply use the existing unit tests to make sure there are no 
regressions? It seems the same barrier does not apply to tuples, lists and sets.

> Of course, 1.9x faster attribute access 
> (http://bugs.python.org/issue28638#msg298499) is attractive.

It is indeed and it makes a huge difference in situations like busy loops. E.g. 
in case of asyncio 1.9x faster literally means being able to serve twice the 
number of reqs/sec:
https://github.com/python/cpython/blob/3e2ad8ec61a322370a6fbdfb2209cf74546f5e08/Lib/asyncio/selector_events.py#L523

--

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread Elvis Stansvik

Elvis Stansvik added the comment:

@inada.naoki: I was half afraid that note in the docs would be brought up :) 
But I should have brought it up myself, sorry about that.

My take is that I see no reason why this limitation should exists. For projects 
that have extensions, and wish to be runnable both directly from the 
distribution source tree, but also be installable, it would be quite convenient 
to be able to set inplace=1 in setup.cfg and have it just work (tm). At least, 
that's how I ran into this issue. Doing so breaks `setup.py install`.

I haven't tested other targets like sdist and bdist_wheel, but I'll do that and 
report back.

--

___
Python tracker 

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



[issue28629] Emit ResourceWarning when implicitly terminating a suspended frame?

2017-07-19 Thread Jakub Stasiak

Changes by Jakub Stasiak :


--
nosy: +jstasiak

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread INADA Naoki

INADA Naoki added the comment:

I thought `inplace` option is for debugging/testing without install,
not for installing or packaging.

As far as document [1], `inplace=1` in `setup.cfg` is noticed as:

  "which is probably a bad idea for this option, since always building 
extensions in-place would break installation of the module distribution."

[1] 
https://docs.python.org/3.6/distutils/configfile.html#writing-the-setup-configuration-file

So I don't know we should fix this or prohibit this.
Is this works for commands other than `install`?  How about sdist and 
bdist_wheel?

--
nosy: +inada.naoki

___
Python tracker 

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



[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

2017-07-19 Thread Armin Rigo

New submission from Armin Rigo:

multiprocessing.queues.SimpleQueue should have a close() method.  This is 
needed to explicitly release the two file descriptors of the Pipe used 
internally.  Without it, the file descriptors leak if a reference to the 
SimpleQueue object happens to stay around for longer than expected (e.g. in a 
reference cycle, or with PyPy).

I think the following would do:

diff -r 0b72fd1a7641 lib-python/2.7/multiprocessing/queues.py
--- a/lib-python/2.7/multiprocessing/queues.py  Sun Jul 16 13:41:28 2017 +0200
+++ b/lib-python/2.7/multiprocessing/queues.py  Wed Jul 19 10:45:03 2017 +0200
@@ -358,6 +358,11 @@
 self._wlock = Lock()
 self._make_methods()

+def close(self):
+# PyPy extension: CPython doesn't have this method!
+self._reader.close()
+self._writer.close()
+
 def empty(self):
 return not self._reader.poll()

--
messages: 298645
nosy: arigo
priority: normal
severity: normal
status: open
title: multiprocessing.queues.SimpleQueue leaks 2 fds
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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



[issue30951] Documentation error in inspect module

2017-07-19 Thread Marco Buttu

Marco Buttu added the comment:

Or maybe: "tuple of names of global variables used in the bytecode"

--
nosy: +marco.buttu

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread Ned Deily

Ned Deily added the comment:

Now has PR waiting for review.  Thanks, Elvis.

--
nosy: +ned.deily
stage:  -> patch review

___
Python tracker 

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



[issue29144] Implicit namespace packages in Python 3.6

2017-07-19 Thread Lumír Balhar

Lumír Balhar added the comment:

Hello.

I've tried the build of python-moksha-common on Fedora rawhide [0] and Fedora 
25 [1].

Fedora rawhide: Python 2.7.13 and 3.6.1, setuptools 36.2.0
Fedora 25: Python 2.7.13 and 3.5.3, setuptools 25.1.1

Source tarball of moksha.common contains pkg_resources-style __init__.py file 
and the setuptools skipped installation of this file in all (four) cases.

It seems that setuptools do the same in all versions but the problem comes with 
Python 3.6 which is more strict than Python 3.5 in behavior related to 
namespace packages.

So, when one part of namespace package doesn't contain __init__.py file and 
other part contains pkg_resources-style __init__.py file:
- in Python 2.7 and 3.5 everything works
- in Python 3.6 submodules cannot import each other

The question is whether it is a bug/feature in Python 3.6 and setuptools should 
install pkg_resources-style __init__.py or not.

What do you think?

[0] https://koji.fedoraproject.org/koji/taskinfo?taskID=20606746
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=20606838

--

___
Python tracker 

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



[issue29225] distutils.command.install_lib.get_outputs() wrong with extensions built inplace

2017-07-19 Thread Elvis Stansvik

Changes by Elvis Stansvik :


--
pull_requests: +2818

___
Python tracker 

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



[issue28638] Optimize namedtuple creation

2017-07-19 Thread INADA Naoki

INADA Naoki added the comment:

I want to focus on pure Python implementation in this issue.

While "40x faster" is more 10x faster than "4x faster", C implementation
can boost only CPython and makes maintenance more harder.

And sometimes "more 10x faster" is not so important.
For example, say application startup takes 1sec and namedtuple
creation took 0.4sec of the 1sec:

  4x faster: 1sec -> 0.7sec  (-30%)
 40x faster: 1sec -> 0.61sec (-39%)

In this case, "4x faster" reduces 0.3sec and "more 10x faster" reduces
only 0.09sec.

Of course, 1.9x faster attribute access 
(http://bugs.python.org/issue28638#msg298499) is attractive.
But this issue is too long already.

--

___
Python tracker 

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



[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

2017-07-19 Thread Steve Dower

Steve Dower added the comment:


New changeset e99d3a52a50b3f836fb9fb88f317aacddd494858 by Steve Dower in branch 
'3.6':
[3.6] bpo-30450: Improved logic for obtaining dependencies (#2751)
https://github.com/python/cpython/commit/e99d3a52a50b3f836fb9fb88f317aacddd494858


--

___
Python tracker 

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



[issue30576] http.server should support HTTP compression (gzip)

2017-07-19 Thread Pierre Quentel

Pierre Quentel added the comment:

Is Python-ideas the appropriate place to get input from other core devs ?

--

___
Python tracker 

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