[issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable

[Peter Eckersley]

Peter Eckersley added the comment:

OK, here's another solution following paul.j3's suggestion. I think this is 
much better:

https://gist.github.com/pde/817a00378d3f6ed73747dfffce323ae5

Tests & documentation included.

--

___
Python tracker 

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

[issue28724] Add method send_io, recv_io to the socket module.

[Christian Heimes]

Christian Heimes added the comment:

Take your time, feature freeze for 3.7 is in about 18 months from now.

--

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I don't understand why test_showwarnmsg_missing was added. Why deleting 
warnings._showwarnmsg should be supported?

I would rename _showwarning to _showwarning_orig for accenting it's purpose. It 
is used only for checking if showwarning was replaced by the user.

--

___
Python tracker 

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

[issue27971] utf-16 decoding can't handle lone surrogates

[Christoph Reiter]

Changes by Christoph Reiter :


--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue28089] asyncio: Document that TCP_NODELAY is now used by default

[Roundup Robot]

Roundup Robot added the comment:

New changeset 726308cfe3b5 by Victor Stinner in branch '3.6':
catch_warnings() calls showwarning() if overriden
https://hg.python.org/cpython/rev/726308cfe3b5

--
nosy: +python-dev

___
Python tracker 

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

[issue28089] asyncio: Document that TCP_NODELAY is now used by default

[Roundup Robot]

Roundup Robot added the comment:

New changeset 150d36dbe3ba by Victor Stinner in branch '3.6':
warnings: Fix the issue number
https://hg.python.org/cpython/rev/150d36dbe3ba

--

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 150d36dbe3ba by Victor Stinner in branch '3.6':
warnings: Fix the issue number
https://hg.python.org/cpython/rev/150d36dbe3ba

--
nosy: +python-dev

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[STINNER Victor]

STINNER Victor added the comment:

I pushed a more complete version of my patch:

New changeset 726308cfe3b5 by Victor Stinner in branch '3.6':
catch_warnings() calls showwarning() if overriden
https://hg.python.org/cpython/rev/726308cfe3b5


I dislike pushing a different change than the reviewed change, but I was in a 
hurry for the Python 3.6.0 release :-/ Sorry about that.

Please double-check the pushed change!

(I used the wrong issue number, fixed in the following commit.)


The final change also fixes the bug reported by Martin:

Martin: "Actually, I found a regression. Looks like you also need to cancel any 
showwarning() function set by the user:"

I fixed it in catch_warnings() with these lines:

# Reset showwarning() to the default implementation to make sure
# that _showwarnmsg() calls _showwarnmsg_impl()
self._module.showwarning = self._module._showwarning

It also added a new unit test for this scenario.


Serhiy Storchaka: "I don't understand why test_showwarnmsg_missing was added. 
Why deleting warnings._showwarnmsg should be supported?"

I don't know well the warnings module. The interactions between the C _warnings 
module and the Python warnings module are complex. I didn't want to break the 
backward compatibility, and *technically*, it is possible to delete 
warnings.showwarning() and warnings.warn("msg") still writes the message into 
stderr! So I decided to support this corner case, for the backward 
compatibility.

Code:
---
import warnings
warnings.warn("with showwarning")
del warnings.showwarning
warnings.warn("without showwarning")
---

Output on Python 3.5 (before my showarnmsg() changes):
---
x.py:2: UserWarning: with showwarning
  warnings.warn("with showwarning")
x.py:4: UserWarning: without showwarning
  warnings.warn("without showwarning")
---

Hum, but maybe we should decorate test_showwarnmsg_missing() with @cpython_only 
to announce that it's a side effect of the implementation, it's not part of the 
"Python specification".


Serhiy Storchaka: "I would rename _showwarning to _showwarning_orig for 
accenting it's purpose. It is used only for checking if showwarning was 
replaced by the user."

Sorry, I suck at naming things :-) Feel free to rename it (after the 3.6.0 
release).


By the way, I'm still interested to make showwarnmsg() public in Python 3.7. 
IMO it's interesting to give access to the new source parameter to custom 
warning loggers. And it will allow to more easily extend warnings with new 
parameters (it was the whole purpose of the issue #26568).


I keep the issue open so someone can still review the pushed change.

--

___
Python tracker 

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

[issue27030] Remove deprecated re features

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch that partially reverts changes of issue27030. It allows using 
unknown escapes in re.sub() replacement template, but they are deprecated and 
will be errors in 3.7.

If this is good to you Barry, and Ned allows, it can be committed in 3.6 only.

But this could delay adding support of new escapes (like \xXX, \u, etc) in 
replacement templates.

--
assignee: serhiy.storchaka -> ned.deily
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file45774/re-sub-allow-unknown-escapes.patch

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[STINNER Victor]

STINNER Victor added the comment:

Julien reviewed the pushed change and asked me questions on IRC:

* "nonlocal log": this change is unrelated to the fix, I should have done that 
in a separated change, sorry, I cannot resist to refactoring :-) The change has 
no effect, it's more cosmetic to help reviewers: "log is not a local variable 
nor a global variable, it's a "non-local" variable".

* inner function (calling log.append) renamed from "showarnmsg()" to 
"showarnmsg_logger()": it's to help debugging. It's a pain when two different 
functions completely different have the same name, especially for the warnings 
where many functions are overriden at runtime. Moreover, the function is now 
used for _showwarnmsg_impl instead of _showwarnmsg, so I also renamed the 
function to avoid confusion.

--

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch that cleans up the code.

--
Added file: http://bugs.python.org/file45775/showwarning-tidy.patch

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[STINNER Victor]

STINNER Victor added the comment:

rename.patch: Big patch to rename function parameters.

--
Added file: http://bugs.python.org/file45776/rename.patch

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

os.scandir() returns an iterable object that should not be used
  from multiple threads.  Doing so can e.g. cause one thread to
  close the dirp while another thread is still using it.  This is
  likely to crash.  Similarly, the test for (!iterator->dirp) at
  the start of ScandirIterator_iternext() is only done once even
  if the following loop runs two or three times because of "." or
  ".." entries.

--

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(C2) os.scandir() direntry objects should not have stat() called from two
  threads concurrently.  It will make two stat objects and leak one of
  them.

