[issue28924] Inline PyEval_EvalFrameEx() in callers

[STINNER Victor]

STINNER Victor added the comment:

> It may break other debuggers like Python Tools for Visual Studio, though 
> (+steve.dower for that).

Do you mean debuggers expecting that bytecode is run in PyEval_EvalFrameEx() 
rather than PyEval_EvalFrameDefault()? Can't we fix these debuggers?


> IMHO, inlining is best left to profiling optimizers.

The problem is that PGO compilation is not used by everyone yet. The patch is a 
minor enhancement to make sure that regular builds are also fast.

--

___
Python tracker 

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

[issue28920] Dangerous usage of "O" format string in _asynciomodule.c

[Roundup Robot]

Roundup Robot added the comment:

New changeset f2745b64d8b7 by Victor Stinner in branch '3.6':
_asyncio uses _PyObject_CallMethodIdObjArgs()
https://hg.python.org/cpython/rev/f2745b64d8b7

--
nosy: +python-dev

___
Python tracker 

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

[issue28920] Dangerous usage of "O" format string in _asynciomodule.c

[STINNER Victor]

Changes by STINNER Victor :


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

___
Python tracker 

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

[issue28838] Using consistent naming for arguments of "call" functions (C API)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 654ec6ed3225 by Victor Stinner in branch 'default':
Issue #28838: Cleanup abstract.h
https://hg.python.org/cpython/rev/654ec6ed3225

--

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

May be just replace inlined call with _PyEval_EvalFrameDefault?

--

___
Python tracker 

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

[issue28838] Using consistent naming for arguments of "call" functions (C API)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Victor, it would be worth to discuss this change on Python-Dev.

--

___
Python tracker 

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

[issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio

[INADA Naoki]

INADA Naoki added the comment:

> Fixed fromkeys() in Py2.7.  Stills needs to be forward ported to 3.4/3.5.

dict.fromkeys() is fixed already in 3.6+.

dict(l) doesn't presize the dict.  If it's desirable, let's create a new issue.

--
nosy: +inada.naoki
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: "May be just replace inlined call with _PyEval_EvalFrameDefault?"

Do you mean replacing PyEval_EvalFrameEx() with _PyEval_EvalFrameDefault()? It 
would defeat the purpose of the PEP 523, no?

--

___
Python tracker 

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

[issue28977] Document PyObject_CallFunction() special case more explicitly

[STINNER Victor]

New submission from STINNER Victor:

The PyObject_CallFunction() function has a special case if the format string is 
"O". See my email thread on python-dev:
https://mail.python.org/pipermail/python-dev/2016-December/146919.html

Serhiy wrote: "It is documented for Py_BuildValue(), and the documentation of 
PyObject_CallFunction() refers to Py_BuildValue()." which is true, but I would 
prefer to be more explicit to avoid bad surprises (see issues #21209 and 
#28920).

Attached patch modifies PyObject_CallFunction() doc to mention the "O" format 
special case in the .rst doc and the .h comment.

The documentation of PyObject_CallMethod() and _PyObject_CallMethodId() should 
also be modified, but I would prefer to wait for a first review on the added 
text before modifying all functions.

I proposed to only modify Python 3.7 because Include/abstract.h was a in a bad 
shape: I rewrote this file to make it easier to maintain, but only in Python 
3.7, see issue #28838.

--
assignee: docs@python
components: Documentation, Interpreter Core
files: call_doc.patch
keywords: patch
messages: 283256
nosy: docs@python, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document PyObject_CallFunction() special case more explicitly
versions: Python 3.7
Added file: http://bugs.python.org/file45908/call_doc.patch

___
Python tracker 

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

[issue28838] Using consistent naming for arguments of "call" functions (C API)

[STINNER Victor]

STINNER Victor added the comment:

I pushed cleanup-2.patch (after a minor rebase). Sorry for breaking "hg 
annotation" on Include/abstract.h: I hope that it will be less annoying that 
the giant "replace tabs with space" made by Antoine Pitrou a few years ago 
which modified almost all .c and .h files (my change only changes a single 
file, abstract.h). If you have large pending patch series which modify this 
file, ping me, I will help you to rebase them.

Sorry, I didn't expect this issue to be so painful. I hope that abstract.h is 
now more readable, easier to maintain (no more surprising indentation!), and 
have better comments. I now started to cleanup the documentation of functions 
of the "PyObject_Call() family": see my first issue #28977. I think that we 
should then synchronize .rst doc and .h comments to make them consistent again 
(and maybe update the doc).

--

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ah, now I see. I was confused by the fact that eval_frame is set only to 
_PyEval_EvalFrameDefault.

But how large the gain of inlining PyEval_EvalFrameEx()? Is it worth cluttering 
the code?

Since almost all calls of PyEval_EvalFrameEx() are in the same file as its 
definition, I suppose the compiler can inline it even without PGO.

--

___
Python tracker 

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

[issue28147] Unbounded memory growth resizing split-table dicts

[Ned Deily]

Ned Deily added the comment:

It appears this issue has stalled again.  Is the most recent patch 
fix28147-py36-2.patch) ready for review?  If so, can someone please review it?  
Then it needs to be pushed to the 3.6 branch for 3.6.1 and exposed to the 
buildbots.  Only then could we consider cherrypicking for 3.6.0 and a change of 
the magnitude in the patch would require at least another preview release and 
delay 3.6.0 final. 3.6.0 is scheduled to be released tomorrow. I am very 
reluctant to delay now for an issue that has been open now for 3 months 
throughout the beta phase of the release cycle.  If enough people feel we 
should delay 3.6.0 to address this, we can.  But without a fix reviewed and 
committed and without more feedback from other core developers, 3.6.0 is going 
out without it.  @inada.naoki ? @haypo ? @serhiy.storchaka ?  Others?

--

___
Python tracker 

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

[issue28967] copy.copy fails on threading.local subclass

[Ned Deily]

Ned Deily added the comment:

Thanks for raising the issue, Jelle.  And thanks for the analysis, Serhiy.  It 
doesn't sound like a release blocker for 3.6.0.  Is it worth addressing at all?

--
assignee: ned.deily -> 
priority: release blocker -> normal
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

[issue28147] Unbounded memory growth resizing split-table dicts

[Ned Deily]

Changes by Ned Deily :


--
priority: high -> deferred blocker

___
Python tracker 

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

[issue28971] nntplib is broken when responses are longer than _MAXLINE

[Xavier de Gaye]

Xavier de Gaye added the comment:

The patch:
1) Increases _MAXLINE to 4096.
2) Reverts issue 16040 and that is not correct, please ignore that part.

