[issue24665] CJK support for textwrap

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Add functions to get the width in columns of a character, 
textwrap.wrap: add control for fonts with different character widths

___
Python tracker 

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

[issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket

[Martin Panter]

Martin Panter added the comment:

Without more information about what the relevant code is and why you think the 
line number is wrong, my best guess is you may not realize how the 
ResourceWarning is emitted. It happens when the garbage collector runs and 
destroys the socket object, which happens sometime after the last reference to 
the socket has been deleted. So the line number can be rather arbitrary, 
especially if it was a reference cycle that triggered the garbage collector.

If you are having trouble tracking down what socket is involved, the new 
“python -X tracemalloc=” option 
 may help. It saves stack 
traces when objects are created.

--
nosy: +martin.panter
stage:  -> test needed

___
Python tracker 

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

[issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line

[Eryk Sun]

Eryk Sun added the comment:

For the tokenizer, a blank line is "[a] logical line that contains only spaces, 
tabs, formfeeds and possibly a comment" [1]. A blank line is normally ignored, 
except in the REPL an entirely blank line (i.e. no whitespace or comment) is 
used to end a multi-line statement.

This behavior is coded in Parser/tokenizer.c in tok_get(). After removing 
leading whitespace to get the indentation level, it decides whether the line 
should be ignored as blank as follows:

if (c == '#' || c == '\n') {
/* Lines with only whitespace and/or comments
   shouldn't affect the indentation and are
   not passed to the parser as NEWLINE tokens,
   except *totally* empty lines in interactive
   mode, which signal the end of a command group. */
if (col == 0 && c == '\n' && tok->prompt != NULL) {
blankline = 0; /* Let it through */
}
else {
blankline = 1; /* Ignore completely */
}
/* We can't jump back right here since we still
   may need to skip to the end of a comment */
}

The tokenizer switches to the ps2 prompt unconditionally, even if the first 
line was ignored as a blank line. One can argue that this behavior is outside 
of the norm for a shell or REPL. For example, bash doesn't switch to its PS2 
prompt after ignoring an initial blank line. On the other hand, the interpreter 
is correctly conveying that it's still tokenizing the input; it hasn't compiled 
or executed any code.

[1]: https://docs.python.org/3/reference/lexical_analysis.html#blank-lines

--
nosy: +eryksun

___
Python tracker 

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

[issue24665] CJK support for textwrap

[INADA Naoki]

INADA Naoki added the comment:

FYI, I had implemented textwrap respects EAW in Bazaar project.
See here.
http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5874

--

___
Python tracker 

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

[issue24665] CJK support for textwrap

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Some CJK character are marked as "ambiguous width". Seems in this patch 
ambiguous characters are assumed as narrow. Maybe it's better to document it?

--
nosy: +Chi Hsuan Yen

___
Python tracker 

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

[issue24665] CJK support for textwrap

[INADA Naoki]

INADA Naoki added the comment:

Sorry, I'm not unicode expert.

Important usage of textwrap is printing in terminal.
So I think we should learn from software relating terminal.

tmux uses utf8proc.  utf8proc calculates display width by script at here.
https://github.com/JuliaLang/utf8proc/tree/master/data

--
nosy: +inada.naoki

___
Python tracker 

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

[issue29557] binhex documentation claims unknown bug

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
components: +macOS
nosy: +ned.deily, ronaldoussoren

___
Python tracker 

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

[issue29557] binhex documentation claims unknown bug

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think this should be read in the context of previous lines:

If you code or decode textfiles on non-Macintosh platforms they will still 
use
the old Macintosh newline convention (carriage-return as end of line).

And may be related to the in-code comment:

#  Do translation on non-mac systems

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks, Thomas :) I'll let you close your own PR on GitHub.

--

___
Python tracker 

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

[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque

[Thomas Caswell]

Thomas Caswell added the comment:

I am not optimistic about the speed at which my employer will get this
sorted out.

better to just fix it and drop my commit!

On Tue, Feb 14, 2017, 23:43 Mariatta Wijaya  wrote:

Mariatta Wijaya added the comment:

Thanks, Raymond :) I prepared the pull requests for 3.5, 3.6, and master
branches.

Thomas, you mentioned about needing to go over CLA with your employer in
your PR.

Not sure if you have any update on that? If your CLA is approved, I can
merge and cherry-pick your PR instead.

--
stage:  -> patch review

___
Python tracker 

___

--

___
Python tracker 

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

[issue28929] Provide a link from documentation back to its source file

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +75

___
Python tracker 

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

[issue29521] Minor warning messages when compiling documentation

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +73

___
Python tracker 

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

[issue29521] Minor warning messages when compiling documentation

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +74

___
Python tracker 

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

[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks, Raymond :) I prepared the pull requests for 3.5, 3.6, and master 
branches.

Thomas, you mentioned about needing to go over CLA with your employer in your 
PR.

Not sure if you have any update on that? If your CLA is approved, I can merge 
and cherry-pick your PR instead.

--
stage:  -> patch review

___
Python tracker 

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

[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +72

___
Python tracker 

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

[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +71

___
Python tracker 

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

[issue29481] 3.6.0 doc describes 3.6.1 feature - typing.Deque

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +70

___
Python tracker 

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

[issue29536] test_hashlib failure on Ubuntu 16.04

[Xiang Zhang]

Xiang Zhang added the comment:

I am using 16.10 but I can't reproduce the failures. Sachin can you reliably 
reproduce the failures? And one thing interesting is that all the failed test 
cases need the network source to be enabled but your command doesn't do that, 
it's better to use ./python -m test -uall -v test_hashlib.

--
nosy: +xiang.zhang

___
Python tracker 

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

[issue29521] Minor warning messages when compiling documentation

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +69

___
Python tracker 

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

[issue29563] Update Devguide about building documentation.

[Zachary Ware]

Zachary Ware added the comment:

I'd suggest replacing as much as possible in the devguide with a link to 
Doc/README.rst (or Doc/README.txt, if that's what it still is).  Other 
improvements should be made in the README.

--
nosy: +zach.ware

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[David Ford (FirefighterBlu3)]

David Ford (FirefighterBlu3) added the comment:

Arch Linux (updated ~weekly but not often rebooted) on a Digital Ocean droplet.

Kernel 4.5.1-1-ARCH, x86_64, OpenSSL 1.0.2j, Python 3.6.0

--

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[David Ford (FirefighterBlu3)]

David Ford (FirefighterBlu3) added the comment:

my SNI callback is a function that chooses which SSL certificate to load and 
summarized is:

  6 def sni_callback(sock, servername, context):
[...]
 44 # load a specific crt/key
 45 store = crtstore[servername]
 46 
 47 context.load_cert_chain( certfile = store['certfile'],
 48  keyfile  = store['keyfile'],
 49  password = store['password'] )

--

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[David Ford (FirefighterBlu3)]

David Ford (FirefighterBlu3) added the comment:

in process of creating a non-stripped python install. the default Arch Linux 
PKGBUILD uses xvfb-run at the end of the build process which is crashing.

--

___
Python tracker 

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

[issue29529] Backport Travis configuration

[INADA Naoki]

Changes by INADA Naoki :


--
pull_requests: +68

___
Python tracker 

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

[issue29564] ResourceWarning tracking is attaching incorrect file:position to unclosed socket

[David Ford (FirefighterBlu3)]

New submission from David Ford (FirefighterBlu3):

the following warning is incorrectly reported as initiated at 
psycopg2/extras.py:314, it actually occurs inside the Twilio python module.

/usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning: 
unclosed 
  ts = super(NamedTupleCursor, self).fetchall()
namedtuple_Record:19: ResourceWarning: unclosed 



This is the snippet of my code which makes the Twilio API call over https 
(noted by the >>> line).

# get failed/undelivered
with (yield from 
self.aiopg_pool.cursor(cursor_factory=psycopg2.extras.NamedTupleCursor)) as c:
yield from c.execute(stmt_bad, (id,))
rows = yield from c.fetchall()

# make calls to twilio and fetch failure reasons
for r in rows:
>>> msg = self._twilio.messages.get(r.delivery_id)
errors[r.delivery_id] = r.recipient, msg.error_code, 
msg.error_message


my tool uses crossbar.io's python-autobahn asyncio classes which do not use 
threading to my knowledge. psycopg2/pool.py does use threading. python-twilio 
does not use threading either.

--
messages: 287810
nosy: David Ford (FirefighterBlu3)
priority: normal
severity: normal
status: open
title: ResourceWarning tracking is attaching incorrect file:position to 
unclosed socket
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

[issue29563] Update Devguide about building documentation.

[Jim DeLaHunt]

New submission from Jim DeLaHunt:

The Devguide section 7.5.1 "Building the documentation" / "Using make / 
make.bat" is out of date.  The document lists 10 documentation targets for 
`make`. The Doc/Makefile lists 17. 

One important omission is `make check`, which looks for errors in 
reStructuredText syntax, using `rstlint.py`. It's important for contributors to 
know about and to run `make check`, because with the move to GitHub, the 
project is running make check after pulling in new code.  If contributors 
haven't cleaned up their submissions, the build fails.

I suggest that the following improvements be made:

1. rewrite the bullet list "Available make targets are:" in 7.5.1 
https://cpython-devguide.readthedocs.io/documenting.html#using-make-make-bat to 
match the list of targets in Doc/Makefile:21-38.

2. add a comment that `make help` will give the most up-to-date list of targets 
from the makefile, which might be better than the list in the Devguide.

3. add `make help` to both Doc/Makefile:21-38 and Devguide 7.5.1.

4. add to Devguide 6.3. "Helping with the Developer’s Guide" an instruction to 
run `make check` before submitting a pull request to the Devguide.

--
assignee: docs@python
components: Documentation
messages: 287808
nosy: JDLH, docs@python
priority: normal
severity: normal
status: open
title: Update Devguide about building documentation.
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue18779] Misleading documentations and comments in regular expression HOWTO

[A.M. Kuchling]

A.M. Kuchling added the comment:

Unfortunately making the sentences pedantically correct also makes them 
ungainly, and I think people generally assume that underscores are treated as a 
letter.

--
nosy: +akuchling
resolution:  -> wont fix
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

[issue29562] test_getgroups of test_posix fails (on OS X 10.10)

[Jim DeLaHunt]

Jim DeLaHunt added the comment:

I have pushed a branch for this issue to my cpython fork:

https://github.com/JDLH/cpython/tree/bpo-29562_failing_test_getgroups_on_os_x

It modifies test_getgroups in test_posix.py to give better diagnostics in the 
event of a test failure. It says specifically which groups were in id -G, and 
posix.getgroups(), but not in the other.

% ./python.exe -m unittest -v test.test_posix.PosixTester.test_getgroups 
test_getgroups (test.test_posix.PosixTester) ... FAIL

==
FAIL: test_getgroups (test.test_posix.PosixTester)
--
Traceback (most recent call last):
  File "/Users/jdlh/workspace/cpython/Lib/test/test_posix.py", line 841, in 
test_getgroups
self.assertEqual(len(symdiff), 0, msg)
AssertionError: 2 != 0 : id -G and posix.groups() should have zero difference.
Groups in id -G but not posix.groups(): [(701, 'com.apple.sharepoint.group.1'), 
(398, 'com.apple.access_screensharing')]
Groups in posix.groups() but not id -G: []
(Effective GID (20) was disregarded.)

--
Ran 1 test in 0.020s

I don't think this branch is ready yet to submit to the main codebase, but it 
may help people diagnose the issue.

--

___
Python tracker 

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

[issue29562] test_getgroups of test_posix fails (on OS X 10.10)

[Jim DeLaHunt]

New submission from Jim DeLaHunt:

When I run test.test_posix.PosixTester.test_getgroups on my Mac OS X system, it 
fails:

% ./python.exe -m unittest -v test.test_posix.PosixTester.test_getgroups
test_getgroups (test.test_posix.PosixTester) ... FAIL

==
FAIL: test_getgroups (test.test_posix.PosixTester)
--
Traceback (most recent call last):
  File "/Users/jdlh/workspace/cpython/Lib/test/test_posix.py", line 824, in 
test_getgroups
self.assertTrue(not symdiff or symdiff == {posix.getegid()})
AssertionError: False is not true

--
Ran 1 test in 0.013s

FAILED (failures=1)


Details of my system:
% sw_vers
ProductName:Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F2109

% id -G
20 507 12 61 80 
98 399 33 100 
204 395 398 
701
% id -G -n
staff xampp everyone localaccounts admin 
_lpadmin com.apple.access_ssh _appstore _lpoperator 
_developer com.apple.access_ftp com.apple.access_screensharing 
com.apple.sharepoint.group.1
# I wrapped these lines similarly, to make the correspondence clearer

% ./python.exe -c 'import grp,os; g={i: (n, p, i, mem) for (n, p, i, mem) in 
grp.getgrall()}; print(sorted([(i, g[i][0]) for i in os.getgroups()]) )'
[(12, 'everyone'), (20, 'staff'), (33, '_appstore'), (61, 'localaccounts'), 
(80, 'admin'), (98, '_lpadmin'), (100, '_lpoperator'), (204, '_developer'), 
(395, 'com.apple.access_ftp'), (399, 'com.apple.access_ssh'), (507, 'xampp')]

So the difference, which triggers the test failure, is that id -G is returning 
groups (701, 'com.apple.sharepoint.group.1'), and (398, 
'com.apple.access_screensharing'), while posix.getgroups() is not.  I do not 
yet understand why.

Others say this test works on their OS X 10.10 system, so maybe it's triggered 
by something in my environment. 

Also: python3.6 from MacPorts, and python2.7 from MacPorts, return the same set 
of groupids as does the dev build of python3.7.

This bug affects the same test, and the same posix.getgroups() call, as 
http://bugs.python.org/issue17557 "test_getgroups of test_posix can fail on OS 
X 10.8 if more than 16 groups" (2013-2014, closed).  But I think it is a 
different problem: issue17557 is related to how posix.getgroups() deals with 
large numbers of groups, and it is fixed.

I would appreciate help in getting this test to pass. Maybe my environment is 
wrong, in which case I should fix my environment. But maybe the cpython code is 
sensitive to some detail of my environment, in which case perhaps I should fix 
the cpython code.

--
components: Tests
messages: 287806
nosy: JDLH
priority: normal
severity: normal
status: open
title: test_getgroups of test_posix fails (on OS X 10.10)
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue29531] Update Doc/README.txt to README.rst

[Roger Sachan]

Changes by Roger Sachan :


--
pull_requests: +67

___
Python tracker 

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

[issue29531] Update Doc/README.txt to README.rst

[Roger Sachan]

Changes by Roger Sachan :


--
pull_requests:  -31

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Matthias Bussonnier]