--

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(C3) _PyGen_yf() checks the opcode at [f_lasti + 1], which is the next
  opcode that will run when we resume the generator: either it is the
  opcode following the YIELD, or it is exactly YIELD_FROM.  It is not
  possible at the moment to write Python code that compiles to a YIELD
  immediately followed by YIELD_FROM, so by chance the two cases are
  correctly distinguished.  *However,* the discussion so far assumes
  that the generator is not currently running.  If it is (which probably
  doesn't occur in reasonable Python code but can be constructed
  manually), then this checks for example the byte/word that describes
  the argument of the currently running opcode.  If we're very unlucky
  this byte has the value 72, which is YIELD_FROM.  Total nonsense and
  crashes follow.

--

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
  to a refcount crash.  It does this::

 old_mro = type->tp_mro;
 ...mro_invoke()...  /* might cause reentrance */
 type->tp_mro = new_mro;
 ...
 Py_XDECREF(old_mro);

  This last XDECREF drops the reference held by the previous value of
  ``type->tp_mro`` after we changed it.  But ``type->tp_mro`` might have
  changed because of mro_invoke(), which calls pure Python code.  If it
  did change, then old_mro is no longer the old value of
  ``type->tp_mro``.  The wrong object gets decrefed.

--

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

New submission from Armin Rigo:

As discussed on python-dev, I am creating omnibus issues from the lists of 
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues 
that I found while developing Python 3.5.2 support for PyPy.  These occur with 
CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the crashers.

--
messages: 282518
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 crashers (from PyPy)
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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(C4) faulthandler: register(): the signal handler, faulthandler_user(),
  changes errno in faulthandler_dump_traceback() but fails to restore it
  if chain=False.  This can rarely cause random nonsense in the main
  program.

--

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(C5) setting f_lineno didn't evolve when the rest of the bytecodes evolved,
  which means it is not safe any more::

import sys

def f():
try:
raise ValueError# line 5
except ValueError:
print(42)   # line 7

def my_trace(*args):
print(args)
if args[1] == 'line':
f = args[0]
if f.f_lineno == 5:
f.f_lineno = 7
return my_trace

sys.settrace(my_trace)
f()
sys.settrace(None)

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

New submission from Armin Rigo:

As discussed on python-dev, I am creating omnibus issues from the lists of 
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues 
that I found while developing Python 3.5.2 support for PyPy.  These occur with 
CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the bugs that are wrong according to 
documentation, or at least clearly (imo) unexpected behavior.

--
messages: 282526
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 non-segfaulting bugs (from PyPy)
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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
  to a refcount crash.  It does this::

 old_mro = type->tp_mro;
 ...mro_invoke()...  /* might cause reentrance */
 type->tp_mro = new_mro;
 ...
 Py_XDECREF(old_mro);

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B1) on modern Linux: if the first call in the process to
  socketpair() ends in a EINVAL, then cpython will (possibly wrongly)
  assume it was caused by SOCK_CLOEXEC and not use SOCK_CLOEXEC at all
  in the future

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B3) re.sub(b'y', bytearray(b'a'), bytearray(b'xyz')) -> b'xaz'

  re.sub(b'y', bytearray(b'\\n'), bytearray(b'xyz')) -> internal TypeError

--

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


--
Removed message: http://bugs.python.org/msg282524

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B2) fcntl.ioctl(x, y, buf, mutate_flag): mutate_flag is there for the case
  of buf being a read-write buffer, which is then mutated in-place.
  But if we call with a read-only buffer, mutate_flag is ignored (instead
  of rejecting a True value)---ioctl(x, y, "foo", True) will not actually
  mutate the string "foo", but the True is completely ignored.  (I think
  this is a bug introduced during the Argument Clinic refactoring.)

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B4) if you have a stack of generators where each is in 'yield from' from
  the next one, and you call '.next()' on the outermost, then it enters
  and leaves all intermediate frames.  This is costly but may be
  required to get the sys.settrace()/setprofile() hooks called.
  However, if you call '.throw()' or '.close()' instead, then it uses a
  much more efficient way to go from the outermost to the innermost
  frame---as a result, the enter/leave of the intermediate frames is not
  invoked.  This can confuse coverage tools and profilers.  For example,
  in a stack ``f1()->f2()->f3()``, vmprof would show f3() as usually
  called via f2() from f1() but occasionally called directly from f1().

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B5) this is an old issue that was forgotten twice on the
  issue tracker: ``class C: __new__=int.__new__`` and ``class C(int):
  __new__=object.__new__`` can each be instantiated, even though they
  shouldn't.  This is because ``__new__`` is completely ignored if it is
  set to any built-in function that uses ``tp_new_wrapper`` as its C code
  (many of the built-in types' ``__new__`` are like that).
  http://bugs.python.org/issue1694663#msg75957,
  http://bugs.python.org/issue5322#msg84112.  In (at least) CPython 3.5,
  a few classes work only thanks to abuse of this bug: for example,
  ``io.UnsupportedOperation.__new__(io.UnsupportedOperation)`` doesn't
  work, but that was not noticed because ``io.UnsupportedOperation()``
  mistakenly works.

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B6) this program fails the check for no sys.exc_info(), even though at
  the point this assert runs (called from the <== line) we are not in
  any except/finally block.  This is a generalization of
  test_exceptions:test_generator_doesnt_retain_old_exc::

import sys

def g():
try:
raise ValueError
except ValueError:
yield 1
assert sys.exc_info() == (None, None, None)
yield 2

gen = g()

try:
raise IndexError
except IndexError:
assert next(gen) is 1
assert next(gen) is 2# <==

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B7) frame.clear() does not clear f_locals, unlike what a test says
  (Lib/test/test_frame.py)::

def test_locals_clear_locals(self):
# Test f_locals before and after clear() (to exercise caching)
f, outer, inner = self.make_frames()
outer.f_locals
inner.f_locals
outer.clear()
inner.clear()
self.assertEqual(outer.f_locals, {})
self.assertEqual(inner.f_locals, {})

  This test passes, but the C-level PyFrameObject has got a strong
  reference to f_locals, which is only updated (to be empty) if the
  Python code tries to read this attribute.  In the normal case,
  code that calls clear() but doesn't read f_locals afterwards will
  still leak everything contained in the C-level f_locals field.  This
  can be shown by this failing test::

import sys

def g():
x = 42
return sys._getframe()