The changes made in issue 16040 limit the amount of data read by readline() and 
does not close the nntp session when the server sends a message whose size is 
greater than this limit. In that case, should not nntplib close the session as 
the session has become unusable as shown by the test_nntplib results in 
test_nntplib.log?

--

___
Python tracker 

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

[issue28930] bytes_methods.c won't recompile if related stringlib/* changed

[Roundup Robot]

Roundup Robot added the comment:

New changeset 56a7eb5a0679 by Xiang Zhang in branch '3.6':
Issue #28930: Add a Makefile rule for bytes_methods.c.
https://hg.python.org/cpython/rev/56a7eb5a0679

New changeset c4bcca326c0a by Xiang Zhang in branch 'default':
Issue #28930: Merge from 3.6.
https://hg.python.org/cpython/rev/c4bcca326c0a

--
nosy: +python-dev

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: "Since almost all calls of PyEval_EvalFrameEx() are in the same file as 
its definition, I suppose the compiler can inline it even without PGO."

Let me check. My patch changes gen_send_ex() of genobject.c and 
_PyEval_EvalCodeWithName() of ceval.c. "gcc -O3" is able to inline 
PyEval_EvalFrameEx() in the same file (ceval.c), but not in a different file 
(genobject.c).

My patch also avoids an useless call to PyThreadState_GET()... Well, I'm not 
sure that it's worth it. I propose the change because the indirection now looks 
completely useless to me, but I didn't expect that it could break anything. 
With my patch, python-gdb.py is fixed. Steve says that Visual Studio is already 
fixed as well. So I don't know, it's up to you ;-)

--

gen_send_ex().

C code:
188 gen->gi_running = 1;
189 result = PyEval_EvalFrameEx(f, exc);
190 gen->gi_running = 0;

x86_64 assembler (gcc -03):
=> 0x0047fe37 :   movb   $0x1,0x18(%rbp)
   0x0047fe3b :   callq  0x54b870 

   0x0047fe40 :   movb   $0x0,0x18(%rbp)
   0x0047fe44 :   mov%rax,%r12
   0x0047fe47 :   mov0x18(%rbx),%rdi

I still see the call to PyEval_EvalFrameEx().

--

_PyEval_EvalCodeWithName().

C code:
4169retval = PyEval_EvalFrameEx(f,0);

x86_64 assembler (gcc -03):
=> 0x0054ae30 <+2544>:  mov0x3827f9(%rip),%rax# 0x8cd630 
<_PyThreadState_Current>
   0x0054ae37 <+2551>:  xor%esi,%esi
   0x0054ae39 <+2553>:  mov0x40(%rsp),%rdi
   0x0054ae3e <+2558>:  mov0x10(%rax),%rax
   0x0054ae42 <+2562>:  callq  *0x70(%rax)

In this file, PyEval_EvalFrameEx() is inlined. I understand that the first 
instruction is the PyThreadState_GET() call which is an atomic read (single x86 
instruction). My patch avoids the useless PyThreadState_GET(), since tstate 
must not change.

--

___
Python tracker 

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

[issue28930] bytes_methods.c won't recompile if related stringlib/* changed

[Xiang Zhang]

Changes by Xiang Zhang :


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

[issue28147] Unbounded memory growth resizing split-table dicts

[STINNER Victor]

STINNER Victor added the comment:

fix28147-py36-2.patch: test_dict pass with DEBUG_PYDICT defined.

--

___
Python tracker 

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

[issue11322] encoding package's normalize_encoding() function is too slow

[INADA Naoki]

Changes by INADA Naoki :


--
keywords: +patch
Added file: http://bugs.python.org/file45909/encoding_normalize_optimize.patch

___
Python tracker 

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