Matthias Bussonnier added the comment:

See https://github.com/python/cpython/pull/103 that implements Barry's proposed 
format.

--

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Matthias Bussonnier]

Changes by Matthias Bussonnier :


--
pull_requests: +66

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Matthias Bussonnier]

Matthias Bussonnier added the comment:

I'm unsure I understand changing only the default __str__() method. You will 
anyway have to format the message differently depending on whether you raise 
from a from-import or a from-import-* or any other locations. 

AFAIU you "just" need the following 

  -PyErr_SetImportError(PyUnicode_FromFormat("cannot import name %R", 
name), pkgname, pkgpath);
  +PyErr_SetImportError(
  +PyUnicode_FromFormat("cannot import name %R from %R (%S)",
  +name, pkgname, pkgpath),
  +pkgname, pkgpath);

To use Barry format (though keeping quotes around identifiers to match current 
behavior).
(And similar if path is null). 

I'm unsure if you meant to provide a set of "format-template" to ImportError 
that are guarantied to be called with format(name=..., path=...) but I doubt it.

--

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Brett Cannon]

Brett Cannon added the comment:

Thanks to Matthias' PR the information is all there in the exception, but the 
message has not been changed. One idea for this -- depending on how much C code 
you want to write -- is to provide a default message for __str__() that changes 
depending on whether 'path' and/or 'name' are set. Then you can just set the 
attributes in the __init__() and have __str__() take care of providing a common 
message format. Another option is to do all of that in the __init__() so that 
BaseException.args continues to have the full error message (but that is added 
overhead if the __str__() is never taken of the exception). I also have no clue 
how much C code this would take :) (This is all why I have toyed with the idea 
of re-implementing the exceptions in Python for easier customization.)