frame = g()
d = frame.f_locals
frame.clear()
print(d)
assert d == {}   # fails!  but 'assert d is frame.f_locals' passes,
 # which shows that this dict is kept alive by
 # 'frame'; and we've seen that it is non-empty
 # as long as we don't read frame.f_locals.

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B8) also discussed in connection with https://bugs.python.org/issue28427

  weak dicts (both kinds) and weak sets have an implementation of
  __len__ which doesn't give the "expected" result on PyPy, and in some
  cases on CPython too.  I'm not sure what is expected and what is not.
  Here is an example on CPython 3.5.2+ (using a thread to run the weakref
  callbacks only, not to explicitly inspect or modify 'd')::

import weakref, _thread
from queue import Queue

queue = Queue()
def subthread(queue):
while True:
queue.get()
_thread.start_new_thread(subthread, (queue,))

class X:
pass
d = weakref.WeakValueDictionary()
while True:
x = X()
d[52] = x
queue.put(x)
del x
while list(d) != []:
pass
assert len(d) == 0  # we've checked that list(d)==[], but this may fail

  On CPython I've seen the assert fail only after editing the function
  WeakValueDictionary.__init__.remove() to add ``time.sleep(0.01)`` as
  the first line.  Otherwise I guess the timings happen to make that test
  pass.

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B9) CPython 3.5.2: this ``nonlocal`` seems not to have a reasonable
  effect (note that if we use a different name instead of ``__class__``,
  this example correctly complain that there is no binding in the outer
  scope of ``Y``)::

class Y:
class X:
nonlocal __class__
__class__ = 42
print(locals()['__class__']) # 42
print(__class__) # but this is a NameError

--

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(B10) Follow-up on issue #25388: running ``python x.py`` if x.py contains
  the following bytes...

  * ``b"#\xfd\n"`` => we get a SyntaxError: Non-UTF-8 code
  * ``b"# coding: utf-8\n#\xfd\n"`` => we get no error!

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(S4) if you write ``from .a import b`` inside the Python prompt, or in
  a module not in any package, then you get a SystemError(!) with an
  error message that is unlikely to help newcomers.

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

New submission from Armin Rigo:

As discussed on python-dev, I am creating omnibus issues from the lists of 
crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues 
that I found while developing Python 3.5.2 support for PyPy.  These occur with 
CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the "strange behaviors" and some of them, or 
possibly most, will turn out to be my own feelings only and not python-dev's, 
which is fine by me.

--
messages: 282537
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 strange-behavior issues (from PyPy)

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(S3) hash({}.values()) works (but hash({}.keys()) correctly gives
  TypeError).  That's a bit confusing and, as far as I can tell, always
  pointless.  Also, related: d.keys()==d.keys() but
  d.values()!=d.values().

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(S1) ceval.c: GET_AITER: calls _PyCoro_GetAwaitableIter(), which might
  get an exception from calling the user-defined __await__() or checking
  what it returns; such an exception is completely eaten.

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(S2) argument clinic turns the "bool" specifier into
  PyObject_IsTrue(), accepting any argument whatsoever.  This can easily
  get very confusing for the user, e.g. after messing up the number of
  arguments.  For example: os.symlink("/path1", "/path2", "/path3")
  doesn't fail, it just considers the 3rd argument as some true value.

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Armin Rigo added the comment:

(S5) pep 475: unclear why 'os.fchmod(fd)' retries automatically when
  it gets EINTR but the otherwise-equivalent 'os.chmod(fd)' does not.
  (The documentation says they are fully equivalent, so someone is
  wrong.)

--

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Added comments on Rietveld.

I think we can keep "func" instead of "callable" in the source code for 
decreasing the number of changes.

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


--
type:  -> behavior

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


--
type:  -> behavior

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Armin Rigo]

Changes by Armin Rigo :


--
type:  -> crash

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

About (B10) see issue18961 and issue25937.

--
dependencies: +DIfference between utf8 and utf-8 when i define python source 
code encoding., Non-UTF8 encoding line
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

About (B3): Only str and bytes are supported. The support of bytearray 
templates is not documented and is not guarantied.

--

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

(S4) was fixed in 3.6 (issue18018). But the fix was not applied to 3.5.

--
dependencies: +SystemError: Parent module '' not loaded, cannot perform 
relative import
nosy: +brett.cannon, serhiy.storchaka

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

(S2) is related not to Argument Clinic itself, but to the 'p' format unit added 
in 3.3 (issue14705).

--

___
Python tracker 

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

[issue28886] Deprecated abstract base class (abc) decorators do not raise DeprecationWarning

[John Hagen]

New submission from John Hagen:

In the abc module (https://docs.python.org/3/library/abc.html) the following 
decorators have been deprecated since Python 3.3:

- abstractclassmethod
- abstractstaticmethod
- abstractproperty

But if you run the following example code using Python 3.5.2 with -Werror, no 
DeprecationWarnings are thrown. Throwing DeprecationWarnings will help make it 
more clear that these properties should not be used. PyCharm, for example, will 
strikethrough the usage of methods that throw DeprecationWarning so that even 
new users will be notified quickly even if they don't run with -Werror.


import abc


class Base(abc.ABC):
@abc.abstractclassmethod
def abstract_class(cls):
pass

@abc.abstractstaticmethod
def abstract_static():
pass

@abc.abstractproperty
def abstract_property(self):
pass


class Child(Base):
@classmethod
def abstract_class(cls):
print('Abstract class method')

@staticmethod
def abstract_static():
print('Abstract static method')

@property
def abstract_property(self):
return 'Abstract property'


child = Child()
child.abstract_class()
child.abstract_static()
print(child.abstract_property)

--
components: Library (Lib)
messages: 282548
nosy: John Hagen
priority: normal
severity: normal
status: open
title: Deprecated abstract base class (abc) decorators do not raise 
DeprecationWarning
type: behavior
versions: 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

[issue28879] smtplib RFC 5322 date header missing

[Henning von Bargen]

Henning von Bargen added the comment:

I can give a little more information.
First, I created a very simple stand-alone test script (for Python >= 2.6):

#!/bin/env python
# -*- coding: utf-8 -*-

import smtplib

# Adjust these!

HOST = "smtp.nowhere.local"
PORT = 25

from_name = u"Test Python smtplib"
from_addr = u"valid.address@nowhere.local"

to_name = u"Python Test Recipient"
to_addr = u"some.addr...@yourcompany.com"

subject = "Test Nr. 1"
smtp = smtplib.SMTP(HOST, PORT, timeout=10)
smtp.set_debuglevel(1)
smtp.sendmail(from_addr, [to_addr], subject)
smtp.quit()


This script shows the same behavior, which shows that the problem is not 
related to my program, but it is indeed a problem with smtplib.py.

Unfortunately, I could only test this with Python 2.6, because I'm not allowed 
to install Python 2.7 on that machine; OTOH I have to run it on that machine to 
have access to the mail server.

The observations are:

* The message is sent (I sent it to one of my email addresses).

* Spam Assassin flags the message with additional header lines: X-Amavis-Alert: 
BAD HEADER SECTION, Missing required header field: "Date"
X-Spam-Status: No, score=-2.36 ...
* In some cases the message is silently dropped, because the missing date 
header caues a negative score; which in turn may be bad enough to classify it 
as spam, depending on the content.
* The SMTP server used here is Postfix.
* When I receive the message, a Date header is present (obviously it has been 
inserted during the message's journey through the internet).

Personal opinion: 
I think classifying a message as spam just because a practically useless header 
field is missing is bad behavior of Spam Assaassin.
Nevertheless, the standard library should try to conform to RFC 5322.
It is good practise to be forgiving while reading but pedantic while writing.

--

___
Python tracker 

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

[issue28887] Login with Google not working on PyPi site

[WayEasy Corporation]

New submission from WayEasy Corporation:

When I try to login with Google I don't get an error but I'm not logged in 
either.

--
messages: 282550
nosy: WayEasy Corporation
priority: normal
severity: normal
status: open
title: Login with Google not working on PyPi site
type: performance

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[Roundup Robot]

Roundup Robot added the comment:

New changeset e6ad41a3f3bd by Victor Stinner in branch 'default':
Uniformize argument names of "call" functions
https://hg.python.org/cpython/rev/e6ad41a3f3bd

--
nosy: +python-dev

___
Python tracker 

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

[issue28838] Uniformize argument names of "call" functions (C API)

[STINNER Victor]

STINNER Victor added the comment:

I pushed a change which is rename.patch with fixes on comments in abstract.h. 
It seems like comments were no more revelant or moved to random places. I moved 
many comments, rewrote some of them, etc. Some comments were wrong like "This 
is the equivalent of the Python expression: o.method(args)", it's 
"o.method(*args)" in fact. Serhiy catched this mistake, it should now be fixed.

I chose to push this large change, instead of having another round of review, 
because it's tricky to handle such large changes. I suggest to push following 
changes if you still see issues.

I also wanted to push it quickly because I have pending changes modifying the 
same parts of the code in my queue :-)

Thanks for reviews Serhiy! Very useful, as usual ;-)


Serhiy: "I think we can keep "func" instead of "callable" in the source code 
for decreasing the number of changes."

I prefer to "fix" it as well, the purpose of the issue is to uniformize 
everything: .c files, .h files and .rst documentation.

--

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

As I implied but did not say explicitly, this is the expected behavior of 
smtplib.  You are responsible for adding any headers to the message that you 
want smtplib to send.  In particular, the 'sendmail' method takes a string to 
send, and smtplib does not modify it except for cr/lf transformation.  smtplib 
does not itself understand RFC5322 message syntax.

We can, however, add a Date header in the new send_message method of the 
python3 email library, because it accepts a Message object, and smtplib can use 
the knowledge the Message object encapsulates to check for the Date header and 
add one if it is missing.  That's why I've left this issue open.  I have now 
adjusted versions accordingly (ie: this is not a bug in python2.7, it is an 
enhancement request for Python3).  Sorry I wasn't clear about this earlier.

Hmm.  Actually, we can argue that it is an RFC compliance issue, as you have 
suggested, and change it in 3.6 as well, since it isn't likely to break 
anyone's working code.  So I'll put 3.6 in the versions unless someone objects 
to that logic.  But even after this is changed in python3, the smtplib sendmail 
method will not add a Date header, only the send_message method.

--
keywords: +easy
title: smtplib RFC 5322 date header missing -> smtplib send_message should add 
Date header if it is missing, per RFC5322
type:  -> 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

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

[R. David Murray]

R. David Murray added the comment:

"Uniformize" isn't really an English word :)

--
nosy: +r.david.murray
title: Uniformize argument names of "call" functions (C API) -> Using 
consistent naming for arguments of "call" functions (C API)

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

Oh, you have mixed up comments! In headers descriptions are written after 
function declarations. You have moved some comments and now some descriptions 
are placed below the corresponding declaration, and some descriptions are 
placed above. Now it is not clear to what function every comment is related.

You should either revert your changes or change *all* headers by moving *all* 
descriptions above corresponding declarations. That would be very large patch, 
and I doubt it will be approved.

Please don't make such large changes without a review.

--

___
Python tracker 

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

[issue27030] Remove deprecated re features

[Ned Deily]

Ned Deily added the comment:

It is unfortunate that the deprecation note did not explicitly mention 
replacement templates as well as regexp patterns.  While there are good 
arguments to be made for either case, I think it makes more sense to treat the 
replacement template as following the rules for strings rather than for regexps 
which would argue for making the proposed change to cause only a deprecation 
warning in templates for 3.6 - although I'm not happy about making such a 
change at the last minute.  Serhiy, please push to 3.6 for rc1.  There should 
also be a note in the What's New for 3.6 document.

--
assignee: ned.deily -> serhiy.storchaka
stage: patch review -> commit review

___
Python tracker 

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

[issue27030] Remove deprecated re features

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1b162d6e3d01 by Serhiy Storchaka in branch '3.6':
Issue #27030: Unknown escapes in re.sub() replacement template are allowed
https://hg.python.org/cpython/rev/1b162d6e3d01

New changeset 5904d2ced3d8 by Serhiy Storchaka in branch 'default':
Merge documentation for issue #27030 from 3.6.
https://hg.python.org/cpython/rev/5904d2ced3d8

--

___
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

[Eric Lafontaine]

Eric Lafontaine added the comment:

Hi,  Not sure this is where the comment goes...