[issue11322] encoding package's normalize_encoding() function is too slow

[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

[issue28971] nntplib is broken when responses are longer than _MAXLINE

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

It seems to me there are two issues:

1) The limit of line length is not large enough.
2) After raising an error on too long line the NNTP object is left in broken 
state.

The first issue can be solved by increasing the default limit or by patching 
the nntp module in tests.

For the second issue I suggest to open new tracker issue.

--

___
Python tracker 

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

[issue11322] encoding package's normalize_encoding() function is too slow

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Thanks for the patch.

Victor has implemented the function in C, AFAIK, so an even better approach 
would be to expose that function at the Python level and use it in the 
encodings package.

--
versions: +Python 3.7 -Python 3.4, Python 3.5

___
Python tracker 

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

[issue28147] Unbounded memory growth resizing split-table dicts

[INADA Naoki]

Changes by INADA Naoki :


Added file: http://bugs.python.org/file45910/fix28147-py36-3.patch

___
Python tracker 

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

[issue28147] Unbounded memory growth resizing split-table dicts

[STINNER Victor]

STINNER Victor added the comment:

I reviewed fix28147-py36-2.patch, I have some requests.

--

___
Python tracker 

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

[issue28147] Unbounded memory growth resizing split-table dicts

[STINNER Victor]

STINNER Victor added the comment:

Ned: "If so, can someone please review it?"

Done.


Ned: "I am very reluctant to delay now for an issue that has been open now for 
3 months throughout the beta phase of the release cycle.  If enough people feel 
we should delay 3.6.0 to address this, we can."

The bug was seen as minor and I didn't expect that anyone would notice it.

Wenzel Jakob wrote "RSS goes to 43MB to 4.3GB": for me, it's a major 
regression, and it's not possible to work around it. With such bug, Python 3.6 
is unusable on such application (pybind11). I easily imagine that such memory 
leak is a blocker issue for a server running for days.

I now consider that Python 3.6.0 must not be released with such blocker issue.

--
nosy: +larry
priority: deferred blocker -> release blocker

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[Brendan Donegan]

Brendan Donegan added the comment:

Can you provide a code snippet that demonstrates the actual problem? As far as 
I can see this code behaves as documented

--
nosy: +brendan-donegan

___
Python tracker 

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

[issue28147] Unbounded memory growth resizing split-table dicts

[STINNER Victor]

STINNER Victor added the comment:

fix28147-py36-3.patch LGTM: Naoki, please push it right now.

But please see also my comments on fix28147-py36-2.patch: I would still 
apprecicate that we enhance the comment in dictobject.c. The comment is not a 
blocker issue for 3.6.0, it can be enhanced later :-D

--

___
Python tracker 

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

[issue11322] encoding package's normalize_encoding() function is too slow

[STINNER Victor]

STINNER Victor added the comment:

It seems like encodings.normalize_encoding() currently has no unit test! Before 
modifying it, I would prefer to see a few unit tests:

* " utf 8 "
* "UtF 8"
* "utf8\xE9"
* etc.

Since we are talking about an optimmization, I would like to see a benchmark 
result before/after. I also would like to test Marc-Andre's idea of exposing 
the C function _Py_normalize_encoding().

_Py_normalize_encoding() works on a byte string encoded to Latin1. To implement 
encodings.normalize_encoding(), we might rewrite the function to work on 
Py_UCS4 character, or have a fast version on char*, and a more generic version 
for UCS2 and UCS4?

--

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

code :
>>> if 1<2<3:print(123);print(op);

Output:
123
Traceback (most recent call last):
 
NameError:...

--

___
Python tracker 

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

[issue28925] Confusing exception from cPickle on reduce failure

[Raoul Gough]

Raoul Gough added the comment:

Hi Serhiy, thanks very much for looking at this. My only concern with removing 
the code completely is that it does work (presumably as intended) with at least 
some of the standard exception types. For example, if you change the demo to 
raise and catch a RuntimeError instead of MyException, the output looks like 
this:

INFO:root:Creating BadReduce object
INFO:root:Pickling
INFO:root:Unpickling
INFO:root:Raising exception "BadReduce init failed"
INFO:root:Got RuntimeError "(RuntimeError('BadReduce init failed',), , (1123,))"
INFO:root:Done

Where the caught RuntimeError contains the original RuntimeError and some 
additional information from cPickle.

I also checked that it correctly propagates KeyboardInterrupt by testing 
manually with a sleep:

INFO:root:Creating BadReduce object
INFO:root:Pickling
INFO:root:Unpickling
INFO:root:Sleeping a while - send keyboard interrupt to test
  C-c C-cTraceback (most recent call last):
  File "/home/zk8ms03/python/cpickle_reduce_failure.py", line 49, in 
main()
  File "/home/zk8ms03/python/cpickle_reduce_failure.py", line 42, in main
pickler.loads(s1)
  File "/home/zk8ms03/python/cpickle_reduce_failure.py", line 28, in __init__
time.sleep(5.0)
KeyboardInterrupt: (None, , (1123,))


I'm not sure how likely it is that anyone depends on the extra information that 
cPickle adds in these cases, so I'll leave it up to others to decide what's 
best.

--

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[Brendan Donegan]