--

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Brett Cannon]

Brett Cannon added the comment:


New changeset bc4bed440504597cac47d0a215ee094bfa99ba7e by Brett Cannon in 
branch 'master':
bpo-29546: Set 'path' on ImportError for ``from ... import ...`` (GH-91)
https://github.com/python/cpython/commit/bc4bed440504597cac47d0a215ee094bfa99ba7e


--

___
Python tracker 

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

[issue29557] binhex documentation claims unknown bug

[Berker Peksag]

Changes by Berker Peksag :


--
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5, Python 3.6

___
Python tracker 

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

[issue29557] binhex documentation claims unknown bug

[Berker Peksag]

Berker Peksag added the comment:


New changeset 6de2b7817fa9403e81dc38f13f3690f0bbf3d064 by Berker Peksag in 
branch 'master':
bpo-29557: Remove ambiguous line in binhex docs (#90)
https://github.com/python/cpython/commit/6de2b7817fa9403e81dc38f13f3690f0bbf3d064


--
nosy: +berker.peksag

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Matthias Bussonnier]

Changes by Matthias Bussonnier :


--
pull_requests: +62

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Matthias Bussonnier]

Changes by Matthias Bussonnier :


--
pull_requests: +62, 63, 64

___
Python tracker 

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

[issue29546] A more helpful ImportError message

[Matthias Bussonnier]

Changes by Matthias Bussonnier :


--
pull_requests: +62, 63

___
Python tracker 

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

[issue29558] Provide run_until_complete inside loop

[Martin Panter]

Martin Panter added the comment:

Sounds related to Issue 22239

--
nosy: +martin.panter

___
Python tracker 

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

[issue29561] Interactive mode gives sys.ps2 not sys.ps1 after comment-only line

[Jim DeLaHunt]

New submission from Jim DeLaHunt:

When you run the Python interpreter in interactive mode, get a sys.ps1 prompt 
(`...`), and type a comment-only or white-space-only line, the interpreter 
responds with a sys.ps2 prompt (`...`), instead of a sys.ps1 prompt. This seems 
wrong.

For example: 