I work with the smtplib and email libraries.  I understand Henning von Bargen 
when he say that we should have a way to support RFC 5322 without asking the 
user to understand how to support it.  The issue is that the SMTP protocol is 
NOT the protocol that format the e-mail.  SMTP is the protocol that identify 
the "from", the "to", start encryption and finally transfert the message.  The 
actual e-mail content is all passed inside the SMTP "DATA" Command.  I strongly 
believe that an email should not be modified by a SMTP library.

the discussion should be focused on trying to make it available to the user 
WITHOUT changing the current behavior of email.message class.  


In other words, I disagree to change the SMTPlib module and suggest that it's 
how you construct your email in the first place that should consider it;
class MessageRfc5322(email.message.Message):
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
if self.get('Date', None) is None:
self.add_header('Date', email.utils.formatdate())

msg = email.message_from_string(string_message, MessageRfc5322)



But, that's my opinion as someone who uses the smtplib and email library but 
also need to support rfc822 clients...

--
nosy: +Eric Lafontaine

___
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 69c7451c3ec1 by Victor Stinner in branch 'default':
Issue #28838: Fix weird indentation of abstract.h
https://hg.python.org/cpython/rev/69c7451c3ec1

--

___
Python tracker 

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

[issue28888] Installer fails when newer version of CRT is pending installation

[Steve Dower]

New submission from Steve Dower:

We just discovered an issue where CPython install can fail on Windows 8, 8.1 
and Server 2012.

* do not install the recommended UCRT update
* install any other Windows Update that requires a reboot
* install the *latest* VC Redist and do not reboot
* install CPython

Because of the pending reboot, the UCRT update in the VC Redist will be queued 
but not installed. When we install CPython, because we don't find the UCRT we 
will try and install it, but because we install a slightly older version than 
the latest VC Redist we get 0x80240017 WU_E_NOT_APPLICABLE returned. Since this 
is an error code, we abort installation.

However, the correct action to take here is to continue installation, but 
trigger a mid-setup reboot before doing any of the custom actions that require 
Python to be installed (bootstrap pip, precompile stdlib) or require a reboot 
after install. We also need to do a reboot if our own installation of the UCRT 
requests it, since we may be the ones to queue the update.

At the very least, continuing with installation, failing the custom actions and 
telling the user to reboot and repair Python would also be less impactful than 
aborting. But I believe we can set it up to do that automatically.

Ned FYI, but I won't be forcing this in to 3.6.0. The workaround is fine for 
interactive installs (reboot your machine and try again) - it's only a problem 
when Python is being chained into a larger install (e.g. Visual Studio, or an 
automated deployment).

--
assignee: steve.dower
components: Windows
messages: 282560
nosy: ned.deily, paul.moore, steve.dower, tim.golden, zach.ware
priority: high
severity: normal
stage: needs patch
status: open
title: Installer fails when newer version of CRT is pending installation
type: behavior
versions: 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

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

[STINNER Victor]

STINNER Victor added the comment:

I pushed another large patch to "fix" the indentation of abstract.h. I would 
prefer to also have this "reindent" change on review, but our reviewing tool 
doesn't support patch series :-(


Attached cleanup.patch reformats deeply the header file to use the same style 
for all comments, use the same style used in other Python headers. IMO it makes 
the header file more consistent with other header files and it makes the file 
more readable.


R. David Murray (r.david.murray):
> Uniformize" isn't really an English word :)

Oh, it's a frenglish word in this case :-) Good to know.


Serhiy Storchaka: "You have moved some comments and now some descriptions are 
placed below the corresponding declaration, and some descriptions are placed 
above. Now it is not clear to what function every comment is related."

It don't think that my change makes abstract.h worse, some comments were far 
from their declaration, and there is was no unique style for comments. It's a 
mess.


Serhiy: "You should either revert your changes or change *all* headers by 
moving *all* descriptions above corresponding declarations."

My plan is to rewrite completely abstact.h, this file annoys me since many 
months :-)


"That would be very large patch, and I doubt it will be approved."

Why not?


"Please don't make such large changes without a review."

You reviewed rename.patch, I only made tiny changes after this patch. As I 
explained, it's hard to work on such large patch.

--
Added file: http://bugs.python.org/file45777/cleanup.patch

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Brett Cannon]

Brett Cannon added the comment:

Victor & Yury for S1.

--
nosy: +haypo, yselivanov

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[Brett Cannon]

Brett Cannon added the comment:

Serhiy's patch LGTM.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue28883] Python 3.5.2 crashers (from PyPy)

[Brett Cannon]

Brett Cannon added the comment:

Victor for C4.

--
nosy: +brett.cannon, haypo

___
Python tracker 

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

[issue27629] Cannot create ssl.SSLSocket without existing socket

[nemunaire]

nemunaire added the comment:

The documentation already recommends to use SSLContext.wrap_socket(), but it 
didn't cover all use cases. Eg. I use multiple inheritance to handle both 
socket and SSLSocket inside a factory pattern, in order to override some 
methods defined in both classes. If I use SSLContext.wrap_socket(), it erases 
my overrides.

As the patch add some tests on this feature, this is no more dead code; however 
I let you decide the future of this issue: I've updated my patch with your 
remarks if you want to include it (it applies from Python 3.3 to current Python 
3.6).

--
Added file: 
http://bugs.python.org/file45778/fix_sslsocket_init_without_socket_3_3-3_6.patch

___
Python tracker 

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

[issue27629] Cannot create ssl.SSLSocket without existing socket

[nemunaire]

Changes by nemunaire :


Removed file: 
http://bugs.python.org/file43927/fix_sslsocket_init_without_socket_3_3-3_6.patch

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Yury Selivanov]

Yury Selivanov added the comment:

I'll take a look at s1 later tonight

--

___
Python tracker 

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

[issue28889] IDLE needs the ability to pass in command-line arguments

[Raymond Hettinger]

New submission from Raymond Hettinger:

[--- Feature request posted on behalf of Balakrishnan Sakthidharan ---]

IDLE lets you run scripts with F5.

What is needs is an F6 that opens a dialog box and asks for command-line 
arguments.  This will help develop and test command line scripts in the IDE.

  F6 -q5 -v=8 somefile.txt

