[issue33330] Better error handling in PyImport_Cleanup()

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


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

___
Python tracker 

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



[issue31493] IDLE cond context: fix code update and font update timers

2018-05-22 Thread Terry J. Reedy

Terry J. Reedy  added the comment:

The patch fixed immediate problem #2 above.  #1 is a separate enhancement and I 
listed it as #4 on the new master issue #33610.

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

___
Python tracker 

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



[issue32831] IDLE: Add docstrings and tests for codecontext

2018-05-22 Thread Terry J. Reedy

Terry J. Reedy  added the comment:

If you are following up with a new patch that includes code changes, make a new 
issue.  In the opening message, please briefly list the mini-issues fixed so I 
can refer changes to purposes.  Perhaps something like

* getspacesfirstword - function and param1 names
...

List the new issue as a dependency of new 'improve code context' issue 33610 
that addresses point 2.

--

___
Python tracker 

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



[issue33441] Expose the sigset_t converter via private API

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Since posix_spawn() has been removed in 3.7, there is no need to backport this 
feature.

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

___
Python tracker 

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



[issue33610] IDLE: Make multiple improvements to CodeContext

2018-05-22 Thread Terry J. Reedy

Change by Terry J. Reedy :


--
dependencies: +IDLE cond context: fix code update and font update timers, IDLE: 
Add docstrings and tests for codecontext, Idle Code Context: separate changing 
current and future editors
stage: test needed -> 
title: IDLE: Improve CodeContext (various issues) -> IDLE: Make multiple 
improvements to CodeContext
versions: +Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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



[issue33537] Help on importlib.resources outputs the builtin open description

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


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

___
Python tracker 

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



[issue33475] Fix converting AST expression to string and optimize parenthesis

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


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

___
Python tracker 

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



[issue33610] IDLE: Improve CodeContext (various issues)

2018-05-22 Thread Terry J. Reedy

New submission from Terry J. Reedy :

There are a number of possible improvements to CodeContext.  They be separate 
issues (and PRs) that are dependencies of this master index issue. Some should 
be fairly easy now that we have the new tests.

1. #32831 added docstrings and tests.  Review has notes.
2. Follow-up may revise and do some user-invisible code cleanups.
3. #31493 cancelled the event loops when instances are deleted.
4. Spinoff from above: 1 or 2 events loops for class, not each instance.
5. #22703: separate initial context state of new window from toggling the state 
of current windows.  Current behavior is buggy.
6. Gray-out Options => Code Context on non-editor windows. (This would have to 
be revised again if windows became panes in master window.)
7. Change fixed # of lines to variable # of lines as needed, up to limit.  
About 15 is limit for 4-space indents in 80 char lines. 
8. Click on context line jumps to line. Show it at top of window.
9. Reenable user config of context colors?
10. Somehow mark blocks in editor.  Subtle background color change?
Or tag just the indents, or, if add line numbers, the line numbers?

--
assignee: terry.reedy
components: IDLE
messages: 317357
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Improve CodeContext (various issues)
type: enhancement

___
Python tracker 

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



[issue33454] Mismatched C function signature in _xxsubinterpreters.channel_close()

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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



[issue27300] tempfile.TemporaryFile(): missing errors=... argument

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Thank you Stephan for your contribution!

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.6

___
Python tracker 

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



[issue27300] tempfile.TemporaryFile(): missing errors=... argument

2018-05-22 Thread Serhiy Storchaka

New submission from Serhiy Storchaka :


New changeset 825aab95fde959541859383f8ea7e7854ebfd49f by Serhiy Storchaka 
(sth) in branch 'master':
bpo-27300: Add the errors parameter to tempfile classes. (GH-6696)
https://github.com/python/cpython/commit/825aab95fde959541859383f8ea7e7854ebfd49f


--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue27485] urllib.splitport -- is it official or not?

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

This change made test_urlparse failing when ran with -We. Or just producing a 
lot of warnings in the default mode.