% ./python.exe 
Python 3.7.0a0 (default, Feb 13 2017, 16:27:07) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> # comment-only<<-- line A
...   <<-- line B
>>>   <<-- line C 
>>>   <<-- line D 

Line A is a comment-only line entered by the user. The interpreter responds 
with the sys.ps2 prompt (`...`), in line B. Line C is a null line (user enters 
only the Enter key, nothing else). The interpreter responds with a sys.ps1 
prompt (`...`).  

If user enters a white-space-only line at a sys.ps1 prompt, the interpreter 
responds the same as if it were a comment-only line, with a sys.ps2 prompt 
(line B).

The expected expected interpreter behaviour in response to a  comment-only line 
or a white-space-only line, not in the midst of a compound statement, is that 
it be the same as to a null line, with a sys.ps1 prompt. 

In the context of a compound statement, the expected interpreter behaviour is 
that a comment-only line or a white-space-only line continue the compound 
statement. Entering a null line in a compound statement ends the compound 
statement.

Another way to phrase it: the expected interpreter behaviour is that a 
comment-only line or white-space-only line not change the interpreter prompt: 
if it was sys.ps1, it remains so; if it was sys.ps2, it remains so.

I have reproduced this behaviour on my build of cpython 3.7.a0, python 3.6 from 
MacPorts, python 2.7 from MacPorts, all on Mac OS X.  I see the same behaviour 
in the interactive shell at python.org/shell .

This makes me suspect that the Python design says my expectations are wrong. In 
that case, the current behaviour certainly is surprising. It should be 
documented.  I haven't found such documentation yet.

--
components: Interpreter Core
messages: 287799
nosy: JDLH
priority: normal
severity: normal
status: open
title: Interactive mode gives sys.ps2 not sys.ps1 after comment-only line
type: behavior
versions: Python 2.7, 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

[issue28695] Add SSL_CTX_set_client_cert_engine

[Gennady Kovalev]

Gennady Kovalev added the comment:

Ok, thank you.

--

___
Python tracker 

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

[issue28695] Add SSL_CTX_set_client_cert_engine

[Christian Heimes]

Christian Heimes added the comment:

I haven't started to design the new feature yet. Since it is going to be a new 
feature and feature freeze of 3.7 is 2018-01-29, I'm going to start working on 
new stuff around in April or May for PyCon.

--

___
Python tracker 

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

[issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue28695] Add SSL_CTX_set_client_cert_engine

[Gennady Kovalev]

Gennady Kovalev added the comment:

Is there any news?

--

___
Python tracker 

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

[issue11165] Document PyEval_Call* functions

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes

[Pauli Virtanen]

Pauli Virtanen added the comment:

Converted patch to Github PR + some cleanup.

--
pull_requests: +61

___
Python tracker 

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

[issue29560] Turtle graphics fill behavior differs between versions

[John Simmons]

New submission from John Simmons:

When I run the demo program on the library 24.1 documentation page to draw the 
star, it colors the entire star yellow, not just the parts that are show yellow 
on the page.  This appears to be a behavior change.  This is running on a 
Windows 7 or 10 machine with Python 3.2, 3.5, or 3.6.

I have not tried this program at home, but when I run a similar program that 
draws and then fills 10 overlapping circles, my Linux Mint 17.3 computer at 
home, running IDLE in Python 3.4, fills the "interior" points inside and odd 
number of circles but does not fill the "exterior" points inside an even number 
of circles.  This appears to be the behavior shown on documentation page 24.1.  
I would like to know what is intended to be the correct behavior and why the 
implementations differ.

--
components: Tkinter
messages: 287794
nosy: John Simmons
priority: normal
severity: normal
status: open
title: Turtle graphics fill behavior differs between versions
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Mark Dickinson]

Mark Dickinson added the comment:

All done. Closing. (In theory, as a bugfix, this could be backported to 3.5 and 
3.6. In practice, I doubt it's worth the effort.)

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

[issue29534] _decimal difference with _pydecimal

[Mark Dickinson]

Mark Dickinson added the comment:


New changeset 996c3874fdbc91d29f0a06b37043f62cf4ead6cb by GitHub in branch 
'master':
Issue #29534: move Misc/NEWS entry to correct section; add Misc/ACS entry for 
Andrew Nester. (#99)
https://github.com/python/cpython/commit/996c3874fdbc91d29f0a06b37043f62cf4ead6cb


--

___
Python tracker 

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

[issue6143] IDLE - an extension to clear the shell window

[Terry J. Reedy]

Terry J. Reedy added the comment:

Alwx, please do not change the headers.  IDLE menu commands cannot be invoked 
from a program.

--
type: resource usage -> behavior
versions: +Python 3.6, Python 3.7 -Python 2.7

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Mark Dickinson]

Mark Dickinson added the comment:

PR to fix the Misc/NEWS entry: https://github.com/python/cpython/pull/99

--

___
Python tracker 

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

[issue29559] Detect mouse over lines on canvas while mouse button is down

[Ted Shaneyfelt]

New submission from Ted Shaneyfelt:

There way mouse captures are done, mouse-over events seem to be disabled while 
dragging. 

This makes it difficult to provides hints as feedback, and more complicated 
than it should be to detect when dropping over a particular line object. 

Tk may not directly support it, but is there any way of getting into its guts 
to provide an option to re-enable mouse-over events while dragging? Or even 
providing a tuple with the pending mouse-overs upon release? or perhaps even 
simulate a mouse-up-mouse-down sequence to allow the events to propagate 
through and consume the noise within tkinter? Or even detect that there is a 
pending mouseover waiting for the mouseup event and delivering it along with 
the mouseup or notifying within the event that there is one pending?

--
components: Tkinter
messages: 287789
nosy: Ted Shaneyfelt2
priority: normal
severity: normal
status: open
title: Detect mouse over lines on canvas while mouse button is down
type: enhancement
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

[issue29534] _decimal difference with _pydecimal

[Mark Dickinson]

Mark Dickinson added the comment:

PR merged; thank you!

Unfortunately, just after I merged it I noticed that the Misc/NEWS entry was in 
the wrong section. I'll make a new PR to fix that, and close this issue once 
it's done.

--

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Mark Dickinson]

Mark Dickinson added the comment:


New changeset 6d1dece06d13a7d40637e07b2c79f34aab368766 by Mark Dickinson in 
branch 'master':
Fixed #29534 - _decimal difference with _pydecimal (#65)
https://github.com/python/cpython/commit/6d1dece06d13a7d40637e07b2c79f34aab368766