--
assignee: terry.reedy
components: IDLE
messages: 282567
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE needs the ability to pass in command-line arguments
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

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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> It don't think that my change makes abstract.h worse, some comments were far
> from their declaration, and there is was no unique style for comments. It's
> a mess.

Seems most of comments that did not follow common style are your comments to 
"fast call" functions. It would be better to fix only that comments.

> "That would be very large patch, and I doubt it will be approved."
> Why not?

Because it breaks "hg annotation" and makes harder researching the history of 
the file. That harms the workflow of other developers. Ask on Python-Dev before 
making such larger and questionable changes.

> You reviewed rename.patch, I only made tiny changes after this patch.

Reviewed patch did not contain committed changes. That changes are not tiny.

--

___
Python tracker 

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

[issue28886] Deprecated abstract base class (abc) decorators do not raise DeprecationWarning

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Not all features deprecated in the source should be deprecated in the code. May 
be reasons for not doing this in the code.

Adding the deprecation in maintained releases can introduce a regression. It 
seems to me that these decorators are not broken. They is just other, more 
preferable way to write the same, with the combination of other decorators.

--
nosy: +Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, eric.araujo, 
eric.snow, ncoghlan, python-dev, serhiy.storchaka, stutzbach

___
Python tracker 

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

[issue28890] logging.handlers: Document that QueueListener is a daemon thread

[Julien Castiaux]

Changes by Julien Castiaux :


--
assignee: docs@python
components: Documentation
nosy: Julien Castiaux, docs@python
priority: normal
severity: normal
status: open
title: logging.handlers: Document that QueueListener is a daemon thread
type: enhancement
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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[Roundup Robot]

Roundup Robot added the comment:

New changeset aaee06743c61 by Ned Deily in branch '3.6':
Issue #28835: Tidy previous showwarning changes based on review comments.
https://hg.python.org/cpython/rev/aaee06743c61

New changeset 7bca3bf6401a by Ned Deily in branch 'default':
Issue #28835: merge from 3.6
https://hg.python.org/cpython/rev/7bca3bf6401a

--

___
Python tracker 

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

[issue28835] Change in behavior when overriding warnings.showwarning and with catch_warnings(record=True)

[Ned Deily]

Ned Deily added the comment:

Thanks everyone for getting this resolved for 360rc1!

--
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.7

___
Python tracker 

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

[issue27030] Remove deprecated re features

[Ned Deily]

Ned Deily added the comment:

Thanks, Serhiy, for reverting the error handling for 3.6.0 (in 3.6.0rc1).  I'm 
going to mark this as closed.  Issue28450 is still open at the moment regarding 
the documentation and possible 3.7 changes.

--
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.7

___
Python tracker 

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

[issue28450] Misleading/inaccurate documentation about unknown escape sequences in regular expressions

[Ned Deily]

Ned Deily added the comment:

Note that 1b162d6e3d01 in Issue27030 (for 3.6.0rc1) has changed the behavior 
for re.sub replacement templates to produce a deprecation warning in 3.6 while 
still being treated as an error in 3.7.

--

___
Python tracker 

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

[issue24254] Make class definition namespace ordered by default

[Ned Deily]

Ned Deily added the comment:

What's the status of this issue?  It's still marked as a "deferred blocker" for 
3.6.

--
nosy: +ned.deily

___
Python tracker 

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

[issue28339] "TypeError: Parameterized generics cannot be used with class or instance checks" in test_functools after importing typing module

[Ned Deily]

Ned Deily added the comment:

This is still marked as "deferred blocker". Is there anything more that needs 
to be done for 3.6.0?  I'm assuming not.

--

___
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:
> Seems most of comments that did not follow common style are your comments to  
> "fast call" functions. It would be better to fix only that comments.

I would like to modify abstract.h because its weird style annoy me for years. I 
would like to make the header consistent with all other headers.

I checked unicodeobject.h, code.h, frameobject.h, floatobject.h, etc.: comments 
are always before declaration.

About "fast calls" in abstract.h, sorry, it's my fault. When I added new code, 
I used the same style than all other files. I didn't notice that abstract.h has 
a special style. That's why I would like to make it consistent again.


Serhiy:
> Reviewed patch did not contain committed changes.

You wrote on the review that a comment is misplaced: "The comment is related to 
PyObject_Call() declared 85 lines above."

That's why I took the opportunity of a refactoring change to fix comments.


Serhiy:
> That changes are not tiny.

Between rename.patch and the pushed change e6ad41a3f3bd, I only moved 5 
comments: see attached rename_pushed.patch which is the diff between the two 
patches.

For me, it was obvious that the comment must be before the declaration, since 
it is the style used in all other Python headers. Sorry, I didn't expect that 
you didn't want to change that. I misunderstood your comment on the review.

--
Added file: http://bugs.python.org/file45779/rename_pushed.patch

___
Python tracker 

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

[issue28810] Document bytecode changes in 3.6

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Because nobody proposed a patch, here is my attempt. Following patch documents 
opcodes CALL_FUNCTION, CALL_FUNCTION_KW and CALL_FUNCTION_EX.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45780/docs-call-function-opcodes.patch

___
Python tracker 

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

[issue28882] RFC: Slice confusing with negative strides and the 0th element.

[Josh Rosenberg]

Josh Rosenberg added the comment:

I find this report nigh incomprehensible, but I will admit that I can't seem to 
find any good explanations of the extended slicing rules in the Python docs.

The tutorial covers slicing, but, AFAICT, it never mentions extended slicing at 
all, not in 3.1.2 or 3.1.3 (Strings and Lists introduction), nor anywhere in 
section 5 (Data structures). 3.1.2 and 3.1.3 even lie a little (claiming the 
implicit start is always 0, and the implicit end is always len(sequence), when 
those reverse for a negative slice step).

The slice object and the slice glossary entry doesn't cover it either, nor link 
to anything that does. The Data model entry for Slicings doesn't seem to 
describe meaning either.

--
nosy: +josh.r

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Gregory P. Smith]

Gregory P. Smith added the comment:

+larry for (S2) regarding argument clinic's treatment of bool.

--
nosy: +gregory.p.smith, larry

___
Python tracker 

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

[issue28886] Move deprecated abc module decorators to separate section in docs

[Nick Coghlan]

Nick Coghlan added the comment:

Right, these are in the "Don't use them in new code, but we have absolutely no 
plans to actually remove them" documentation-only category of deprecation 
warning.