Brendan Donegan added the comment:

How does that contradict the documentation? Both print statements were executed 
- the second one raised an exception because of 'op' not being defined.

--

___
Python tracker 

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

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

[Maciej Szulik]

Maciej Szulik added the comment:

I tend to agree with Eric Lafontaine, looking at the quote Henning von Bargen 
posted the originator address field is also required, but yet we don't 
explicitly check its presence in the code, but rely on the SMTP server to error 
out.

--
nosy: +maciej.szulik

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

code :
>>> if 1<2<3:print(123);print(op);print(opi);

Output:
123
Traceback (most recent call last):
 
NameError:name 'op' is not defined

The third 'print' call hasn't been executed.

--

___
Python tracker 

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

[issue28838] Using consistent naming for arguments of "call" functions (C API)

[STINNER Victor]

STINNER Victor added the comment:

Serhiy: "Victor, it would be worth to discuss this change on Python-Dev."

Done: https://mail.python.org/pipermail/python-dev/2016-December/146999.html

--

___
Python tracker 

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

[issue28925] Confusing exception from cPickle on reduce failure

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Perhaps it was added for debugging. Exceptions that don't define own __new__ 
and __init__ inherit them from BaseException. BaseException constructor saves 
positional arguments as the args attribute. But not all standard exceptions 
accept arbitrary number of positional arguments. For example UnicodeEncodeError 
and UnicodeDecodeError don't work.

--

___
Python tracker 

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

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

[Chi Hsuan Yen]

Changes by Chi Hsuan Yen :


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

[issue28969] fnmatch is not threadsafe

[Peter Otten]

Peter Otten added the comment:

Here's another way to reproduce the error. The problem seems to be in the C 
implementation of _lru_cache_wrapper() / bounded_lru_cache_wrapper().

$ cat test.py
import functools
import threading
import time

@functools.lru_cache(maxsize=2)
def f(v):
time.sleep(.01)

threads = [threading.Thread(target=f, args=(v,)) for v in [1,2,2,3,2]]
for t in threads:
t.start()

$ ./python test.py
Exception in thread Thread-5:
Traceback (most recent call last):
  File "/somewhere/Lib/threading.py", line 916, in _bootstrap_inner
self.run()
  File "/somewhere/Lib/threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
KeyError: (2,)

$ ./python
Python 3.7.0a0 (default:654ec6ed3225+, Dec 15 2016, 11:24:30) 
[GCC 4.8.4] on linux

--
nosy: +peter.otten, rhettinger, serhiy.storchaka

___
Python tracker 

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

[issue28838] Using consistent naming for arguments of "call" functions (C API)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Victor.

--

___
Python tracker 

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

[issue28969] fnmatch is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
keywords: +3.5regression
stage:  -> needs patch
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

[issue28925] Confusing exception from cPickle on reduce failure

[Roundup Robot]

Roundup Robot added the comment:

New changeset eb830f1511ef by Serhiy Storchaka in branch '2.7':
Issue #28925: cPickle now correctly propagates errors when unpickle instances
https://hg.python.org/cpython/rev/eb830f1511ef

--
nosy: +python-dev

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[Brendan Donegan]

Brendan Donegan added the comment:

Indeed, but that's merely because an exception has been raised. The example 
given doesn't include any statements that would raise an exception.

I'm not sure it's necessary to re-iterate well known Python behaviour in this 
section.

Anyway, that's my 2c

--

___
Python tracker 

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

[issue28147] Unbounded memory growth resizing split-table dicts

[INADA Naoki]

INADA Naoki added the comment:

This patch updates the comment.

--
Added file: http://bugs.python.org/file45911/fix28147-comment-update.patch

___
Python tracker 

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

[issue28969] lru_cache is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
title: fnmatch is not threadsafe -> lru_cache is not threadsafe

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

Thanks for your attention.

--

___
Python tracker 

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

[issue28689] OpenSSL 1.1.0c test failures

[Christian Heimes]

Christian Heimes added the comment:

No blacklisting :)
I don't want to mess with any code prior to the final release of Python 3.6.0. 
Let's just document that stock 1.1.0c is not compatible.

Ned, I'm setting the release blocker flag as a reminder to add a comment to the 
release notes of 3.6.0.

--
nosy: +ned.deily
priority: high -> release blocker

___
Python tracker 

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

[issue28870] Refactor PyObject_CallFunctionObjArgs() and like

[Roundup Robot]

Roundup Robot added the comment:

New changeset 71876e4abce4 by Victor Stinner in branch 'default':
Add _PY_FASTCALL_SMALL_STACK constant
https://hg.python.org/cpython/rev/71876e4abce4

--
nosy: +python-dev

___
Python tracker 

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

[issue28915] Modify PyObject_CallFunction() to use fast call internally

[Roundup Robot]

Roundup Robot added the comment:

New changeset bec846dd92e8 by Victor Stinner in branch 'default':
Fix _PyObject_CallFunctionVa(), use the small stack
https://hg.python.org/cpython/rev/bec846dd92e8

--

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

New submission from woo yoo:

Quote the documentation as below:

> parameter_list ::=  (defparameter ",")*
| "*" [parameter] ("," defparameter)* ["," "**" parameter]
| "**" parameter
| defparameter [","] )