--

___
Python tracker 

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

[issue29540] Add compact=True flag to json.dump/dumps

[Brett Cannon]

Brett Cannon added the comment:

I'm a little confused as the PR proposes a COMPACT constant for the module but 
the issue proposes a new compact argument. Which are we actively considering?

--

___
Python tracker 

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

[issue19675] Pool dies with excessive workers, but does not cleanup

[Dustin Oprea]

Dustin Oprea added the comment:

I don't think this can be tested. Throwing exceptions in the remote process 
causes exceptions that can't be caught in the same way (when the initializer 
fails the pool just attempts to recreate the process over and over) and I don't 
think it'd be acceptable to try to spawn too many processes in order to induce 
the original problem. There's not a lot of surface area to what we've doing 
here. We can't simulate failures any other way.

Can I get an agreement on this from someone?

--
pull_requests: +60

___
Python tracker 

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

[issue29558] Provide run_until_complete inside loop

[Javier Domingo]

New submission from Javier Domingo:

The current architecture of asyncio makes it really hard to combine both async 
and sync code.

When porting a Thread based application to asyncio, the first step is usually 
to start merging threads to the main loop, by using `run_coroutine_threadsafe`. 
This works well and allows to use a single ioloop from different threads.

There is another step, that usually involves the patching of libraries to work 
in an async way. One will typically patch the IO calls to be asyncio, and using 
`run_until_complete` proves useful in these situations.

However, at the moment it's not possible to `run_until_complete` from an 
ioloop. The possibility to be able to patch sync libraries to run in asyncio is 
something that would help a lot the migration.

This functionality would basically provide a way to continue running the ioloop 
until the future is resolved.

Sync code -> async code -> Sync code -> Async code

If you know how to have this without spawning an executor, that would be good 
too, in such case I would rather ask for documentation on how to do it =)

--
components: asyncio
messages: 287784
nosy: gvanrossum, txomon, yselivanov
priority: normal
severity: normal
status: open
title: Provide run_until_complete inside loop
type: enhancement
versions: 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

[issue29556] Remove unused #include

[Chi Hsuan Yen]

Changes by Chi Hsuan Yen :


--
title: Remove an unused #include from bltinmodule.c -> Remove unused #include 


___
Python tracker 

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

[issue29387] Tabs vs spaces FAQ out of date

[Mariatta Wijaya]

Mariatta Wijaya added the comment:


New changeset 38c8354f3204441f6c6bd22213b449d2d8954fcc by GitHub in branch 
'3.5':
bpo-29521 Fix two minor documentation build warnings (#41) (#84)
https://github.com/python/cpython/commit/38c8354f3204441f6c6bd22213b449d2d8954fcc


--
nosy: +Mariatta

___
Python tracker 

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

[issue29553] Argparser does not display closing parentheses in nested mutex groups

[Christoph Stahl]

Changes by Christoph Stahl :


--
type:  -> behavior

___
Python tracker 

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

[issue29556] Remove an unused #include from bltinmodule.c

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Hmmm, seems there are more redundant #include ; let me check one by 
one

--

___
Python tracker 

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

[issue29557] binhex documentation claims unknown bug

[David Wilemski]

New submission from David Wilemski:

The binhex documentation has a line in it that says "As of this writing, 
hexbin() appears to not work in all cases."

This is a bit ambiguous and there is no context for what the bug may be. It 
appears this line is from the first commit to the hexbin function's 
documentation in 1995 (https://hg.python.org/cpython/rev/3911d4a89ab0#l4.40) 
but the commit also has no information about what this bug may be. I also see 
no current open bugs for the binhex module that seem related.

In 2009, there was a patch for the hexbin function but I have no idea if this 
is the bug from the original documentation or if it was something else 
entirely: https://bugs.python.org/issue6369

Given this, I believe the line should be removed unless more details about the 
referenced buggy behavior can be found.

--
assignee: docs@python
components: Documentation
messages: 287781
nosy: David Wilemski, docs@python
priority: normal
pull_requests: 59
severity: normal
status: open
title: binhex documentation claims unknown bug
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

[issue29556] Remove an unused #include from bltinmodule.c

[Chi Hsuan Yen]

Changes by Chi Hsuan Yen :


--
pull_requests: +58

___
Python tracker 

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

[issue29556] Remove an unused #include from bltinmodule.c

[Chi Hsuan Yen]

New submission from Chi Hsuan Yen:

This #include is added in b744ba1d14c5487576c95d0311e357b707600b47 (issue8610) 
and later the use of CODESET is removed in 
d64e8a75e5138d5e5970f0c70995ae5cc377c421 (issue9642).

Found this in investigating issue29436

Add haypo as both commit is written by you

--
components: Build
messages: 287780
nosy: Chi Hsuan Yen, haypo
priority: normal
severity: normal
status: open
title: Remove an unused #include from bltinmodule.c
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue29555] Update Python Software Foundation Copyright Year

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +lemburg

___
Python tracker 

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

[issue29555] Update Python Software Foundation Copyright Year

[Senthil Kumaran]

New submission from Senthil Kumaran:

In the attached patch, I updated the copyright year to 2017 at places it was 
mentioned until 2016.

There was a suggestion that we remove the copyright line of Python Software 
Foundation from module headers since the code is already covered 1) by top 
level copyright mention, 2) The mention of copyright is inconsistent in 
modules, 3) will avoid unnecessary churn every year. 

This idea needs to be vetted by PSF Board and legal staff.

--
files: pr-4.diff
keywords: patch
messages: 287779
nosy: orsenthil
priority: normal
severity: normal
status: open
title: Update Python Software Foundation Copyright Year
versions: Python 2.7, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46638/pr-4.diff

___
Python tracker 

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

[issue29554] profile/pstat doc clariification

[Matthias Bussonnier]

New submission from Matthias Bussonnier:

profile .rst say:

> Each restriction is either an integer (to select a count of lines), or a 
> decimal fraction between 0.0 and 1.0 inclusive (to select a percentage of 
> lines), **or a regular expression**

Actually it accept a string that will be compiled to a regex.

Profile.py also mention:

> (i.e., in addition to the old -1, 0, 1, or 2)