However, I'm converting this to a documentation enhancement request, as the 
documentation could make that status clearer by moving them to a separate 
"Legacy builtin decorator subclasses" section at the end of 
https://docs.python.org/3/library/abc.html

Then that section can *start* with the information on simply applying the 
builtin decorators on top of the abc.abstractproperty() decorator, before 
moving on to document the available subclasses.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
stage:  -> needs patch
title: Deprecated abstract base class (abc) decorators do not raise 
DeprecationWarning -> Move deprecated abc module decorators to separate section 
in docs
type: behavior -> enhancement

___
Python tracker 

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

[issue24254] Make class definition namespace ordered by default

[Nick Coghlan]

Nick Coghlan added the comment:

Thanks for the ping Ned.

Closing this again, as Guido explained the rationale for the change in the 
python-dev thread referenced above: 
https://mail.python.org/pipermail/python-dev/2016-September/146371.html

--
resolution:  -> fixed
stage: commit 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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Gregory P. Smith]

Gregory P. Smith added the comment:

attaching a proposed fix for (S5).  os.chmod should have the same EINTR retry 
treatment as everything else.  That it does not appears to have been an 
oversight.

--
keywords: +patch
Added file: http://bugs.python.org/file45781/os-chmod-EINTR-retry.gps01.diff

___
Python tracker 

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

[issue28891] Standardise more behaviours for zero-argument super() __class__ and __classcell__

[Nick Coghlan]

New submission from Nick Coghlan:

In http://bugs.python.org/issue28884#msg282535 Armin Rigo points out that the 
zero-argument super() cell injection currently interacts a little strangely 
with explicit "nonlocal __class__" statements in nested namespaces.

Specifically, it acts like a closure variable that isn't visible in its own 
scope, but can be accessed via nonlocal in nested class scopes:

>>> class C_with_nested_nonlocal:
... class Inner:
... nonlocal __class__
... __class__ = 42
... print(locals())
...
{'__module__': '__main__', '__qualname__': 'C_with_nested_nonlocal', 'Inner': 
, '__class__': 42}

This weird behaviour is due to the way the CPython code generator injects 
__class__ into the namespaces we track during symbol table generation 
(specifically, it's made available as a free variable for nested namespaces to 
reference without actually adding it to the local symbol namespace for the 
class body). There's no requirement for other implementations to replicate the 
full details of that idiosyncratic behaviour, but there is a requirement that 
__class__ and (in 3.6+) __classcell__ not show up in locals() by default when 
evaluating the class body.

And methods can similarly overwrite the interpreter provided reference to the 
defining class:

>>> class C_with_method_assignment_to_class_cell:
... def bad_method(self):
... nonlocal __class__
... __class__ = 42
... def other_method(self):
... return __class__
... bad_method(None)
... print(locals()["__class__"])
... 
42
>>> C_with_method_assignment_to_class_cell().other_method()

>>> C_with_method_assignment_to_class_cell().bad_method()
>>> C_with_method_assignment_to_class_cell().other_method()
42

One possible approach here would be to implement an outright language level ban 
on the use of "__class__" in explicit "nonlocal" declarations, and then add a 
test to Lib/test_super.py that ensures "__class__" and "__classcell__" don't 
show up in the class locals() while the statement body is executing.

--
messages: 282585
nosy: arigo, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Standardise more behaviours for zero-argument super() __class__ and 
__classcell__
type: behavior

___
Python tracker 

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

[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)

[Nick Coghlan]

Nick Coghlan added the comment:

I broke B9 for the "nonlocal __class__" misbehaviour out to a separate issue: 
http://bugs.python.org/issue28891

I love zero-argument super() as a user, but as an interpreter maintainer... ugh 
:P

--
nosy: +ncoghlan

___
Python tracker 

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

[issue28891] Standardise more behaviours for zero-argument super() __class__ and __classcell__

[Nick Coghlan]

Nick Coghlan added the comment:

Breaking the concrete proposal out to its own post:

- for CPython, "nonlocal __class__" becomes a SyntaxError generated by the 
symbol table pass in the compiler in 3.7+ and a DeprecationWarning in 3.6.1+
- other implementations (including PyPy) can just make "nonlocal __class__" a 
SyntaxError immediately
- an explicit test be added to 
https://hg.python.org/cpython/file/default/Lib/test/test_super.py for 3.6+ that 
"__class__" and "__classcell__" don't show up in the class locals() during 
execution of the class body

--

___
Python tracker 

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

[issue28892] pandas.to_datetime crashes in 3.6b4

[Dale]

New submission from Dale:

I'm trying 3.6b4 on my mac (OS X 10.10.5) and when I run the following code  
(after doing pip install numpy and pandas) I see a 'SystemError':

>>> import pandas as pd
>>> pd.to_datetime('10/31/2016')
ValueError: Error parsing datetime string "10/31/2016" at position 2

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

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/util/decorators.py",
 line 91, in wrapper
return func(*args, **kwargs)
  File 
"/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/tseries/tools.py",
 line 430, in to_datetime
return _convert_listlike(np.array([arg]), box, format)[0]
  File 
"/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/tseries/tools.py",
 line 401, in _convert_listlike
require_iso8601=require_iso8601
  File "pandas/tslib.pyx", line 2302, in pandas.tslib.array_to_datetime 
(pandas/tslib.c:43278)
  File "pandas/tslib.pyx", line 2458, in pandas.tslib.array_to_datetime 
(pandas/tslib.c:41773)
  File "pandas/tslib.pyx", line 2416, in pandas.tslib.array_to_datetime 
(pandas/tslib.c:41009)
  File "pandas/src/datetime.pxd", line 141, in datetime._string_to_dts 
(pandas/tslib.c:90460)
SystemError:  returned a result with an error set
>>>

sys.version says:

>>> import sys
>>> sys.version
'3.6.0b4 (v3.6.0b4:18496abdb3d5, Nov 21 2016, 20:44:47) \n[GCC 4.2.1 (Apple 
Inc. build 5666) (dot 3)]'
>>> 



With 3.5 it works as expected:

>>> import sys
>>> sys.version
'3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) \n[GCC 4.2.1 (Apple Inc. 
build 5666) (dot 3)]'
>>> import pandas as pd
>>> pd.to_datetime('10/31/2016')
Timestamp('2016-10-31 00:00:00')
>>> 