The last right parenthesis is redundant.And the second alternative form is not 
complete, it does not incorporate a case that only include starred parameter.

--
assignee: docs@python
components: Documentation
messages: 283288
nosy: docs@python, woo yoo
priority: normal
severity: normal
status: open
title: a redundant right  parentheses in the EBNF rules of parameter_list
versions: Python 3.5

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

woo yoo added the comment:

Here is the link 
https://docs.python.org/3/reference/compound_stmts.html#function-definitions

--

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

woo yoo added the comment:

Just the right parenthesis is redundant, ignore other words.

--

___
Python tracker 

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

[issue28969] lru_cache is not threadsafe

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your example Peter.

Proposed patch fixes the KeyError. It introduces new private C API 
_PyDict_Pop_KnownHash(). It is like _PyDict_Pop(), but with precomputed hash.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45912/lru_cache-dict-pop.patch

___
Python tracker 

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

[issue28925] Confusing exception from cPickle on reduce failure

[Serhiy Storchaka]

Changes 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

[issue22135] allow to break into pdb with Ctrl-C for all the commands that resume execution

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Here comes the patch:

1. Let Pdb can also resume from `return`, `until` and `next` commands when 
receiving Control-C.

2. Explicitly raise `bdb.BdbQuit` when an unexpected exception occurs in 
`sigint_handler`. See #24283.

3. Add two tests `test_break_during_interactive_input`, 
`test_resume_from_sigint` and some helper functions to `test_pdb.py` to make 
sure that Pdb behaves as we expected.
See below, Pdb resumes back in a wrong position when receiving Control-C.  The 
environment is Python 3.5.2 (Mac).  But Pdb works right in latest 
3.5/3.6/default now. So we should have tests here.
(Pdb) list
  1  import time
  2  def f():
  3  import pdb; pdb.Pdb().set_trace();
  4  ->delay()
  5  print("* f() done *")
  6
  7  def delay():
  8  time.sleep(3)
  (Pdb) c
^C
Program interrupted. (Use 'cont' to resume).
--Call--
> /usr/local/var/pyenv/versions/3.5.2/lib/python3.5/signal.py(45)signal()
-> @_wraps(_signal.signal)
(Pdb)



What this patch does NOT do are:

1. Let Pdb can resume from `step` command.
I tried by the same way like what I did for `continue/return/until/next` 
commands, but Pdb resumed back at the beginning of `sigint_handler`. The user 
should type in `continue` to go to the right place. I can't find an elegant way 
to work around it:
-> time.sleep(3)
(Pdb) s
^C--Call--
> /Users/chun-yutseng/Projects/cpython/Lib/pdb.py(189)sigint_handler()
-> def sigint_handler(self, signum, frame):
(Pdb) l
184  self.commands_defining = False # True while in the process of 
defining
185 # a command list
186  self.commands_bnum = None # The breakpoint number for which we 
are
187# defining a list
188
189  ->def sigint_handler(self, signum, frame):
190  if self.allow_kbdint:
191  raise KeyboardInterrupt
192  try:
193  self.message("\nProgram interrupted.")
194
(Pdb)

2. Let the two added tests can be run on Windows.
I tried, but when I found that I may need to use Windows-specific signals 
(CTRL_C_EVENT/CTRL_BREAK_EVENT) in `pdb.py` to let automated tests pass, I 
decided not to introduce such complexity.
So I use `@unittest.skipIf` to skip these two tests and tested the patch on 
Windows manually.


Call for review/advice/guides, please.

--
keywords: +patch
nosy: +Chun-Yu Tseng
versions: +Python 3.7 -Python 3.5
Added file: http://bugs.python.org/file45913/fix-cc-and-add-tests.patch

___
Python tracker 

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

[issue28969] lru_cache is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
type: crash -> behavior

___
Python tracker 

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