Which is not really helpful, to newcomers to Python who do not know what these 
are meant to be. Either explaining (or removing if considered old behavior that 
should be stopped) seem to be better alternative.

See https://github.com/python/cpython/pull/88

--
assignee: docs@python
components: Documentation
messages: 287778
nosy: docs@python, mbussonn
priority: normal
severity: normal
status: open
title: profile/pstat doc clariification
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

[issue29548] deprecate PyEval_Call*() functions.

[INADA Naoki]

INADA Naoki added the comment:

I stopped deprecating PyEval_Call APIs, and removing it's usage in PR 75.

Summary of current pull requests:

PR 87 contains fix regression of PyEval_CallObjectWithKeywords for Python 3.6.

PR 75 is for master branch.  It contains fix same to PR 87. Additionally, 
PyEval_CallFunction and PyEval_CallMethod is now copy of PyObject_CallFunction 
and PyObject_CallMethod.  And comment about PyObject_Call preference is added.

--

___
Python tracker 

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

[issue29553] Argparser does not display closing parentheses in nested mutex groups

[Christoph Stahl]

New submission from Christoph Stahl:

When creating nested mutually exclusive groups, all closing brackets except one 
are omitted.

Example:
parser = ArgumentParser()
group = parser.add_mutually_exclusive_group()
group.add_argument('-a')
group.add_argument('-b')
group2 = group.add_mutually_exclusive_group()
group2.add_argument('-c')
group2.add_argument('-d')
group3 = group2.add_mutually_exclusive_group()
group3.add_argument('-e')
group3.add_argument('-f')

prints a usage line of:
usage: test.py [-h] [-a A | -b B | [-c C | -d D | [-e E | -f F]

it should print something like:
usage: test.py [-h] [-a A | -b B | [-c C | -d D | [-e E | -f F]]]

--
components: Library (Lib)
messages: 287776
nosy: christofsteel
priority: normal
severity: normal
status: open
title: Argparser does not display closing parentheses in nested mutex groups
versions: 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

[issue29548] deprecate PyEval_Call*() functions.

[STINNER Victor]

STINNER Victor added the comment:

> So they are part of stable ABI.  We can't remove them until Python 4.

Please just stop right now using "Python 4" as the starting point to
break -again- the Python world.

If you plan to remove the function, plan it right now with versions
like "in 2 cycles".

If the function is part of the stable ABI, we simply cannot remove it.
Since these functions are used outside CPython and they are part of
the stable ABI, I'm not sure anymore that there is any value to remove
them.

Maybe just document them and write "please don't use them", but don't
deprecate the functions.

--

___
Python tracker 

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

[issue29540] Add compact=True flag to json.dump/dumps

[STINNER Victor]

STINNER Victor added the comment:

"Add compact=True flag to json.dump/dumps"

Oh, fun, I implemented exactly this option in my perf project. Extract:

def dump(data, fp, compact):
kw = {}
if compact:
kw['separators'] = (',', ':')
else:
kw['indent'] = 4
json.dump(data, fp, sort_keys=True, **kw)

So I like the idea of moving the compact=True feature directly into the json 
module ;-)

(I don't propose to change the default to indent=4, that's a personal choice 
;-))

--
nosy: +haypo

___
Python tracker 

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

[issue29540] Add compact=True flag to json.dump/dumps

[Berker Peksag]

Berker Peksag added the comment:

I'm +1 on the idea. Currently, a user needs to find this information in a wall 
of text: "To get the most compact JSON representation, you should specify (',', 
':') to eliminate whitespace." It's easy to miss the lack of trailing space in 
(',', ':').

Perhaps the constant name could be changed to something more descriptive, but I 
don't have a better suggestion at the moment.

(Adding Brett since he also reviewed the PR.)

--
nosy: +berker.peksag, brett.cannon
stage:  -> patch review

___
Python tracker 

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

[issue29552] Issue in Dictionary fromkeys

[Prudvi Mangadu]

Prudvi Mangadu added the comment:

Thanks Martin , I will close it.

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

[issue29552] Issue in Dictionary fromkeys

[Martin Panter]

Martin Panter added the comment:

I suggest to close this as not a bug.

--
resolution:  -> not a bug

___
Python tracker 

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

[issue29552] Issue in Dictionary fromkeys

[Martin Panter]

Martin Panter added the comment:

This is similar to the problem of building a list by repeating one item: 
.

With dict.fromkeys(), the resulting dictionary maps each specified key object 
to the one and only value object (empty list) you passed to fromkeys(). If you 
look up one of the keys, it returns the list object. If you modify that object, 
all references to that object will see the update.

The difference with the dictionary comprehension workaround is that the 
interpreter executes the expressions “D_IP” and “[]” once for each iteration of 
“input”, resulting in a new empty list instance each iteration. But when you 
call fromkeys(), you pass a single object. The fromkeys() method just copies 
references; it does not create objects itself.

If the id() function returns the same identity, it means you have two 
references to the same underlying object instance. This is the same as checking 
“result['1'] is result['2']”.

--
nosy: +martin.panter

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[INADA Naoki]

INADA Naoki added the comment:

> I would suggest to deprecate PyEval_Call*() functions first only in the 
> documentation. In 3.8 or 3.9 add the Py_DEPRECATED attribute.


 doesn't excluded by PEP 384.
And these 3 functions and 1 macro is outside of "#ifndef Py_LIMITED_API" check.
So they are part of stable ABI.  We can't remove them until Python 4.
No reason to hurry up.

I'll remove Py_DEPRECATED for Python 3.7.

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Any idea of the popularity of the undocumented PyEval_xxx() functions?

You can just search code at GitHub.

I would suggest to deprecate PyEval_Call*() functions first only in the 
documentation. In 3.8 or 3.9 add the Py_DEPRECATED attribute.

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