I know it looks like pandas might be at fault, but given that the only thing 
I've changed is the Python version, I'm thinking it might be exposing a 3.6 bug 
(or vice versa, I suppose).


My apologies if I'm doing this all wrong, I'm new around here.

--
components: Extension Modules, Interpreter Core, macOS
messages: 282588
nosy: Schouten, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pandas.to_datetime crashes in 3.6b4
type: crash
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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Larry Hastings]

Larry Hastings added the comment:

I assert that Argument Clinic's / PyArg_ParseTuple's handling of bool is 
correct.

* Python has a well-established concept of "truth":

  https://docs.python.org/3/library/stdtypes.html#truth-value-testing

  The C equivalent is, indeed, PyObject_IsTrue().

* When we added the 'p' format unit to PyArg_ParseTuple, I originally had a 
second format unit 'P' that would only accept boolean literal values.  But 
nobody could come up with a use case for it.  So we removed it.  See #14705 for 
the discussion.

* Existing code often does something half-assed here.  eg. stat_float_times 
uses the PyArg_ParseTuple "i" format unit for its boolean parameter, which 
accepts booleans and integers but not strings.  This is strange and 
inconsistent.  (Of course, you can do this with Argument Clinic, just specify 
the parameter as an int.  But, yuck.)

If you have a counter-proposal for how it should behave, I'd be interested to 
hear it.  But as far as I'm concerned, the two legitimate answers for "how to 
handle integers" are either a) accept literally only True and False--an 
approach which nobody has a use case for--or b) PyObject_IsTrue(), which 
behaves exactly like Python.

--

___
Python tracker 

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

[issue28091] Document PEP 525

[Yury Selivanov]

Yury Selivanov added the comment:

Eric, are you working on a patch?  If not, I'll be focusing on this myself in 
the next couple of days.

--

___
Python tracker 

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

[issue28892] pandas.to_datetime crashes in 3.6b4

[Ned Deily]

Ned Deily added the comment:

Thanks for the report. This problem was reported previously in Issue28636 where 
it was determined that the problem is in Pandas 
(https://github.com/pandas-dev/pandas/issues/14561).  It looks like the Pandas 
project has pushed a fix for it.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> strange issue with Pandas-0.19.1 on Python-3.6.0b3
type: crash -> 

___
Python tracker 

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

[issue28892] pandas.to_datetime crashes in 3.6b4

[Dale]

Dale added the comment:

Thanks for the quick response!

--

___
Python tracker 

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

[issue28091] Document PEP 525

[Eric Appelt]

Eric Appelt added the comment:

Hi Yury - Yes, I am excited about doing this and getting to work on it. Today 
was pretty busy but I have some time blocked out tomorrow to really dig in. I 
was planning to give myself a deadline of Friday afternoon if that works for 
the review/release schedule. If needed I can try to get it up earlier.

--

___
Python tracker 

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

[issue28091] Document PEP 525

[Yury Selivanov]

Yury Selivanov added the comment:

Friday is good, take your time!

--

___
Python tracker 

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

[issue28893] Make sure exceptions raised in __aiter__ are properly chained in ceval

[Yury Selivanov]

New submission from Yury Selivanov:

Originally reported in http://bugs.python.org/issue28885#msg282538

Ned, please take a look at the attached patch.  While I think that the change 
is quite small & safe to merge, I think it's OK if we push this only in 3.6.1.  
It's a nice usability improvement, but only for people that implement objects 
with custom __await__, which is quite a rare case.

--
assignee: yselivanov
components: Interpreter Core
files: chain.patch
keywords: patch
messages: 282595
nosy: brett.cannon, haypo, ned.deily, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Make sure exceptions raised in __aiter__ are properly chained in ceval
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45782/chain.patch

___
Python tracker 

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

[issue28885] Python 3.5.2 strange-behavior issues (from PyPy)

[Yury Selivanov]

Yury Selivanov added the comment:

I created an issue to track S1: http://bugs.python.org/issue28893

--

___
Python tracker 

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

[issue28867] NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)

[Jon Dufresne]

Changes by Jon Dufresne :


--
keywords: +patch
Added file: 
http://bugs.python.org/file45783/namedtemporaryfile-resourcewarning.patch

___
Python tracker 

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

[issue28886] Move deprecated abc module decorators to separate section in docs

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy:  -serhiy.storchaka

___
Python tracker 

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

[issue28893] Make sure exceptions raised in __aiter__ are properly chained in ceval

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Should the original exception be stored on the __context__ or the __cause__ 
attribute? In the latter case you should use _PyErr_FormatFromCause().

--

___
Python tracker 

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

[issue28866] Type cache is not correctly invalidated on a class defining mro()

[Julien Palard]

Julien Palard added the comment:

> issue28866.diff always invalidates the cache, so it works. But it is 
> suboptimal, IMO it defeats the whole purpose of a cache.

Not sure about defeating the purpose of the cache as I only invalidate in 
setattr, getattr are still cache hitting. I tried:

$ python3 -m performance run --python=./python --rigorous -b all -o master.json
$ git checkout issue28866; make -j 8
$ python3 -m performance run --python=./python --rigorous -b all -o 
issue28866.json
$ python3 -m performance compare master.json issue28866.json

And I don't see much differences, probably only noise as I get some faster 
tests:

### call_method_unknown ###
Median +- Std dev: 56.8 ms +- 3.3 ms -> 52.9 ms +- 1.6 ms: 1.08x faster
Significant (t=12.92)

### pybench.IfThenElse ###
Median +- Std dev: 247 ns +- 3 ns -> 224 ns +- 16 ns: 1.11x faster
Significant (t=15.15)

and some slower:
### pybench.StringPredicates ###
Median +- Std dev: 1.89 us +- 0.05 us -> 2.18 us +- 0.21 us: 1.15x slower
Significant (t=-15.20)

### unpack_sequence ###
Median +- Std dev: 207 ns +- 4 ns -> 231 ns +- 27 ns: 1.12x slower
Significant (t=-11.63)

I'm not yet accustomed to this perf suite, so I may miss something obvious. 
I'll ran it again on master to measure the noise and should probably fine-tune 
my system for stability.

I'll also try a benchmark without the cache for comparison.

--

___
Python tracker 

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