[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'

[Matt Joiner]

Changes by Matt Joiner :


--
nosy:  -anacrolix

___
Python tracker 

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

[issue28971] nntplib is broken when responses are longer than _MAXLINE

[Xavier de Gaye]

Xavier de Gaye added the comment:

It seems that the comment placed above the definition of _MAXLINE in the 
nntplib module is not correct:
"RFC 3977 limits NNTP line length to 512 characters, including CRLF. We 
have selected 2048 just to be on the safe side."
The 512 characters limit in RFC 3977 only applies to command lines and to the 
initial line of a response.

RC 3977 says instead:
"This document does not place any limit on the length of a line in a 
multi-line block.  However, the standards that define the format of articles 
may do so."

So I think _MAXLINE should have a large value (64 K ?) and its semantic is that 
a line whose length is above that value is considered by nntplib as a Dos 
attack (and not a protocol violation). In that case nntplib should behave in 
consequence and prevent any further reads from that connection (either by 
closing the connection or raising an exception on each of these attempts). IMHO 
this should be handled in the same issue because it is one single problem, and 
this may possibly be handled in two different changesets.

--

___
Python tracker 

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

[issue28969] lru_cache is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: http://bugs.python.org/file45912/lru_cache-dict-pop-3.5.patch

___
Python tracker 

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

[issue28969] lru_cache is not threadsafe

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file45914/lru_cache-dict-pop-3.5.patch

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

woo yoo added the comment:

And i find that the current rules of parameter_list includes a bare '*',which 
is illegal in practice.

--

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[Jim Fasarakis-Hilliard]

Jim Fasarakis-Hilliard added the comment:

See issue<9232> that changed the docs on function definitions. These changes 
aren't reflected in the 3.5 documentation though, you'll find them in the 3.6 
docs.

The linked grammar is probably missing an opening parentheses from what I can 
tell, i.e change | to (:

( "*" [parameter] ("," defparameter)* ["," "**" parameter]

--
nosy: +Jim Fasarakis-Hilliard

___
Python tracker 

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

[issue28870] Refactor PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

I reworked abstract.c to prepare work for this issue:

* change 455169e87bb3: Add _PyObject_CallFunctionVa() helper
* change 6e748eb79038: Add _PyObject_VaCallFunctionObjArgs() private function
* change 71876e4abce4: Add _PY_FASTCALL_SMALL_STACK constant


I wrote a function _testcapi to measure the consumption of the C code. I was 
surprised by the results: calling PyObject_CallFunctionObjArgs(func, arg1, 
arg2, NULL) consumes 560 bytes! I measured on a Python compiled in release mode.

Attached less_stack.patch rewrites _PyObject_VaCallFunctionObjArgs(), it 
reduces the stack consumption from 560 bytes to 384 bytes (-176 bytes!).

Changes:

* Remove "va_list countva" variable: the va_list variable itself, va_copy(), 
etc. consume stack memory. First I tried to move code to a subfunction, it 
helps. With my patch, it's even simpler.

* Reduce _PY_FASTCALL_SMALL_STACK from 5 to 3. Stack usage is not directly 
_PY_FASTCALL_SMALL_STACK*sizeof(PyObject*), it's much more, probably because of 
complex memory alignement rules.

* Use Py_LOCAL_INLINE(). It seems like depending on the size of the 
object_vacall() function body, the function is inlined or not. If it's not 
inlined, the stack usage increases from 384 bytes to 544 bytes!? Use 
Py_LOCAL_INLINE() to force inlining.


Effect of _PY_FASTCALL_SMALL_STACK:

* 1: 368 bytes
* 2: 384 bytes
* 3: 384 bytes -- value chosen in my patch
* 4: 400 bytes
* 5: 416 bytes

--
Added file: http://bugs.python.org/file45915/less_stack.patch

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

Changes by STINNER Victor :


--
title: Refactor PyObject_CallFunctionObjArgs() and like -> Reduce stack 
consumption of PyObject_CallFunctionObjArgs() and like

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

I don't propose to add _testcapi.pyobjectl_callfunctionobjargs_stacksize(). 
It's just to test the patch. I'm using it with:

$./python -c 'import _testcapi; n=100; 
print(_testcapi.pyobjectl_callfunctionobjargs_stacksize(n) / (n+1))'
384.0

The value of n has no impact on the stack, it gives the same value with n=0.

--

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

woo yoo added the comment:

There is  a few difference between Python-3.5.2 and Python-3.6.2 concerning the 
EBNF rules even though the parenthesis bug is fixed.

--

___
Python tracker 

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

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

[Matteo Bertini]

Matteo Bertini added the comment:

I'm back on this issue with a minimal patch, and a longer motivation.

Distutils does not support Visual C++ for Python compiler, but it could, with a 
one-line patch.

The proposed workaround is to use `setuptools`. But, we are not alone in this 
World, am I supposed to fork each third party package still using `distutils` 
and upgrade them to `setuptools`?

No, someone will say, you can "simply" `import setuptools`, and it will 
monkey-patch `distutils` adding the support for VS for Python.

1) this is implicit, very very against the Python Zen
2) the modifications are not limited and back-compatible. Some packages, say 
`sip` from `PyQt`, are broken simply adding this `import setuptools`, and other 
are too.

That said, I think this minimal patch to the `find_vcvarsall` code, can save a 
lot of time to every Python 2.7 users, time I see better spent upgrading to 
Python 3.

Sorry for the rant-mode, but I very liked Python, and I still like Python more 
than other languages, but I don't think that providing half broken solutions 
and very limited support to all the developer still running Python 2.7 in some 
big old project is a good strategy to push people to Python 3.

Python 3 is already a better language, but Python as a language can be a better 
language only if Python 2.7 will be a first class citizen till 2020.

--
keywords: +patch
nosy: +naufraghi
type:  -> enhancement
Added file: http://bugs.python.org/file45916/vsforpython.diff

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

woo yoo added the comment:

Nor the rules in Python-3.6.0 excludes the bare '*' following no parameters.

--

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

I also tried to use alloca(): see attached alloca.patch. But the result is 
quite bad: 528 bytes of stack memory per call. I only attach the patch to 
discuss the issue, but I now dislike the option: the result is bad, it's less 
portable and more dangerous.

--
Added file: http://bugs.python.org/file45917/alloca.patch

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

I also tried Serhiy's approach, split the function into subfunctions, but the 
result is not as good as expected: 496 bytes. See attached subfunc.patch.

--
Added file: http://bugs.python.org/file45918/subfunc.patch

___
Python tracker 

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

[issue28979] What's New entry on compact dict mentions "faster" implementation

[Jim Fasarakis-Hilliard]

New submission from Jim Fasarakis-Hilliard:

Specifically, the entry reads:

"The dict type has been reimplemented to use a faster, more compact 
representation similar to the PyPy dict implementation."

Through, the text describing the new implementation doesn't mention anything on 
speed, it only mentions memory usage.

issue27350 and, specifically, msg275587 even report a slight regression ok key 
look-ups. Am I interpreting this differently? If not, is it a good idea to be 
stating it is faster?

--
assignee: docs@python
components: Documentation
messages: 283304
nosy: Jim Fasarakis-Hilliard, docs@python
priority: normal
severity: normal
status: open
title: What's New entry on compact dict mentions "faster" implementation
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

[issue28965] Multiprocessing spawn/forkserver fails to pass Queues

[kumaar.nd]

kumaar.nd added the comment:

hi,

few comments on this: [when tested with 'spawn']

1. the document(3x, 17.2.1.2) clearly mentions that 'spawn' doesnt inherit the 
file-handles (hence FileNotFoundError).
2. the document's examples has spawn() followed by join() where parent waits 
for the Child to finish and exits gracefully. The error "OSError: [Errno 9] Bad 
file descriptor" is seen for Child process.
3. Isnt exception-handling for null file descriptors sufficient (with 
corresponding Document updates)

am not a core developer yet and still trying to learn and contribute.

Thanks

--
nosy: +kumaar.nd

___
Python tracker 

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

[issue7291] urllib2 cannot handle https with proxy requiring auth

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Modify target versions to bugfix and feature branches

--
versions: +Python 3.7 -Python 2.6, Python 3.4

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> not a bug
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

[issue28968] xml rpc server fails with connection reset by peer error no 104

[R. David Murray]

R. David Murray added the comment:

Connection reset by peer means the far end has terminated the connection.  
You'll probably need to do some protocol analysis (wireshark or a similar tool) 
to find out why the connection is being dropped, or perhaps you can look at the 
far end logging.  As it is, there isn't enough information here to speculate as 
to a cause, or if there is any bug in the python library code.

(FYI Martin von Loewis hasn't had much time for CPython development lately, so 
I doubt he'll respond.)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

Why the issue was closed?

--

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

[STINNER Victor]

STINNER Victor added the comment:

For comparison, Python 3.5 (before fast calls) uses 448 bytes of C stack per 
call. Python 3.5 uses a tuple allocated in the heap memory.

--

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[Steve Dower]

Steve Dower added the comment:

At least define EvalFrameEx in a header as an inline func, rather than copying 
the body.

VS expected to walk the native stack and locate the f parameter in EvalFrameEx. 
Since the function gets inlined, it couldn't find the frame. I use the JIT hook 
to insert my own frame onto the stack which is easier to find, so yes, the 
debugger has been fixed, yes the function gets inlined, and yes this has an 
impact other than performance.

--

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[STINNER Victor]

STINNER Victor added the comment:

Well, since the impact on performance is likely non-existent, whereas drawbacks 
are real, I close the issue.

Thanks for your feedback ;-)

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

___
Python tracker 

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

[issue28924] Inline PyEval_EvalFrameEx() in callers

[STINNER Victor]

STINNER Victor added the comment:

> At least define EvalFrameEx in a header as an inline func, rather than 
> copying the body.

Hum, it would break the stable ABI, no?

--

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

Changes by woo yoo :


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

___
Python tracker 

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

[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322

[R. David Murray]

R. David Murray added the comment:

The sendmail function will never modify the RFC822+ content.  send_message, 
however, already does several manipulations of the message headers to make 
sending email simpler.  Practicality (make it easy to send messages without 
knowing the details of the SMTP/RFC5322 rules) beats purity (an SMTP library 
should not modify the content of the DATA) in this case, especially since 
smtplib *does* provide the purity version if you prefer to work that way.

That is, 'sendmail' is pure SMTP, while send_message is a practical enhancement 
that provides additional services to the caller, and can (and does and probably 
should) do checks for RFC required headers.

If someone wants to do a purity refactor (to which I would not object, and 
would in fact encourage), the RFC5322-aware code could be factored out into one 
or more functions or Message object methods in the email library that smtplib 
would call from the send_message method.

My visualization is that the email library should allow you to construct a 
valid email in whatever order you want (adding the Date header late in the 
process, for example), but should support validating the email before it is 
sent.  One way to do this would be to have the SMTP policy do the unambiguous 
fixups such as date headers, and raising errors for the rest (probably only if 
the strict flag is on, at this point) when the message is serialized.

Note that we previously fixed send_message to add a Resent-Date header if there 
are Resent- headers and no Resent-Date, so the precedent is already set (that 
is, smptlib send_message is already "not pure" :)

--

___
Python tracker 

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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[R. David Murray]

R. David Murray added the comment:

What do you mean by "a bare * followed by no parameters"?  That is, what is the 
thing that is considered invalid that you are saying the BNF rules allow?  I'm 
looking for a code snipped that produces a syntax error.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[R. David Murray]

R. David Murray added the comment:

Because the documentation is correct.  There is no bug here.  As Brendan said, 
there is no need to repeat a fundamental (that statements can raise exceptions) 
in this context.  The point of the passage is that

  if x: a; b; c;

is equivalent to

  if x:
 a
 b
 c

not

  if x: a
  b
  c

And that is what it clearly says, in my opinion.  The language reference is a 
specification and not a tutorial, so more words here would not be a good idea.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue7291] urllib2 cannot handle https with proxy requiring auth

[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

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

[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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[woo yoo]

woo yoo added the comment:

Code:
>>>def f(a, *):
>>>print(a)

（SyntaxError occurs here）

--

___
Python tracker 

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

[issue28980] ResourceWarning when imorting antigravity in 3.6

[Ivan Levkivskyi]

New submission from Ivan Levkivskyi:

In 3.6 importing antigravity prints a warning (although it does what it should 
do):

>>> import antigravity
/home/ivan/.../Lib/subprocess.py:761: ResourceWarning: subprocess 15501 is 
still running
  ResourceWarning, source=self)

This is probably related to http://bugs.python.org/issue27069

--
components: Library (Lib)
messages: 283317
nosy: levkivskyi
priority: normal
severity: normal
status: open
title: ResourceWarning when imorting antigravity in 3.6
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

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list

[R. David Murray]

R. David Murray added the comment:

Ah, I see.  (", " defparameter)* should instead be "+", or whatever the BNF 
equivalent is.

--

___
Python tracker 

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

[issue28979] What's New entry on compact dict mentions "faster" implementation

[Brendan Donegan]

Brendan Donegan added the comment:

Agree. Patch provided.

--
keywords: +patch
nosy: +brendan-donegan
Added file: http://bugs.python.org/file45919/whatsnew36.patch

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

According to the original description, "either all or none...",what does 'none' 
represent?

--

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[Brendan Donegan]

Brendan Donegan added the comment:

None represents the case where the if statement is false

On Thu, 15 Dec 2016 at 20:40 woo yoo  wrote:

>
> woo yoo added the comment:
>
> According to the original description, "either all or none...",what does
> 'none' represent?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--
nosy: +brendand

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

"either all or none of the print() calls are executed",I think the 'none' 
describes the number of the calls to be executed.

--

___
Python tracker 

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

[issue28979] What's New entry on compact dict mentions "faster" implementation

[Roundup Robot]

Roundup Robot added the comment:

New changeset 181453f9a0c4 by Victor Stinner in branch '3.6':
Issue #28979: Fix What's New in Python 3.6, dict
https://hg.python.org/cpython/rev/181453f9a0c4

--
nosy: +python-dev

___
Python tracker 

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

[issue28979] What's New entry on compact dict mentions "faster" implementation

[STINNER Victor]

STINNER Victor added the comment:

@Ned: Would you be ok to cherry-pick 181453f9a0c4 in Python 3.6.0?

--
nosy: +haypo

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[Brendan Donegan]

Brendan Donegan added the comment:

I think the consensus is that the wording is correct. If you can come up
with text that is clearer, and still correct, please do submit a patch.

On Thu, 15 Dec 2016 at 20:50 woo yoo  wrote:

>
> woo yoo added the comment:
>
> "either all or none of the print() calls are executed",I think the 'none'
> describes the number of the calls to be executed.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue28979] What's New entry on compact dict mentions "faster" implementation

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +inada.naoki, ned.deily, serhiy.storchaka, yselivanov

___
Python tracker 

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

[issue27069] webbrowser creates zombi processes in the background mode

[Brendan Donegan]

Brendan Donegan added the comment:

This appears to be Firefox specific? At least:

b = webbrowser.get("chromium-browser")
b.open("https://bugs.python.org/issue26741";)

returns simply:

True

With no exception

--
nosy: +brendan-donegan

___
Python tracker 

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

[issue28980] ResourceWarning when imorting antigravity in 3.6

[Brendan Donegan]

Brendan Donegan added the comment:

I think this is essentially a duplicate of http://bugs.python.org/issue27069, 
or at least fixing that will fix this (as the exception is caused by the 
webbrowser.open() call)

--
nosy: +brendan-donegan

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[woo yoo]

woo yoo added the comment:

In fact, I'm a newcomer to Python. When i have experimented with those 
description interactively using Python interpreter, i got confused.

I don't know how to submit a patch.If the description were changed by me,it 
would be：
>if xis equivalent to
>if xprint(x)
>print(y)
>print(z)

--

___
Python tracker 

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

[issue28976] incorrect description that dose not conform to the actual behavior

[R. David Murray]

R. David Murray added the comment:

As I said, the language reference is a specification, not a tutorual.  The text 
as written is clear technical English.  You are correct that 'none' refers to 
the number of statements executed, but 'none' are executed when the statement 
is false, and 'all' are executed when the statement is true.  The fact that 
execution of a suite may be interrupted by an exception is covered elsewhere in 
the language reference and it would not enhance the documentation to repeat it 
here.

If other core developers think putting in the example is appropriate I'm not 
going to object, but I don't think they will.

--

___
Python tracker 

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