PyEval_CallObject() was added at Jan 12 1995 (05360cd616ae). 
PyObject_CallObject(), PyObject_CallFunction() and PyObject_CallMethod() were 
added with Include/abstract.h at Jul 18 1995 (d5398acafa2c) and implemented in 
terms of PyEval_CallObject(). PyEval_CallObjectWithKeywords() was added few 
minutes later (0261bf5b3819). PyObject_Call() was added at Aug 02 2001 
(09df3254b49d) as a simple wrapper around tp_call. PyObject_CallFunction() and 
PyObject_CallMethod() were reimplemented in terms of PyObject_Call() at Aug 16 
2002 (255d1d3e66a3).

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 14.02.2017 11:16, STINNER Victor wrote:
> 
>> Please note that the two sets of APIs are not identical, e.g. you cannot 
>> simply replace PyEval_CallObject() with PyObject_Call(), since the former 
>> applies a few extra checks and defaults, which the latter doesn't.
> 
> IMHO these checks are too expensive at runtime for little benefit. If you 
> pass non-tuple to PyObject_Call(), Python immediately crash. You are 
> immediately noticied of the bug :-) I don't think that such bugs are common 
> enough to justify the overhead.

>From the design of the abstract API layer, it is rather
uncommon to have these not do extra checks to prevent segfaults.
They were originally designed to be safe and developer friendly.

OTOH, the PyEval_* APIs were designed to be fast, only for people
who know what they are doing and for interpreter internals.

Historically, this design approach appears to have been swapped
somewhere between Python 2.1 and 2.2 for the call APIs,
which is unfortunate.

So from a design perspective, it would be better to have the
abstract APIs again do proper checks and leave the low level,
"segfault protected" :-) call APIs around as PyEval_Call*()
or better yet: not make them public at all.

> Any idea of the popularity of the undocumented PyEval_xxx() functions? Are 
> they used by Cython for example? By a single random extension module in the 
> world?

Well, I know that our eGenix extensions are using them
and there are quite a few hits on github as well:

https://github.com/search?utf8=%E2%9C%93=PyEval_CallObjectWithKeywords=Code=searchresults

> I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and 
> deprecate them.

--

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[Christian Heimes]

Christian Heimes added the comment:

Please also provide more information about your system: platform, distro, 
architecture, OpenSSL version, exact Python version etc.

--

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[Christian Heimes]

Christian Heimes added the comment:

Please install debug symbols and provide a proper C backtrace of the invalid 
free call. The backtrace in your first comment is missing both line numbers, 
file and function names.

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[INADA Naoki]

INADA Naoki added the comment:

> I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and 
> deprecate them.

That's PR 75 :)

--

___
Python tracker 

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

[issue29157] random.c: Prefer getrandom() over getentropy() to support glibc 2.24 on Linux

[STINNER Victor]

STINNER Victor added the comment:

Python 2.7, see issue #29188: "Backport random.c from Python 3.5 to Python 
2.7". Mercurial commit 13a39142c047, Git commit 
01bdbad3e951014c58581635b94b22868537901c.

https://github.com/python/cpython/commit/01bdbad3e951014c58581635b94b22868537901c

--

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[STINNER Victor]

STINNER Victor added the comment:

You now have to test "PYTHONMALLOC=malloc valgrind python3 ...".

IMHO it's not a bug in Python, but in your code ussing OpenSSL:

  File "/var/bluelabs/python/_cams_threaded_server.py", line 49 in sni_callback

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[STINNER Victor]

STINNER Victor added the comment:

> Please note that the two sets of APIs are not identical, e.g. you cannot 
> simply replace PyEval_CallObject() with PyObject_Call(), since the former 
> applies a few extra checks and defaults, which the latter doesn't.

IMHO these checks are too expensive at runtime for little benefit. If you pass 
non-tuple to PyObject_Call(), Python immediately crash. You are immediately 
noticied of the bug :-) I don't think that such bugs are common enough to 
justify the overhead.

Any idea of the popularity of the undocumented PyEval_xxx() functions? Are they 
used by Cython for example? By a single random extension module in the world?

I'm more in favor of modifying PyEval_xxx() to call PyObject_xxx() and 
deprecate them.

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[STINNER Victor]

STINNER Victor added the comment:

"you now add the extra support for args being NULL to PyObject_Call()"

I dislike this idea. I don't want to change the API of this function.

If it is likely that NULL is the result of a previous error:

args = Py_BuildValue(...);
res = PyObject_Call(func, args, NULL);

There are already enough ways to call a function with no argument:

res = PyObject_CallFunction(func, NULL);
res = PyObject_CallFunctionObjArgs(func, NULL);
res = _PyObject_CallNoArg(func)   # private

If you want to call a function only with keyword arguments, well, create an 
empty tuple ... which is a singleton in CPython, no risk of memory allocation 
failure ... and use PyObject_Call(), no?

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Looking through Python's history, it's interesting that PyObject_Call() did 
apply the args == NULL checks up until Python 2.1.

In Python 2.2 this was replaced by a direct call to tp_call, without the 
checks. However, the tp_call slots don't do this check as you can see in 
function_call() of function objects. And indeed, the documentation of 
PyObject_Call() was changed in that version as well to disallow args == NULL.

--

___
Python tracker 

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

[issue25720] Fix curses module compilation with ncurses6

[Ismail Donmez]

Ismail Donmez added the comment:

What's the status on this? Can you please create a pull request on Github so we 
can continue there?

--

___
Python tracker 

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

[issue24665] CJK support for textwrap

[STINNER Victor]

STINNER Victor added the comment:

See also the now old issue #12568: "Add functions to get the width in columns 
of a character".

--

___
Python tracker 

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

[issue11165] Document PyEval_Call* functions

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

The PyEval_Call*() APIs indeed predate the PyObject_Call*() ones. The 
PyObject_Call*() APIs came into existence when the abstract layer was added in 
Python 1.3.

The PyObject_Call*() APIs lacked a way to call an object with keyword arguments 
for a long time. I guess that's what most people continued to use the 
PyEval_Call*() ones. The latter also provide better protection against wrong 
parameters. The interpreter itself used them interchangeably.

--
nosy: +lemburg

___
Python tracker 

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

[issue5667] Interpreter fails to initialize on build dir when IO encoding is one of CJK

[STINNER Victor]

STINNER Victor added the comment:

I'm unable to reproduce the bug. It seems like it was fixed since 8 years ;-)

haypo@selma$ LC_ALL=ko_KR.eucKR ./python
Python 3.7.0a0 (default, Feb 14 2017, 10:48:09) 
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

haypo@selma$ LC_ALL=ko_KR.eucKR ./python -S
Python 3.7.0a0 (default, Feb 14 2017, 10:48:09) 
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux
>>>

--
nosy: +haypo
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