==
ERROR: test_splitattr (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1113, in 
test_splitattr
self.assertEqual(splitattr('/path;attr1=value1;attr2=value2'),
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 1103, in splitattr
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splitattr() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splithost (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1006, in 
test_splithost
self.assertEqual(splithost('//www.example.org:80/foo/bar/baz.html'),
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 977, in splithost
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splithost() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splitnport (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1077, in 
test_splitnport
self.assertEqual(splitnport('parrot:88'), ('parrot', 88))
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 1049, in 
splitnport
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splitnport() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splitpasswd (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1050, in 
test_splitpasswd
self.assertEqual(splitpasswd('user:ab'), ('user', 'ab'))
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 1013, in 
splitpasswd
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splitpasswd() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splitport (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1066, in 
test_splitport
self.assertEqual(splitport('parrot:88'), ('parrot', '88'))
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 1026, in splitport
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splitport() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splitquery (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1091, in 
test_splitquery
self.assertEqual(splitquery('http://python.org/fake?foo=bar'),
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 1073, in 
splitquery
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splitquery() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splittag (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 1101, in 
test_splittag
self.assertEqual(splittag('http://example.com?foo=bar#baz'),
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", line 1088, in splittag
DeprecationWarning, stacklevel=2)
DeprecationWarning: urllib.parse.splittag() is deprecated as of 3.8, use 
urllib.parse.urlparse() instead

==
ERROR: test_splittype (test.test_urlparse.Utility_Tests)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-gc/Lib/test/test_urlparse.py", line 998, in 
test_splittype
self.assertEqual(splittype('type:opaquestring'), ('type', 'opaquestring'))
  File "/home/serhiy/py/cpython-gc/Lib/urllib/parse.py", 

[issue13886] readline-related test_builtin failure

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

This old issue still is not fixed. Martin, Xavier, could you open a PR please?

--

___
Python tracker 

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



[issue31529] IDLE: Add docstrings and tests for editor.py reload functions

2018-05-22 Thread Terry J. Reedy

Terry J. Reedy  added the comment:

There is a reference to this issue in #31494, msg302628 (CodeContext loops).

--

___
Python tracker 

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



[issue33565] strange tracemalloc results

2018-05-22 Thread INADA Naoki

INADA Naoki  added the comment:

I can't reproduce it:

  File "test1.py", line 19, in do_get_obj
response = s3_client.get_object(Bucket='archpi.dabase.com', Key='style.css')
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/client.py",
 line 314, in _api_call
return self._make_api_call(operation_name, kwargs)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/client.py",
 line 599, in _make_api_call
operation_model, request_dict)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/endpoint.py",
 line 148, in make_request
return self._send_request(request_dict, operation_model)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/endpoint.py",
 line 173, in _send_request
request = self.create_request(request_dict, operation_model)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/endpoint.py",
 line 157, in create_request
operation_name=operation_model.name)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/hooks.py",
 line 227, in emit
return self._emit(event_name, kwargs)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/hooks.py",
 line 210, in _emit
response = handler(**kwargs)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/signers.py",
 line 90, in handler
return self.sign(operation_name, request)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/signers.py",
 line 156, in sign
auth.add_auth(request)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/auth.py",
 line 420, in add_auth
super(S3SigV4Auth, self).add_auth(request)
  File 
"/Users/inada-n/tmp/boto-leak/venv/lib/python3.6/site-packages/botocore/auth.py",
 line 352, in add_auth
raise NoCredentialsError
botocore.exceptions.NoCredentialsError: Unable to locate credentials

--

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread miss-islington

miss-islington  added the comment:


New changeset 2751dccca4098b799ea575bb35cec9959c74684a by Miss Islington (bot) 
in branch '3.7':
bpo-33604: Remove Pending from hmac Deprecation warning. (GH-7062)
https://github.com/python/cpython/commit/2751dccca4098b799ea575bb35cec9959c74684a


--
nosy: +miss-islington

___
Python tracker 

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



[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

2018-05-22 Thread David Bolen

David Bolen  added the comment:

I have migrated the win8 and win10 builders to a different machine type on 
Azure, which seems to have restored more reasonable performance for the tests, 
at least in the first set of builds.  Assuming that continues to hold true, it 
should resolve this issue.

--

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread miss-islington

Change by miss-islington :


--
pull_requests: +6695

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread Gregory P. Smith

Gregory P. Smith  added the comment:


New changeset 8bb0b5b03cffa2a2e74f248ef479a9e7fbe95cf4 by Gregory P. Smith 
(Matthias Bussonnier) in branch 'master':
bpo-33604: Remove Pending from hmac Deprecation warning. (GH-7062)
https://github.com/python/cpython/commit/8bb0b5b03cffa2a2e74f248ef479a9e7fbe95cf4


--

___
Python tracker 

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



[issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes

2018-05-22 Thread miss-islington

miss-islington  added the comment:


New changeset cd57b48ef9a70b7ef693ba52aaf38d7c945ab5d3 by Miss Islington (bot) 
in branch '3.7':
bpo-33570: TLS 1.3 ciphers for OpenSSL 1.1.1 (GH-6976)
https://github.com/python/cpython/commit/cd57b48ef9a70b7ef693ba52aaf38d7c945ab5d3


--
nosy: +miss-islington

___
Python tracker 

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



[issue33609] Document that dicts preserve insertion order

2018-05-22 Thread Yury Selivanov

New submission from Yury Selivanov :

I don't see it documented that dicts preserve insertion order. 3.7 what's new 
points to [1], but that section doesn't have a "version changed" tag.

IMO, [1] should have two version changed tags: one for 3.6, and one for 3.7.

Also, it would be great if we could document how the order is preserved when a 
key is deleted from the dict etc.

[1] https://docs.python.org/3.7/library/stdtypes.html#mapping-types-dict

--
assignee: docs@python
components: Documentation
messages: 317346
nosy: docs@python, inada.naoki, ned.deily, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Document that dicts preserve insertion order
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

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



[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2018-05-22 Thread STINNER Victor

Change by STINNER Victor :


--
title: Add a cross-interpreter-safe mechanism to indicate that an object may be 
destroyed. -> [subinterpreters] Add a cross-interpreter-safe mechanism to 
indicate that an object may be destroyed.

___
Python tracker 

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



[issue33607] [subinterpreters] Explicitly track object ownership (and allocator).

2018-05-22 Thread STINNER Victor

Change by STINNER Victor :


--
title: Explicitly track object ownership (and allocator). -> [subinterpreters] 
Explicitly track object ownership (and allocator).

___
Python tracker 

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



[issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes

2018-05-22 Thread miss-islington

Change by miss-islington :


--
pull_requests: +6694

___
Python tracker 

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



[issue33570] OpenSSL 1.1.1 / TLS 1.3 cipher suite changes

2018-05-22 Thread Christian Heimes

Christian Heimes  added the comment:


New changeset e8eb6cb7920ded66abc5d284319a8539bdc2bae3 by Christian Heimes in 
branch 'master':
bpo-33570: TLS 1.3 ciphers for OpenSSL 1.1.1 (GH-6976)
https://github.com/python/cpython/commit/e8eb6cb7920ded66abc5d284319a8539bdc2bae3


--

___
Python tracker 

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



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2018-05-22 Thread pmpp

Change by pmpp :


--
nosy: +pmpp

___
Python tracker 

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



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

"That is relatively straight-forward except in one case: indicating that the 
other interpreter doesn't need the object to exist any more (similar to 
PyBuffer_Release() but more general)"

Why an interpreter would access an object from a different interpreter? Each 
interpreter should have its own object space, no?

--

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


--
nosy: +christian.heimes, gregory.p.smith

___
Python tracker 

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



[issue33569] dataclasses InitVar does not maintain any type info

2018-05-22 Thread Eric V. Smith

Eric V. Smith  added the comment:

This seems like a reasonable request.

--
nosy: +eric.smith

___
Python tracker 

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



[issue33562] Check that the global settings for asyncio are not changed by tests

2018-05-22 Thread STINNER Victor

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread Matthias Bussonnier

Matthias Bussonnier  added the comment:

I've sent two PRs, one that updates the deprecation from 
PendingDeprecationWarning to DeprecationWarning that likely should get applied 
to 3.6, and 3.7 ?

And a PR to actually remove the default in 3.8.

--

___
Python tracker 

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



[issue32400] inspect.isdatadescriptor false negative

2018-05-22 Thread Aaron Hall

Change by Aaron Hall :


--
nosy: +Aaron Hall

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread Matthias Bussonnier

Change by Matthias Bussonnier :


--
pull_requests: +6693

___
Python tracker 

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



[issue33565] strange tracemalloc results

2018-05-22 Thread Alexander Mohr

Alexander Mohr  added the comment:

yes, memory does go up.  If you click the botocore bug link you'll see a graph 
of memory usage over time.

--

___
Python tracker 

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



[issue33605] Detect accessing event loop from a different thread outside of _debug

2018-05-22 Thread Yury Selivanov

Yury Selivanov  added the comment:

> I suggest that asyncio should be stricter about this error and that methods 
> and functions that operate on the event loop, such as call_soon, call_later, 
> create_task, ensure_future, and close, should all call _check_thread() even 
> when not in debug mode. _check_thread() warns that it "should only be called 
> when self._debug == True", hinting at "performance reasons", but that doesn't 
> seem justified. threading.get_ident() is efficiently implemented in C, and 
> comparing that integer to another cached integer is about as efficient an 
> operation as it gets.

I'd be OK with this if the performance penalty is within 0.5% in 
microbenchmarks for asyncio & uvloop.

--

___
Python tracker 

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



[issue33607] Explicitly track object ownership (and allocator).

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

"Either we'd add 2 pointer-size fields to PyObject or we would keep a separate 
hash table (or two) pointing from each object to the info (...)"

The expect a huge impact on the memory footprint. I dislike the idea.

Currently, the smallest Python object is:

>>> sys.getsizeof(object())
16

It's just two pointers. Adding two additional pointers would simply double the 
size of the object.

"Now the C-API offers a way to switch the allocator, so there's no guarantee
that the right allocator is used in PyMem_Free()."

I would expect that either all interpreters use the same memory allocator, or 
that each interpreter uses its own allocator. If you use one allocator per 
interpreter, calling PyMem_Free() from the wrong interpreter would just crash. 
As you get a crash when you call free() on an object allocated by PyMem_Free(). 
You can extend PYTHONMALLOC=debug to detect bugs. This builtin debugger is 
already able to catch misuses of allocators. Adding extra pointers to this 
debugger is acceptable since it doesn't modify the footprint of the default 
mode.

--

___
Python tracker 

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



[issue33565] strange tracemalloc results

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

> this means 21 blocks were not released, and in this case leaked because 
> nothing should be held onto after the first iteration (creating the initial 
> connector in the connection pool.  In the head object case that's going to be 
> a new connector per iteration, however the old one should go away.

I'm not sure that I understand properly. If you call the function many times, 
does the memory usage increase?

I'm not sure that this issue is a bug in Python.

--

___
Python tracker 

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



[issue33516] unittest.mock: Add __round__ to supported magicmock methods

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

Thank you Martijn Pieters for the feature request/bug report, and thanks John 
Reese for the implementation!

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

___
Python tracker 

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



[issue33516] unittest.mock: Add __round__ to supported magicmock methods

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:


New changeset 6c4fab0f4b95410a1a964a75dcdd953697eff089 by Victor Stinner (John 
Reese) in branch 'master':
bpo-33516: Add support for __round__ in MagicMock (GH-6880)
https://github.com/python/cpython/commit/6c4fab0f4b95410a1a964a75dcdd953697eff089


--
nosy: +vstinner

___
Python tracker 

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



[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions

2018-05-22 Thread Eric Snow

Eric Snow  added the comment:

good point :)

--

___
Python tracker 

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



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2018-05-22 Thread Eric Snow

Eric Snow  added the comment:

As a lesser (IMHO) alternative, we could also modify Py_DECREF
to respect a new "shared" marker of some sort (perhaps relative
to #33607), but that would probably still require one of the
refcount-based solutions (and add a branch to Py_DECREF).

--
versions: +Python 3.8 -Python 3.4

___
Python tracker 

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



[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

2018-05-22 Thread Eric Snow

New submission from Eric Snow :

In order to keep subinterpreters properly isolated, objects
from one interpreter should not be used in C-API calls in
another interpreter.  That is relatively straight-forward
except in one case: indicating that the other interpreter
doesn't need the object to exist any more (similar to
PyBuffer_Release() but more general).  I consider the
following solutions to be the most viable.  Both make use
of recounts to protect cross-interpreter usage (with incref
before sharing).

1. manually switch interpreters (new private function)
  a. acquire the GIL
  b. if refcount > 1 then decref and release the GIL
  c. switch
  d. new thread (or re-use dedicated one)
  e. decref
  f. kill thread
  g. switch back
  h. release the GIL
2. change pending call mechanism (see Py_AddPendingCall) to
   per-interpreter instead of global (add "interp" arg to
   signature of new private C-API function)
  a. queue a function that decrefs the object
3. new cross-interpreter-specific private C-API function
  a. queue the object for decref (a la Py_AddPendingCall)
 in owning interpreter

I favor #2, since it is more generally applicable.  #3 would
probably be built on #2 anyway.  #1 is relatively inefficient.
With #2, Py_AddPendingCall() would become a simple wrapper
around the new private function.

--
messages: 317333
nosy: eric.snow, ncoghlan, serhiy.storchaka, vstinner, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a cross-interpreter-safe mechanism to indicate that an object may be 
destroyed.
versions: Python 3.4

___
Python tracker 

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Please ignore the last paragraph. It was my mistake, all add_subparsers() 
parameters are keyword-only, and _SubParsersAction is a privale class.

--

___
Python tracker 

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Anthony Sottile

Anthony Sottile  added the comment:

The bug is orthogonal, you can trigger it without the `required=` keyword 
argument via the (currently suggested) monkeypatch workaround which restores 
the pre-3.3 behaviour:

import argparse

parser = argparse.ArgumentParser()
subp = parser.add_subparsers()
subp.add_parser('test')
subp.required = True
parser.parse_args()


$ python3 test.py
Traceback (most recent call last):
  File "test.py", line 7, in 
parser.parse_args()
  File 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/argparse.py",
 line 1730, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/argparse.py",
 line 1762, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File 
"/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6/lib/python3.6/argparse.py",
 line 1997, in _parse_known_args
', '.join(required_actions))
TypeError: sequence item 0: expected str instance, NoneType found


Also note that when `dest` is specified it works fine:


import argparse

parser = argparse.ArgumentParser()
subp = parser.add_subparsers(dest='cmd')
subp.add_parser('test')
subp.required = True
parser.parse_args()

$ python3 test.py
usage: test.py [-h] {test} ...
test.py: error: the following arguments are required: cmd

--

___
Python tracker 

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



[issue33607] Explicitly track object ownership (and allocator).

2018-05-22 Thread Eric Snow

New submission from Eric Snow :

When an object is created it happens relative to the current
thread (ergo interpreter) and the current allocator (part of
global state).  We do not track either of these details for
the object.  It may make sense to start doing so (reasons next).

Regarding tracking the interpreter, that originating interpreter
can be thought of as the owner.  Any lifecycle operations should
happen relative to that interpreter.  Furthermore, the object
should be used in C-API calls only in that interpreter (i.e.
when the current thread's Py_ThreadState belongs to that
interpreter).  This hasn't been an issue since currently all
interpreters in the process share the GIL, as well as the fact
that subinterpreters haven't been heavily used historically.
However, the possibility of no longer sharing the GIL suggests
that tracking the owning interpreter (and perhaps even other
"sharing" interpreters) would be important.  Furthermore,
in the last few years subinterpreters have seen increasing usage
(see Openstack Ceph), and knowing the originating interpreter
for an object can be useful there.  Regardless, even in the
single interpreter case knowing the owning interpreter is
important during runtime finalization (which is currently
slightly broken), which impacts CPython embedders.

Regarding the allocator, there used to be just a single global
one that the runtime used from start to finish.  Now the C-API
offers a way to switch the allocator, so there's no guarantee
that the right allocator is used in PyMem_Free().  This has
already had a negative impact on efforts to clean up CPython's
runtime initialization.  It also results in problems during
finalization.  Additionally, we are looking into moving the
allocator from the global runtime state to the per-interpreter
(or even per-thread or per-context) state value.  In that world
it would be essential to know which allocator was used when
creating the object.  There are other possible applications
based on knowing an object's allocator, but I'll stop there.

To sort all this out we would need to track per-object:

* originating allocator (pointer or id)
* owning interpreter (pointer or id)
* (possibly) "sharing" interpreters (linked list?)

Either we'd add 2 pointer-size fields to PyObject or we would
keep a separate hash table (or two) pointing from each object
to the info (similar to how we've considered doing for
refcounts).  To alleviate impact on the common case (not
embedded, single interpreter, same allocator), we could default
to not tracking interpreter/allocator and take a lookup failure
to mean "main interpreter, default allocator".

--
messages: 317330
nosy: eric.snow, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: Explicitly track object ownership (and allocator).
versions: Python 3.8

___
Python tracker 

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Wouldn't be better to first fix this bug, and only after that add the 
'required' parameter?

Adding it introduced yet one bug: when pass arguments as positional, the 'help' 
argument will be swallowed. You can add new parameters only after existing 
positional parameters.

--

___
Python tracker 

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



[issue33606] Improve logging performance when logger disabled

2018-05-22 Thread Vinay Sajip

New submission from Vinay Sajip :

If a logger is disabled (by setting it's disabled attribute to True), the check 
for this is done late in the dispatch of the logging event - during the 
handle() call - rather than isEnabledFor(), which would short-circuit some 
processing. So the check for logger.disabled should be moved to isEnabledFor().

Credit to Abhijit Gadgil for raising this:

https://stackoverflow.com/questions/50453121/logger-disabled-check-much-later-in-python-logging-module-whats-the-rationale

--
assignee: vinay.sajip
components: Library (Lib)
messages: 317328
nosy: vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve logging performance when logger disabled
type: enhancement
versions: Python 3.8

___
Python tracker 

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



[issue33603] Subprocess Thread handles grow with each call and aren't released [Windows]

2018-05-22 Thread Gregory P. Smith

Change by Gregory P. Smith :


--
title: Subprocess Thread handles  grow with each call and aren't released until 
script ends -> Subprocess Thread handles grow with each call and aren't 
released [Windows]

___
Python tracker 

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



[issue33593] Support heapq on typed arrays?

2018-05-22 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

As noted by Serhiy, the interaction with the Array type would incur significant 
overhead.  Your fastest approach will be to follow his suggest to first convert 
to a list and then perform heap manipulations.

Marking this as closed.  Thank you for the suggestion.

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Anthony Sottile

Anthony Sottile  added the comment:

That's a separate issue (also a bug introduced by the bad 3.3 patch): 
https://bugs.python.org/issue29298

I have an open PR to fix it as well but it has not seen review action: 
https://github.com/python/cpython/pull/3680

--

___
Python tracker 

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

I tried to use add_subparsers() with required=True and have found it not usable.

import argparse
parser = argparse.ArgumentParser(prog='PROG')
subparsers = parser.add_subparsers(required=True)
parser_a = subparsers.add_parser('a')
parser_b = subparsers.add_parser('b')
parser.parse_args([])

The result:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 1745, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 1777, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/home/serhiy/py/cpython/Lib/argparse.py", line 2012, in 
_parse_known_args
', '.join(required_actions))
TypeError: sequence item 0: expected str instance, NoneType found

Seems that not only the default value should be changed, but the whole PR 3027 
should be reverted.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue33605] Detect accessing event loop from a different thread outside of _debug

2018-05-22 Thread Hrvoje Nikšić

New submission from Hrvoje Nikšić :

Looking at StackOverflow's python-asyncio tag[1], it appears that it's a very 
common mistake for users to invoke asyncio functions or methods from a thread 
other than the event loop thread. In some cases this happens because the user 
is careless with threads and hasn't read the documentation. But in many cases 
what happens is that a third-party library invoked a callback in a different 
thread without making it transparent that that's what it's doing.

The trouble is that in many cases doing these things, e.g. calling 
loop.call_soon() or loop.create_task() from the wrong thread, will *appear to 
work*. The typical event loop is busy servicing different coroutines, so a 
function or task enqueued without a proper wakeup gets picked up soon enough. 
This is, of course, a disaster waiting to happen because it could easily lead 
to corruption of event loop's data structures. But users don't know that, and 
many of them become aware of the problem only after wondering "why does my code 
start working when I add a coroutine that does nothing but asyncio.sleep(0.1) 
in an infinite loop?" Some may never even fix their code, just assuming that 
asyncio takes a long time to process a new task or something like that.

I suggest that asyncio should be stricter about this error and that methods and 
functions that operate on the event loop, such as call_soon, call_later, 
create_task, ensure_future, and close, should all call _check_thread() even 
when not in debug mode. _check_thread() warns that it "should only be called 
when self._debug == True", hinting at "performance reasons", but that doesn't 
seem justified. threading.get_ident() is efficiently implemented in C, and 
comparing that integer to another cached integer is about as efficient an 
operation as it gets.

The added benefit would be a vast improvement of robustness of asyncio-based 
programs, saving many hours of debugging.


[1]
Here is an incomplete list of questions where the users stumbled on this 
problem, and that's only from the last three months or so:

https://stackoverflow.com/questions/49906034/python-asyncio-run-forever-and-tasks
https://stackoverflow.com/questions/49851514/python-websockets-and-gtk-confused-about-asyncio-queue
https://stackoverflow.com/questions/49533612/using-asyncio-loop-reference-in-another-file
https://stackoverflow.com/questions/49093623/strange-behaviour-when-task-added-to-empty-loop-in-different-thread
https://stackoverflow.com/questions/48836285/python-asyncio-event-wait-not-responding-to-event-set
https://stackoverflow.com/questions/48833644/how-to-wait-for-asynchronous-callback-in-the-background-i-e-not-invoked-by-us
https://stackoverflow.com/questions/48695670/running-asynchronous-code-synchronously-in-separate-thread

--
components: asyncio
messages: 317324
nosy: asvetlov, hniksic, yselivanov
priority: normal
severity: normal
status: open
title: Detect accessing event loop from a different thread outside of _debug
type: enhancement
versions: Python 3.7, Python 3.8

___
Python tracker 

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



[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends

2018-05-22 Thread Eryk Sun

Eryk Sun  added the comment:

The 2nd example with subprocess.run() creates two threads in the Python 
process, since you're redirecting both stdout and stderr to pipes and run() 
calls communicate(). The first example with subprocess.Popen() shouldn't create 
any threads. In either case, nothing in subprocess should be opening a handle 
for a thread.

Please attach a minimal script that reproduces the problem, preferably running 
a command everyone can test such as "python.exe -V" and preferably with 
shell=False if the problem can be reproduced without the shell. Also, describe 
your Python setup, i.e. the installed distribution and packages. Something 
could be monkey patching the subprocess module.

--

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread Matthias Bussonnier

Change by Matthias Bussonnier :


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

___
Python tracker 

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



[issue33604] HMAC default to MD5 marked as to be removed in 3.6

2018-05-22 Thread Matthias Bussonnier

New submission from Matthias Bussonnier :

HMAC docs says digestmod=md5 default will be removed in 3.6, but was not. 

We should likely bumpt that to 3.8 in the documentation, and actually remove it 
in 3.8

--
messages: 317322
nosy: mbussonn
priority: normal
severity: normal
status: open
title: HMAC default to MD5 marked as to be removed in 3.6
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Anthony Sottile

Anthony Sottile  added the comment:

Is there then no pathway for actually fixing the bug?  aka how can I get 
`required=True` to be the default.

--

___
Python tracker 

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



[issue33531] test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI

2018-05-22 Thread Terry J. Reedy

Terry J. Reedy  added the comment:

The patch seems to have worked.  The last AppVeyor failure was a day ago, when 
testing the 3.7 backport of the fix.
https://ci.appveyor.com/project/python/cpython/history

--

___
Python tracker 

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



[issue33109] argparse: make new 'required' argument to add_subparsers default to False instead of True

2018-05-22 Thread Ned Deily

Ned Deily  added the comment:

> Considering the huge popularity of these SO questions, I don't think this 
> should be reverted [...]

As I understand it (and, again, I make no claim to be an argparse expert), 
there does not seem to be one absolutely correct answer here; there has to be a 
tradeoff.  If we revert the change in default as in PR 6919, users porting code 
from 2.7 will continue to run into the unfortunate change in behavior 
introduced in 3.3.  But, with the reversion, those users are no worse off than 
they were before: the existing workarounds, like those in the cited SO answers, 
still apply.  And it's a one-time annoyance for them, along with all the other 
changes they may need to make to port to a current Python 3.x.  Whereas, if the 
change is not reverted, then we introduce a new incompatibility to a new class 
of users, that is, those upgrading from Python 3.3 through 3.6 to 3.7, 
generating a new set of SO questions, etc.  That seems to be making a 
less-than-ideal situation worse.  So, as release manager, I continue to think 
that the reversion (PR 6919) should go in to 3.7.0.  (For 3.8 and beyond, it 
 would be great to have at least one core developer take responsibility for 
argparse enhancements.)

--

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

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


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

___
Python tracker 

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



[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends

2018-05-22 Thread GranPrego

GranPrego  added the comment:

Process explorer is showing the handles as belonging to the python executable. 
I can see the cmd process start,then the executable which terminates cleanly.  
I can see thread handles appearing under the python process, with some 
terminating, but more green than red, hence the increase.  I can post a 
screenshot tomorrow. Thanks

--

___
Python tracker 

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



[issue33593] Support heapq on typed arrays?

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Workaround:

alist = list(a)
heapq.heapify(alist)
a[:] = alist

And it should be not much slower than using heapq.heapify() directly if it 
could support general sequences. Using it with array.array would add 
significant overhead due to boxing.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends

2018-05-22 Thread Antoine Pitrou

Change by Antoine Pitrou :


--
nosy: +giampaolo.rodola, gregory.p.smith

___
Python tracker 

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



[issue33592] Document contextvars C API

2018-05-22 Thread miss-islington

miss-islington  added the comment:


New changeset afec2d583a06849c5080c6cd40266743c8e04b3e by Miss Islington (bot) 
in branch '3.7':
bpo-33592: Document the C API in PEP 567 (contextvars) (GH-7033)
https://github.com/python/cpython/commit/afec2d583a06849c5080c6cd40266743c8e04b3e


--
nosy: +miss-islington

___
Python tracker 

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



[issue33593] Support heapq on typed arrays?

2018-05-22 Thread Diego Argueta

Diego Argueta  added the comment:

However I do see your point about the speed.

--

___
Python tracker 

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



[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

There is usually more complex code between PyErr_Fetch() and 
_PyErr_ChainExceptions():

PyObject *exc, *val, *tb, *close_result;
PyErr_Fetch(, , );
close_result = _PyObject_CallMethodId(result, _close, NULL);
_PyErr_ChainExceptions(exc, val, tb);
Py_XDECREF(close_result);

Many exceptions can be raised and silenced or overridden between, but we are 
interesting in chaining the only latest exception (or restoring the original 
exception if all exceptions between were silenced).

--

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread Yury Selivanov

Yury Selivanov  added the comment:

This is such a great idea. +1 from me.

--
nosy: +yselivanov

___
Python tracker 

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



[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends

2018-05-22 Thread Eryk Sun

Eryk Sun  added the comment:

The thread handle that CreateProcess returns gets immediately closed in 
Popen._execute_child, so I can't see how this is due to subprocess. Please 
check to make sure these thread handles aren't for threads in your own process. 
Set the lower pane of Process Explorer to show the handle list. For a thread 
handle, the name field shows the executable name and PID of the process to 
which the thread is attached.

--
nosy: +eryksun

___
Python tracker 

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



[issue33593] Support heapq on typed arrays?

2018-05-22 Thread Diego Argueta

Diego Argueta  added the comment:

I was referring to the C arrays in the Python standard library: 
https://docs.python.org/3/library/array.html

--

___
Python tracker 

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



[issue33592] Document contextvars C API

2018-05-22 Thread miss-islington

Change by miss-islington :


--
pull_requests: +6691

___
Python tracker 

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



[issue33592] Document contextvars C API

2018-05-22 Thread Yury Selivanov

Yury Selivanov  added the comment:


New changeset b2f5f59ae15564b991f3ca4850e6ad28d9faacbc by Yury Selivanov (Elvis 
Pranskevichus) in branch 'master':
bpo-33592: Document the C API in PEP 567 (contextvars) (GH-7033)
https://github.com/python/cpython/commit/b2f5f59ae15564b991f3ca4850e6ad28d9faacbc


--

___
Python tracker 

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



[issue33565] strange tracemalloc results

2018-05-22 Thread Alexander Mohr

Alexander Mohr  added the comment:

that's not going to affect 
http://pytracemalloc.readthedocs.io/api.html#get_traced_memory.  There is no 
filter for that :)

as to your sum that's exactly what my original callstack lists:
21 memory blocks: 4.7 KiB

this means 21 blocks were not released, and in this case leaked because nothing 
should be held onto after the first iteration (creating the initial connector 
in the connection pool.  In the head object case that's going to be a new 
connector per iteration, however the old one should go away.

--

___
Python tracker 

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



[issue33565] strange tracemalloc results

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

Oh. Usually, I strip traces allocated by tracemalloc using filters:

http://pytracemalloc.readthedocs.io/examples.html#pretty-top

snapshot = snapshot.filter_traces((
tracemalloc.Filter(False, ""),
tracemalloc.Filter(False, ""),
))

--

___
Python tracker 

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



[issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions

2018-05-22 Thread Eric Snow

Eric Snow  added the comment:

FTR, see PEP 490 ("Chain exceptions at C level") which proposed implicitly 
chaining exceptions in the PyErr_* API.

While that PEP was rejected (not all exceptions should be chained), it does 
make a good point about the clunkiness of using _PyErr_ChainExceptions():

PyObject *exc, *val, *tb;
PyErr_Fetch(, , );
PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);
_PyErr_ChainExceptions(exc, val, tb);

So if we are going to add a public helper function, let's consider adding one 
that simplifies usage.  For instance, how about one that indicates the next 
exception set should chain:

PyErr_ChainNext();
PyErr_Format(ZipImportError, "can't open Zip file: %R", archive);

Or perhaps we should revive PEP 490 with an opt out mechanism for the cases 
where we don't want chaining:

PyErr_NoChainNext();
PyErr_Format(PyExc_RuntimeError, "uh-oh");

--
nosy: +eric.snow, vstinner
versions: +Python 3.8 -Python 3.7

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread INADA Naoki

INADA Naoki  added the comment:

In Doc folder:

  make clean
  make PYTHON=../python venv
  /usr/bin/time make html

master:

  113.15user 0.41system 1:55.46elapsed 98%CPU (0avgtext+0avgdata 
205472maxresident)k
  18800inputs+223544outputs (1major+66066minor)pagefaults 0swaps

  111.07user 0.44system 1:51.72elapsed 99%CPU (0avgtext+0avgdata 
205052maxresident)k
  0inputs+223376outputs (0major+65855minor)pagefaults 0swaps

patched:

  109.92user 0.44system 1:50.43elapsed 99%CPU (0avgtext+0avgdata 
195832maxresident)k
  0inputs+223376outputs (0major+63206minor)pagefaults 0swaps

  110.70user 0.40system 1:51.50elapsed 99%CPU (0avgtext+0avgdata 
195516maxresident)k
  0inputs+223376outputs (0major+62723minor)pagefaults 0swaps

It seems reduced 5% memory footprint, and performance difference is very small.

--

___
Python tracker 

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



[issue33565] strange tracemalloc results

2018-05-22 Thread Alexander Mohr

Alexander Mohr  added the comment:

I believe your method is flawed, when enabling tracemalloc it's going to be 
using memory as well to store the traces.  I still believe you need to use the 
method I mentioned and further even if we don't take into account the total 
memory the traces I mentioned need to be explained.

--

___
Python tracker 

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



[issue33590] sched.enter priority has no impact on execution

2018-05-22 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

It would be nice to either modify the example or add another example to show 
the use of enterabs() and of the priority field being used as a tie breaker for 
two events scheduled at the same time.

--
nosy: +rhettinger
status: pending -> open

___
Python tracker 

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



[issue33593] Support heapq on typed arrays?

2018-05-22 Thread Raymond Hettinger

Raymond Hettinger  added the comment:

I don't think we should go down this path.  The efficiency of the C 
implementation depends on it being tightly coupled to lists.  This tool is used 
in the schedulers of various async tools (such as Tornando), used for merge(), 
nsmallest(), and nlargest() all of which depend on this foundational tool being 
very fast.

Also, I question whether it makes sense at all to be heapifying numpy arrays 
using standard library tooling.  It numpy arrays actually needed this and 
needed for it to be efficient, it would need to be implemented natively in 
numpy.

--
nosy: +rhettinger
versions: +Python 3.8 -Python 2.7, Python 3.6

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread INADA Naoki

INADA Naoki  added the comment:

@Serhiy

php implemented similar idea recently.
https://react-etc.net/entry/improvements-to-garbage-collection-gc-php-7-3-boosts-performance-in-benchmark

In short, each tracked object have only "index" of GC struct, not "pointer".
GC struct is in array and it can be resized.

I tried to copy it, but there are some challenges:

* _PyObject_GC_TRACK() will resize GC array and cause MemoryError.  It's not 
API compatible.
* php's GC is not generational. This design may slow down moving objects 
between generation.
* We need one word (index) for object header and two words (refcnt, pointer to 
the object) for GC struct.  It means we can reduce memory footprint only for 
untracked dicts and tuples.

And this is my first time GC hack.  So I gave up PHP way and choose easier way.

Anyway, we have gc.freeze() now which can be used for avoid CoW after fork.

--

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Le 22/05/2018 à 17:31, INADA Naoki a écrit :
> 
> INADA Naoki  added the comment:
> 
> $ ./python-gc -c 'import asyncio,sys; sys._debugmallocstats()'

Thanks.  You can also collect peak memory stats during the benchmark
suite, though the numbers may be approximate.

--

___
Python tracker 

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



[issue30877] possibe typo in json/scanner.py

2018-05-22 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


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

___
Python tracker 

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



[issue2504] Add gettext.pgettext() and variants support

2018-05-22 Thread Éric Araujo

Éric Araujo  added the comment:

It was an answer to «Is there anything I can do to help get this into the 
codebase»

Feel free to take this on!  I’ll try to review.

--

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

This is an interesting idea.

The other problem with the garbage collecting is that it modifies the memory of 
all collectable objects. This leads to deduplicating virtually all memory 
blocks after the fork, even if these objects are not used in the child.

If gc_refcnt is used only when collecting, what if allocate a linear array for 
them for that time? This will save less memory (only one word per object in the 
peak), but avoid modifying the memory of not collected objects (except pointers 
at the ends of generation lists and neighbors of collected objects).

--

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread INADA Naoki

INADA Naoki  added the comment:

$ ./python-gc -c 'import asyncio,sys; sys._debugmallocstats()'

master:

# bytes in allocated blocks=4,011,368
# bytes in available blocks=  136,640
50 unused pools * 4096 bytes   =  204,800
# bytes lost to pool headers   =   49,824
# bytes lost to quantization   =   53,816
# bytes lost to arena alignment=0
Total  =4,456,448

patched:

# bytes in allocated blocks=3,852,432
# bytes in available blocks=  132,664
27 unused pools * 4096 bytes   =  110,592
# bytes lost to pool headers   =   47,856
# bytes lost to quantization   =   50,760
# bytes lost to arena alignment=0
Total  =4,194,304

--

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Interesting.  Do you have any comparisons on memory footprint too?

--

___
Python tracker 

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



[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends

2018-05-22 Thread GranPrego

New submission from GranPrego :

On windows 7 / 10 I'm using subprocess to launch a dos cmdline executable and 
returning the results, which is all working fine.
However, each time I make a call, the Python handle count is gradually 
increasing, jumping up , back a few, then jumping up and so on.

All the handles are released when the script exits, but quite often python just 
hangs after a few hours.  If I use process explorer to investigate I can see 
that python has an increasing number of Thread handles, even though I can see 
the process being called and cleanly exiting.

Unfortunately I'm stuck with the dos executable and it's always a one shot of 
sending it a single command each time and the script calls it a lot. The 
executable is just taking a string cmdline and returning a couple of lines of 
text and then exiting.  It only runs for a couple of seconds at most.

I've tried two variants of calling the process, I was hoping that the with 
variant would clean up, but there is no difference.

Each handle object that gets left behind has a single reference and a non paged 
quota of 1192, 0 paged.

The script is long running and I've seen the handle count reach 46K.


result = ""
with Popen ([fcptool, parameters],  stdout=PIPE, universal_newlines=True, 
bufsize=1) as process:
for line in process.stdout:
result = result + line

return result
or 
p = subprocess.run([fcptool, parameters], stdout=subprocess.PIPE,  
stderr=subprocess.STDOUT, universal_newlines=True, shell=True).stdout


return p

I can reproduce this on 3 different machines, 2 windows 7 and one windows 10, 
all Python 3.6.   I can't see a way around this at the moment and as far as I 
can tell, I'm using the call to subprocess correctly.

--
components: Interpreter Core, Windows
messages: 317296
nosy: GranPrego, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Subprocess Thread handles  grow with each call and aren't released until 
script ends
type: resource usage
versions: Python 3.6

___
Python tracker 

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



[issue33238] AssertionError on await of Future returned by asyncio.wrap_future

2018-05-22 Thread Jason Haydaman

Change by Jason Haydaman :


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

___
Python tracker 

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



[issue33597] Compact PyGC_Head

2018-05-22 Thread INADA Naoki

INADA Naoki  added the comment:

$ ./python -m perf compare_to master.json twogc.json -G  --min-speed=2
Slower (3):
- scimark_monte_carlo: 268 ms +- 9 ms -> 278 ms +- 8 ms: 1.04x slower (+4%)
- fannkuch: 1.03 sec +- 0.02 sec -> 1.06 sec +- 0.02 sec: 1.03x slower (+3%)
- spectral_norm: 285 ms +- 9 ms -> 291 ms +- 6 ms: 1.02x slower (+2%)

Faster (13):
- unpickle_pure_python: 980 us +- 13 us -> 886 us +- 11 us: 1.11x faster (-10%)
- pickle_dict: 71.9 us +- 6.8 us -> 67.2 us +- 0.4 us: 1.07x faster (-7%)
- mako: 40.5 ms +- 1.1 ms -> 38.7 ms +- 0.4 ms: 1.05x faster (-5%)
- scimark_lu: 396 ms +- 18 ms -> 381 ms +- 16 ms: 1.04x faster (-4%)
- genshi_text: 89.3 ms +- 1.2 ms -> 86.3 ms +- 1.2 ms: 1.03x faster (-3%)
- xml_etree_generate: 270 ms +- 5 ms -> 262 ms +- 5 ms: 1.03x faster (-3%)
- regex_dna: 286 ms +- 1 ms -> 279 ms +- 1 ms: 1.03x faster (-3%)
- scimark_sor: 511 ms +- 6 ms -> 497 ms +- 10 ms: 1.03x faster (-3%)
- xml_etree_iterparse: 220 ms +- 6 ms -> 214 ms +- 5 ms: 1.03x faster (-3%)
- xml_etree_process: 231 ms +- 4 ms -> 225 ms +- 4 ms: 1.02x faster (-2%)
- genshi_xml: 191 ms +- 2 ms -> 187 ms +- 2 ms: 1.02x faster (-2%)
- unpack_sequence: 131 ns +- 2 ns -> 129 ns +- 2 ns: 1.02x faster (-2%)
- richards: 180 ms +- 4 ms -> 176 ms +- 2 ms: 1.02x faster (-2%)

Benchmark hidden because not significant (44)

--

___
Python tracker 

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



[issue33601] [EASY DOC] Py_UTF8Mode is not documented

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

If there are reasons of including it in the limited API, it should be 
documented.

--

___
Python tracker 

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



[issue33602] Remove set and queue references from Data Types

2018-05-22 Thread Andrés Delfino

Change by Andrés Delfino :


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

___
Python tracker 

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



[issue33602] Remove set and queue references from Data Types

2018-05-22 Thread Andrés Delfino

New submission from Andrés Delfino :

Data Types mentions sets (which are now built-in) and synchronized queues (now 
mentioned in Concurrent Execution). I'm proposing fixing this.

PR also adds mention to bytearray.

--
assignee: docs@python
components: Documentation
messages: 317293
nosy: adelfino, docs@python
priority: normal
severity: normal
status: open
title: Remove set and queue references from Data Types
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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



[issue33601] [EASY DOC] Py_UTF8Mode is not documented

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

I wasn't sure if I should document it, but after talking with Serhiy on IRC, I 
now agree that the new variable should be documented.

It should be documented at:
https://docs.python.org/dev/c-api/init.html#global-configuration-variables

--
keywords: +easy
title: Py_UTF8Mode is not documented -> [EASY DOC] Py_UTF8Mode is not documented

___
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

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

> But! I suppose we could fix the bug only for platforms with 
> PTHREAD_KEY_T_IS_COMPATIBLE_WITH_INT.

Yes, this is my proposal.

>> I propose to cast pthread_key_create() result to int, but only define 
>> PyThread_create_key() in Python/thread_pthread.h if 
>> PTHREAD_KEY_T_IS_COMPATIBLE_WITH_INT is defined.

> I don't think that's a good idea. Changing API, even for platforms that 
> aren't officially supported, sounds very harsh this late in the release cycle.

Which API change? I don't propose to modify the existing public C API "int 
PyThread_create_key(void)". I only propose to change it's implementation to the 
native pthread API when PTHREAD_KEY_T_IS_COMPATIBLE_WITH_INT is defined.

--

___
Python tracker 

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



[issue28240] Enhance the timeit module: display average +- std dev instead of minimum

2018-05-22 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

Yes, it was my thought. But seems you are right, it is easier to use Python as 
a programming language. In the past I used the CLI because the programming 
interface didn't supported autoranging.

Although I would change the human-readable output to

raw times (msec): 310 313 308 303 304

But it may be too later for 3.7.

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



[issue33565] strange tracemalloc results

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

A memory leak is when each iteration adds a fixed number of bytes of the 
memory: I'm talking about tracemalloc.get_traced_memory()[0] value. For 
example, if you compare the total traced memory between your iteration 30 and 
iteration 20, you get a value 10N. If you compare iteration 100 and 20, I would 
expect the value 80N. Is it the case?

You can get the number of allocated bytes from a snapshot using:

>>> sum(trace.size for trace in snapshot.traces)
2620350

--

___
Python tracker 

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



[issue33197] Confusing error message when constructing invalid inspect.Parameters

2018-05-22 Thread Dong-hee Na

Dong-hee Na  added the comment:

Can I get a code review for PR 6636?

--

___
Python tracker 

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



[issue33470] Changes from GH-1638 (GH-3575, bpo-28411) are not documented in Porting to Python 3.7

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

> Also, the actual removal of the "modules" field was reverted.

Oh... I didn't understand that part :-) Ok. In this case it's fine to close 
this documentation issue. Nothing should be documented for 3.7 ;-)

--

___
Python tracker 

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



[issue33601] Py_UTF8Mode is not documented

2018-05-22 Thread Serhiy Storchaka

New submission from Serhiy Storchaka :

Py_UTF8Mode was added to the limited API in 3.7, but it is not documented 
anywhere.

--
assignee: docs@python
components: Documentation
messages: 317286
nosy: docs@python, ncoghlan, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Py_UTF8Mode is not documented
versions: Python 3.7, Python 3.8

___
Python tracker 

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



[issue23860] Windows: Failure to check return value from lseek() in Modules/mmapmodule.c

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

Oh right, PR 7017 does that: it removes the lseek() call ;-)

--

___
Python tracker 

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



[issue23860] Windows: Failure to check return value from lseek() in Modules/mmapmodule.c

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

"At the moment, I'm not sure if it's needed or not, but if it's only an
issue with XP, then it might not be worth fixing...:)"

If the workaround is no longer needed, the lseek() call should be removed.

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
title: Failure to check return value from lseek() in Modules/mmapmodule.c -> 
Windows: Failure to check return value from lseek() in Modules/mmapmodule.c

___
Python tracker 

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



[issue28167] remove platform.linux_distribution()

2018-05-22 Thread STINNER Victor

STINNER Victor  added the comment:

FYI I created bpo-33600: "[EASY DOC] Python 2: document that 
platform.linux_distribution() has been removed".

--

___
Python tracker 

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



  1   2   >