[issue24665] CJK support for textwrap

[STINNER Victor]

STINNER Victor added the comment:

Florent Gallaire: Since Python 3.0 was released in 2008, new features are no 
more accepted in Python 2 (Python 2.7, the last release of Python 2). It's a 
deliberate choice, mostly motivated by the lack of CPython developers. See also 
the PEP 404.

I'm only talking about Python core and its builtin stdlib: it became very easy 
to extend Python with third party modules. We even added ensurepip to Python 
2.7.9, even if we didn't want to add new features to Python 2. So just create a 
module on PyPI as you did, make it working on Python 2.7+ and you are done ;-)

In 2016, INADA Naoki and Xiang Zhang got promoted to Python core developers: 
Naoki is japanese and Xiang is chinese. Maybe they would help on CJK issues.

Please remind that Python core developers are volunteers contributing to Python 
in their free time.

Have a nice day :-)

--

___
Python tracker 

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

[issue29548] deprecate PyEval_Call*() functions.

[INADA Naoki]

INADA Naoki added the comment:

> The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced 
> with an empty tuple), but will raise a segfault for PyObject_Call().

PyObject_CallObject() accepts NULL as args. Macro vs function is only 
difference of them.

On the other hand, PyObject_CallObjectWithKeyword() doesn't have identical 
function.
So I agree your suggestion to add NULL support to PyObject_Call().

We have more fast _PyObject_FastCall* APIs for performance critical code.
Additional cost to check NULL in PyObject_Call() would be negligible.

Any opinion from others?

--

___
Python tracker 

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

[issue29470] [python] Error in `/usr/bin/python': free(): invalid size: 0x00007f628400d0e0

[David Ford (FirefighterBlu3)]

David Ford (FirefighterBlu3) added the comment:

2017-02-14 06:58:29 INFO connected: mustang.blue-labs.org/107.170.82.162:37188
2017-02-14 06:58:29 INFO No cert required for this host
*** Error in `/usr/bin/python': double free or corruption (out): 
0x7fb0f8003400 ***
2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in 
violation of protocol (_ssl.c:749)
Fatal Python error: Aborted

Thread 0x7fb0e700 (most recent call first):
  File "/var/bluelabs/python/_cams_threaded_server.py", line 116 in handle
  File "/usr/lib/python3.6/socketserver.py", line 696 in __init__
  File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request
  File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/pytho2017-02-14 06:58:29 INFO goodbye3 107.170.82.162
2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in 
violation of protocol (_ssl.c:749)
2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in 
violation of protocol (_ssl.c:749)
2017-02-14 06:58:29 WARNING SSL client handshake has failed: EOF occurred in 
violation of protocol (_ssl.c:749)
n3.6/threading.py", line 884 in _bootstrap

Thread 0x7fb100de2700 (most recent call first):
  File "/var/bluelabs/python/_cams_thread2017-02-14 06:58:29 INFO goodbye3 
107.170.82.162
2017-02-14 06:58:29 INFO disconnect: Thread-6
2017-02-14 06:58:29 INFO goodbye3 107.170.82.162
2017-02-14 06:58:29 INFO disconnect: Thread-5
ed_server.py", line 116 in handle
  File "/usr/lib/python3.6/socketserver.py", line 696 in __init__
  File "2017-02-14 06:58:29 INFO goodbye3 107.170.82.162
2017-02-14 06:58:29 INFO disconnect: Thread-10
/usr/lib/python3.6/socketserver.py", line 361 in 2017-02-14 06:58:29 INFO 
disconnect: Thread-11
finish_request
  File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap

Thread 0x7fb1025e5700 (most recent call first):
  File "/var/bluelabs/python/_cams_threaded_server.py", line 137 in handle
  File "/usr/lib/python3.6/socketserver.py", line 696 in __init__
  File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request
  File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap

Thread 0x7fb102de6700 (most recent call first):
  File "/var/bluelabs/python/_cams_threaded_server.py", line 137 in handle
  File "/usr/lib/python3.6/socketserver.py", line 696 in __init__
  File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request
  File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap

Current thread 0x7fb1035e7700 (most recent call first):
  File "/var/bluelabs/python/_cams_threaded_server.py", line 49 in sni_callback
  File "/usr/lib/python3.6/ssl.py", line 683 in do_handshake
  File "/usr/lib/python3.6/ssl.py", line 1061 in do_handshake
  File "/var/bluelabs/python/_cams_threaded_server.py", line 152 in handle
  File "/usr/lib/python3.6/socketserver.py", line 696 in __init__
  File "/usr/lib/python3.6/socketserver.py", line 361 in finish_request
  File "/usr/lib/python3.6/socketserver.py", line 639 in process_request_thread
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap

Thread 0x7fb11131a700 (most recent call first):
  File "/usr/lib/python3.6/threading.py", line 299 in wait
  File "/usr/lib/python3.6/threading.py", line 551 in wait
  File "/var/bluelabs/bots/cams/camsbot.py", line 753 in 
start_message_queue_handler
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/python3.6/threading.py", line 884 in _bootstrap

Thread 0x7fb111b1b700 (most recent call first):
  File "/var/bluelabs/python/irclib.py", line 230 in process_once
  File "/var/bluelabs/python/irclib.py", line 246 in process_forever
  File "/var/bluelabs/python/irclib.py", line 1228 in start
  File "/var/bluelabs/python/ircbot.py", line 258 in start
  File "/usr/lib/python3.6/threading.py", line 864 in run
  File "/usr/lib/python3.6/threading.py", line 916 in _bootstrap_inner
  File "/usr/lib/python3.6/threading.py", line 884 in 

[issue11173] Undocumented public APIs in Python 3.2

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

PyEval_CallObject wasn't removed. It's a macro now. And it was documented for a 
long time in Extending Python... in fact, the documentation was removed, not 
the API :-)

--

___
Python tracker 

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

[issue26467] Add async magic method support to unittest.mock.Mock

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag
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

[issue29552] Issue in Dictionary fromkeys

[Prudvi Mangadu]

Prudvi Mangadu added the comment:

Also observed that ID of the values are pointing same, its ok.
But if some one later modified that values which causes the un-usual output.

>>> id(result['1'])
38121184
>>> id(result['2'])
38121184

--

___
Python tracker 

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