[issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo

[Xavier de Gaye]

New submission from Xavier de Gaye :

* The NDK version can be obtained by parsing the file 
$ANDROID_NDK_ROOT/source.properties.
* The versions of the SDK build-tools, emulator and platform-tools packages as 
well as those of the system images can be obtained by parsing the output of 
"$ANDROID_SDK_ROOT/tools/bin/sdkmanager --list".

--
components: Cross-Build
messages: 307544
nosy: Alex.Willmer, vstinner, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: Add the versions of the Android SDK and NDK to test.pythoninfo
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

[issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4606

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4607

___
Python tracker 

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

[issue32107] Improve MAC address calculation and fix test_uuid.py

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset e69fbb6a560a02d0587b9075afd338a1e9073af0 by Serhiy Storchaka in 
branch 'master':
Fix a regression in uuid added in bpo-32107. (#4677)
https://github.com/python/cpython/commit/e69fbb6a560a02d0587b9075afd338a1e9073af0


--

___
Python tracker 

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

[issue32211] Document the bug in re.findall() and re.finditer() in 2.7 and 3.6

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

>>> re.findall(r'^|\w+', 'two words')
['', 'wo', 'words']

Seems the current behavior was documented incorrectly in issue732120.

It will be fixed in 3.7 (see issue1647489, issue25054), but I hesitate to 
backport the fix to 3.6 and 2.7 because this can break the user code. For 
example:

In Python 3.6:

>>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar'))
[<_sre.SRE_Match object; span=(4, 4), match=''>, <_sre.SRE_Match object; 
span=(5, 5), match=''>]

In Python 3.7:

>>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar'))
[, , ]

(This is a real pattern used in the docstring module, but with re.sub()).

The proposed PR documents the current weird behavior in 2.7 and 3.6.

--
assignee: docs@python
components: Documentation, Regular Expressions
messages: 307546
nosy: docs@python, ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document the bug in re.findall() and re.finditer() in 2.7 and 3.6
type: enhancement
versions: Python 2.7, Python 3.6

___
Python tracker 

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

[issue32212] few discrepancy between source and docs in logging

[Michal Plichta]

New submission from Michal Plichta :

my code:

logger = logging.getLogger(name)
logger.setLevel(level=logging.DEBUG)
...
stream_handler = logging.StreamHandler(stream=stdout)
stream_handler.setLevel(logging_level)
stream_handler.setFormatter(fmt=formatter)

and mypy-0.550 complains about fmt vs. form parameter in setFormatter method 
and level vs. lvl in setLevel method.

ta_cc/cc_logger.py: note: In function "_get_stream_handler":
ta_cc/cc_logger.py:34: error: Unexpected keyword argument "fmt" for 
"setFormatter" of "Handler"
/usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:147: note: 
"setFormatter" of "Handler" defined here
ta_cc/cc_logger.py:109: error: Unexpected keyword argument "level" for 
"setLevel" of "Logger"
/usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:46: note: 
"setLevel" of "Logger" defined here

I see in online documentation that indeed there are lvl and form parameters for 
all 2.7, 3.5 and 3.6 python version. However my Pycharm suggest level and fmt 
for all my installed python interpreters.

I use:
Pycharm-2017.3
Python 2.7.12
Python 3.5.2
Python 3.6.3

This is copy of my issue of: https://github.com/python/typeshed/issues/1619

--
assignee: docs@python
components: Documentation
messages: 307547
nosy: Michal Plichta, docs@python
priority: normal
severity: normal
status: open
title: few discrepancy between source and docs in logging
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue32211] Document the bug in re.findall() and re.finditer() in 2.7 and 3.6

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

___
Python tracker 

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

[issue32199] uuid.getnode() should return the MAC address on Android

[Xavier de Gaye]

Change by Xavier de Gaye :


--
keywords: +patch
pull_requests: +4609
stage: needs patch -> patch review

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Mark Shannon  added the comment:

I plan to resurrect my original design over the Christmas break.
The reason that I want to get back to the original design is its consistency 
and relative simplicity.

Duplicating the finally block for every exit from the try body might sound 
expensive, but it only increases the size of the bytecode by an estimated 0.4%.
 
Using statement counts as a proxy for bytecodes, I ran the code query 
https://lgtm.com/query/1505907426052/ over a range of open stack and other 
large projects. The size increase is in the range 0.26% to 0.44%
(Note that the statement counts include dependencies)

I plan to start from 
https://github.com/python/cpython/pull/2827/commits/693b9398b5fd202fa5864f9cc76fa1bc7f84f62e
as that adheres to the original design, but cleans up the code.
Antoine that is on your branch, are you OK with me appropriating it?

--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le 04/12/2017 à 12:46, Mark Shannon a écrit :
> 
> I plan to start from 
> https://github.com/python/cpython/pull/2827/commits/693b9398b5fd202fa5864f9cc76fa1bc7f84f62e
> as that adheres to the original design, but cleans up the code.
> Antoine that is on your branch, are you OK with me appropriating it?

Definitely.

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[STINNER Victor]

STINNER Victor  added the comment:

"./Program/_testembed.exe bpo20891" fails randomly on macOS:
---
macbook:master haypo$ while true; do ./Programs/_testembed bpo20891 ||break; 
date; done
Lun  4 déc 2017 12:46:34 CET
Lun  4 déc 2017 12:46:34 CET
Lun  4 déc 2017 12:46:34 CET
Fatal Python error: PyEval_SaveThread: NULL tstate

Current thread 0x7fffa5dff3c0 (most recent call first):
Abort trap: 6
---

In test_bpo20891() of Program/_testembed.c, Py_BEGIN_ALLOW_THREADS calls 
PyEval_SaveThread() which fails with a fatal error:

PyThreadState *tstate = PyThreadState_Swap(NULL);
if (tstate == NULL)
Py_FatalError("PyEval_SaveThread: NULL tstate"); <~~~ HERE

I'm not sure that it's safe to create the GIL in PyGILState_Ensure() in a 
"non-Python" thread, while the main thread (which is a Python thread) "is 
running".

I found a working fix: call PyEval_InitThreads() in 
PyThread_start_new_thread(). So the GIL is created as soon as a second thread 
is spawned. The GIL cannot be created anymore while two threads are running. At 
least, with the "python" binary. It doesn't fix the issue if a thread is not 
spawned by Python, but this thread calls PyGILState_Ensure().

Maybe we need to better document how threads have to be initialized to prevent 
this race condition / bug?

--
nosy: +eric.snow, ncoghlan
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Why not *always* call PyEval_InitThreads() at interpreter initialization?  Are 
there any downsides?

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[STINNER Victor]

STINNER Victor  added the comment:

> Why not *always* call PyEval_InitThreads() at interpreter initialization?  
> Are there any downsides?

The code is quite old:

commit 1984f1e1c6306d4e8073c28d2395638f80ea509b
Author: Guido van Rossum 
Date:   Tue Aug 4 12:41:02 1992 +

* Makefile adapted to changes below.
* split pythonmain.c in two: most stuff goes to pythonrun.c, in the library.
* new optional built-in threadmodule.c, build upon Sjoerd's thread.{c,h}.
* new module from Sjoerd: mmmodule.c (dynamically loaded).
* new module from Sjoerd: sv (svgen.py, svmodule.c.proto).
* new files thread.{c,h} (from Sjoerd).
* new xxmodule.c (example only).
* myselect.h: bzero -> memset
* select.c: bzero -> memset; removed global variable

(...)

+void
+init_save_thread()
+{
+#ifdef USE_THREAD
+   if (interpreter_lock)
+   fatal("2nd call to init_save_thread");
+   interpreter_lock = allocate_lock();
+   acquire_lock(interpreter_lock, 1);
+#endif
+}
+#endif


Current version of the code:

void
PyEval_InitThreads(void)
{
if (gil_created())
return;
create_gil();
take_gil(PyThreadState_GET());
_PyRuntime.ceval.pending.main_thread = PyThread_get_thread_ident();
if (!_PyRuntime.ceval.pending.lock)
_PyRuntime.ceval.pending.lock = PyThread_allocate_lock();
}

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[STINNER Victor]

STINNER Victor  added the comment:

The "if (gil_created())" check can be found in the Py_BEGIN_ALLOW_THREADS / 
Py_END_ALLOW_THREADS macros which call PyEval_SaveThread() / 
PyEval_RestoreThread():

PyThreadState *
PyEval_SaveThread(void)
{
PyThreadState *tstate = PyThreadState_Swap(NULL);
if (tstate == NULL)
Py_FatalError("PyEval_SaveThread: NULL tstate");
if (gil_created()) < HERE
drop_gil(tstate);
return tstate;
}

void
PyEval_RestoreThread(PyThreadState *tstate)
{
if (tstate == NULL)
Py_FatalError("PyEval_RestoreThread: NULL tstate");
if (gil_created()) { < HERE
int err = errno;
take_gil(tstate);
/* _Py_Finalizing is protected by the GIL */
if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {
drop_gil(tstate);
PyThread_exit_thread();
Py_UNREACHABLE();
}
errno = err;
}
PyThreadState_Swap(tstate);
}


I guess that the intent of dynamically created GIL is to reduce the "overhead" 
of the GIL when 100% of the code is run in single thread.

I understand that this potential overhead must be measured to decide if it's ok 
to always create the GIL.

This bug was reported once in 2014, then Marcin Kasperski asked for an update 
last month: 3 years later. It's not a common bug impacting many users. So if 
there is an overhead, I'm not sure that it's a good idea to change Python to 
fix this rare use case.

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I guess that the intent of dynamically created GIL is to reduce the 
> "overhead" of the GIL when 100% of the code is run in single thread.

I'm not sure it is ok to guess here.  The original code was written in 1992, 
when system threading APIs were buggy and not always available.  Also the 
original GIL logic released the lock every N opcodes, which is a fragile 
heuristic.  The current GIL shouldn't have any visible performance cost in 
single-threaded mode, and in even in multi-threaded mode it's been a long time 
since anyone complained about a real-world performance degradation due to the 
GIL's overhead.

Perhaps Guido remembers the original rationale?

> This bug was reported once in 2014, then Marcin Kasperski asked for an update 
> last month: 3 years later. It's not a common bug impacting many users.

>From a maintenance POV, initializing the GIL eagerly also makes maintenance 
>easier for us, instead of making all those dynamic checks.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue1647489] zero-length match confuses re.finditer()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 70d56fb52582d9d3f7c00860d6e90570c6259371 by Serhiy Storchaka in 
branch 'master':
bpo-25054, bpo-1647489: Added support of splitting on zerowidth patterns. 
(#4471)
https://github.com/python/cpython/commit/70d56fb52582d9d3f7c00860d6e90570c6259371


--

___
Python tracker 

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

[issue25054] Capturing start of line '^'

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 70d56fb52582d9d3f7c00860d6e90570c6259371 by Serhiy Storchaka in 
branch 'master':
bpo-25054, bpo-1647489: Added support of splitting on zerowidth patterns. 
(#4471)
https://github.com/python/cpython/commit/70d56fb52582d9d3f7c00860d6e90570c6259371


--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I started on Antoine's PR and work on different approach 
(https://github.com/serhiy-storchaka/cpython/pull/1) which don't duplicate the 
code for continue/break/return. Instead it uses some kind of subroutines. 
END_FINALLY expects the one of three cases:

1. NULL (or None). Normal execution thread in try/finally. Continue from the 
instruction following END_FINALLY.

2. An integer. This is an address of returning. Continue from the specified 
address.

3. An exception (6 items). Raises the specified exception.

WITH_CLEANUP_FINISH behaves similarly.

The statements continue/break/return insert the instruction CALL_FINALLY which 
pushes the address of the following instruction on the stack and jumps to the 
start of the finally (or with cleanup) block. There can be several CALL_FINALLY 
instructions if you need to execute several finally blocks. At the jump 
instruction is inserted for continue and break, and RETURN_VALUE for return.

Currently I'm trying to simplify the code.

--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le 04/12/2017 à 13:25, Serhiy Storchaka a écrit :
> 
> I started on Antoine's PR and work on different approach 
> (https://github.com/serhiy-storchaka/cpython/pull/1) which don't duplicate 
> the code for continue/break/return. Instead it uses some kind of subroutines. 
> END_FINALLY expects the one of three cases:
> 
> 1. NULL (or None). Normal execution thread in try/finally. Continue from the 
> instruction following END_FINALLY.
> 
> 2. An integer. This is an address of returning. Continue from the specified 
> address.
> 
> 3. An exception (6 items). Raises the specified exception.

The problem is that makes the stack consumption of END_FINALLY variable.
How about always consuming 6 items, even when most of them are unused
padding?

--

___
Python tracker 

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

[issue32030] PEP 432: Rewrite Py_Main()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 31a8393cf6a74c870c3484dd68500619f6232c6d by Victor Stinner in 
branch 'master':
Revert "bpo-32197: Try to fix a compiler error on OS X introduced in bpo-32030. 
(#4681)" (#4694)
https://github.com/python/cpython/commit/31a8393cf6a74c870c3484dd68500619f6232c6d


--

___
Python tracker 

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

[issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 31a8393cf6a74c870c3484dd68500619f6232c6d by Victor Stinner in 
branch 'master':
Revert "bpo-32197: Try to fix a compiler error on OS X introduced in bpo-32030. 
(#4681)" (#4694)
https://github.com/python/cpython/commit/31a8393cf6a74c870c3484dd68500619f6232c6d


--

___
Python tracker 

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

[issue32212] few discrepancy between source and docs in logging

[R. David Murray]

R. David Murray  added the comment:

I don't understand what the bug is that you are reporting here.  Can you 
clarify?  mypy isn't part of the stdlib, so an explanation in terms of what's 
in the stdlib would be helpful.

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

[issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR

[STINNER Victor]

STINNER Victor  added the comment:

Oh sorry, I missed the macOS failure and I wasn't available last week-end for 
quickly fix it. So thanks Serhiy for the revert ;-) I reapplied my changes with 
the following fix. test_embed randomly failed, but it's unrelated (I was able 
to reproduce the bug on master, with the revert):
https://bugs.python.org/issue20891#msg307550

The fix:

diff --git a/Modules/main.c b/Modules/main.c
index 84706e1e290..4095259b88c 100644
--- a/Modules/main.c
+++ b/Modules/main.c
@@ -901,8 +901,8 @@ config_get_program_name(_PyMainInterpreterConfig *config)
 size_t len;
 wchar_t* program_name = Py_DecodeLocale(p, &len);
 if (program_name == NULL) {
-return SET_DECODE_ERROR("PYTHONEXECUTABLE environment "
-"variable", len);
+return DECODE_LOCALE_ERR("PYTHONEXECUTABLE environment "
+ "variable", (Py_ssize_t)len);
 }
 config->program_name = program_name;
 }
@@ -916,8 +916,8 @@ config_get_program_name(_PyMainInterpreterConfig *config)
 size_t len;
 wchar_t* program_name = Py_DecodeLocale(pyvenv_launcher, &len);
 if (program_name == NULL) {
-return SET_DECODE_ERROR("__PYVENV_LAUNCHER__ environment "
-"variable", len);
+return DECODE_LOCALE_ERR("__PYVENV_LAUNCHER__ environment "
+ "variable", (Py_ssize_t)len);
 }
 config->program_name = program_name;
 }

--

___
Python tracker 

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

[issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR

[STINNER Victor]

STINNER Victor  added the comment:

I tested manually that compilation and tests succeed on macOS.

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> The problem is that makes the stack consumption of END_FINALLY variable.
> How about always consuming 6 items, even when most of them are unused
> padding?

Right. Though the value of the stack increment makes sense only for the case 
1, because in other cases the next executed instruction is not the one 
following END_FINALLY, but we need to reserve the stack for the case 3, and 
counting additional "virtual" items  in PUSH_NO_EXCEPT and END_FINALLY will 
help to calculate the maximal stack consumption, even when in runtime they 
push/pop only one item. This is yet one argument for special purposed opcode 
PUSH_NO_EXCEPT (maybe I'll rename it to START_FINALLY or BEGIN_FINALLY). Other 
reason -- this will help to determine bounds of finally blocks in the 
frame.f_lineno setter.

--

___
Python tracker 

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

[issue32212] few discrepancy between source and docs in logging

[Michal Plichta]

Michal Plichta  added the comment:

see at typeshed:
https://github.com/python/typeshed/blob/master/stdlib/2and3/logging/__init__.pyi#L147

def setLevel(self, lvl: Union[int, str]) -> None: ...
def setFormatter(self, form: 'Formatter') -> None: ...

this match python documentation:
Handler.setLevel(lvl)
Handler.setFormatter(form)

but is source code (logging/__init__.py):
def setFormatter(self, fmt):
self.formatter = f

def setLevel(self, level):
self.level = _checkLevel(level)

This is not big deal but keyworded arguments have different names fmt, form and 
level, lvl.

Some tools which perform static code verification are base of *.pyi from 
typeshed repo and some form source code.

--

___
Python tracker 

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

[issue32197] Compiling against master branch fails; error: expected expression SET_DECODE_ERROR

[Sanyam Khurana]

Sanyam Khurana  added the comment:

Hey Victor, thanks for the update.

I was confused about how the macro was replaced in the previous version.

--

___
Python tracker 

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

[issue32212] few discrepancy between source and docs in logging

[R. David Murray]

R. David Murray  added the comment:

Ah.  I'm guessing Vinay will probably want to fix the docs, then, since that's 
less disruptive backward compatibility wise.

--
nosy: +vinay.sajip

___
Python tracker 

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

[issue32212] few discrepancy between source and docs in logging

[R. David Murray]

Change by R. David Murray :


--
stage:  -> needs patch
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

[issue32035] Documentation of zipfile.ZipFile().writestr() fails to mention that 'data' may also be bytes

[Chirag Rathod]

Change by Chirag Rathod :


--
keywords: +patch
pull_requests: +4610
stage: needs patch -> patch review

___
Python tracker 

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

[issue32212] few discrepancy between source and docs in logging

[Michal Plichta]

Michal Plichta  added the comment:

Nice, btw maybe other parameters in logging's docs needs to be corrected.

--

___
Python tracker 

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

[issue32213] assertRaises and subTest context managers cannot be nested

[Paul Ganssle]

New submission from Paul Ganssle :

The TestCase.assertRaises and TestCase.subTest macros apparently don't interact 
with each other well. To demonstrate, consider the following code:

from unittest import TestCase

class SubTestRaisesTest(TestCase):
def test_assert_outer(self):
for to_raise in [True, False]:
with self.assertRaises(Exception):
with self.subTest(to_raise=to_raise):
if to_raise:
raise Exception()

def test_assert_inner(self):
for to_raise in [True, False]:
with self.subTest(to_raise=to_raise):
with self.assertRaises(Exception):
if to_raise:
raise Exception()

This actually fails in two different ways.

For test_assert_outer:
  
-with subtest `to_raise=True`, the test (correctly) passes.
-with subtest `to_raise=False`, the test (correctly) fails, but the subtest is 
not actually assigned (no indication of which subtest it was that failed):



==
FAIL: test_assert_outer (test_bug.SubTestRaisesTest)
--
Traceback (most recent call last):
  File ".../assert_demo/test_bug.py", line 9, in test_assert_outer
raise Exception()
AssertionError: Exception not raised


For test_assert_inner:
- with subtest `to_raise=False`, the test (corrrectly) fails, *and* the subtest 
is set correctly:


==
FAIL: test_assert_inner (test_bug.SubTestRaisesTest) (to_raise=False)
--
Traceback (most recent call last):
  File "/assert_demo/test_bug.py", line 16, in test_assert_inner
raise Exception()
AssertionError: Exception not raised


- with subtest `to_raise=False` the test (incorrectly) fails as an error, 
because the exception is never caught:


==
ERROR: test_assert_outer (test_bug.SubTestRaisesTest) (to_raise=True)
--
Traceback (most recent call last):
  File "/assert_demo/test_bug.py", line 9, in test_assert_outer
raise Exception()
Exception


So, to sum up, the behavior that needs to be fixed:

1. When assertRaises is the outer context, the subtest value needs to be set 
for the failing tests.

2. When assertRaises is the *inner* context, the exception needs to be caught 
properly and cleared on exit from the assertRaises context.

--
components: Tests
messages: 307569
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: assertRaises and subTest context managers cannot be nested
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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Mark Shannon  added the comment:

Serhiy,

I assume that you plan to use something like the JVM's JSR/RET instruction 
pair. https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html
Is that right?

My reasons for preferring the finally-block duplication approach is that it 
keeps the interpreter simpler and minimises the amount work done when no 
exception is raised. As demonstrated, the increase in the static size of the 
bytecode is negligible.

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[Guido van Rossum]

Guido van Rossum  added the comment:

Yeah, the original reasoning was that threads were something esoteric and
not used by most code, and at the time we definitely felt that always using
the GIL would cause a (tiny) slowdown and increase the risk of crashes due
to bugs in the GIL code. I'd be happy to learn that we no longer need to
worry about this and can just always initialize it.

(Note: I haven't read the entire thread, just the first and last message.)

--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le 04/12/2017 à 16:21, Mark Shannon a écrit :
> 
> My reasons for preferring the finally-block duplication approach is that it 
> keeps the interpreter simpler and minimises the amount work done when no 
> exception is raised. As demonstrated, the increase in the static size of the 
> bytecode is negligible.

Whichever approach wins at the end, I would like it to reuse the tests I
wrote to check that no stack size explosion happens when combining or
juxtaposing several control flow constructs.

--

___
Python tracker 

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

[issue32205] test.pythoninfo does not print the cross-built sysconfig data

[STINNER Victor]

STINNER Victor  added the comment:

I'm not sure of the purpose of this change. You can please elaborate on you use 
case?

You use cross-compilation, ok. But why do you want to run test.pythoninfo on 
the computer building Python, rather than the computer running tests?

The purpose of test.pythoninfo is to dump informations on tests run by 
"./python -m test". I wrote it for buildbots.

If your use case is to have an Android buildbot worker, test.pythoninfo would 
be run on Android, no?

--

___
Python tracker 

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

[issue31901] atexit callbacks should be run at subinterpreter shutdown

[Marcel Plch]

Marcel Plch  added the comment:

I created a PR with fix on this issue - 
https://github.com/python/cpython/pull/4611

This makes Py_EndInterpreter() call atexit callbacks for the subinterpreter it 
is destroying.

It doesn't make Py_Finalize() end all subinterpreters, as the current 
implementation of subinterpreters makes it hard to do so. This is the same as 
the current behaviour: you need to end all subinterpreters before calling 
Py_Finalize().

--

___
Python tracker 

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

[issue32213] assertRaises and subTest context managers cannot be nested

[R. David Murray]

R. David Murray  added the comment:

To be pedantic, are not macros, they are context managers :)

Your first case is not something I would have thought of coding.  In the 
to_raise=True case, the subTest is failing because an exception is raised 
inside its scope.  In the to_raise=False case, the subTest scope has already 
ended before the assertRaises scope completes and raises its error because no 
exception was raised.  That is, there is no subTest in effect to be reported 
when that failure occurs.

In your second case, when to_raise is False, no exception is raised, so the 
assertRaises correctly fails, and the subtest reports that to_raise is False.  
When to_raise is true, the exception is raised, the assertRaises passes and so 
does the subtest.  In other words, I can't reproduce the problem you cite for 
the second case.  Looking at what you pasted, it looks like you confused a 
test_assert_outer report with a test_report_inner report.

So, as far as I can see, there's nothing broken here, everything is working 
according to the documentation :)

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

[issue32213] assertRaises and subTest context managers cannot be nested

[Paul Ganssle]

Paul Ganssle  added the comment:

@r.david.murray So it is, my mistake. I think I was conflating issues when this 
first came up, and then I didn't notice that the order the test cases printed 
in was different than I expected.

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Right, this is similar to how the JSR/RET pair was used in for calling the 
finally block.

It seems the main drawback of duplicating of the finally code is not increasing 
the code size (which can be exponential in degenerate cases), but the problem 
with determining the boundaries of the finally block.

The main purpose of this issue (getting rid of "pseudo exceptions" in the 
interpreter) will be achieved in any case.

This is the first step. In the second step I'm going to get rid of dynamic 
PyTryBlock and instructions like SETUP_EXCEPT and POP_BLOCK. I think all 
necessary information can be determined at compile time and saved in an 
auxiliary structure, similarly as line numbers are saved in the packed 
co_lnotab array instead of be set by SET_LINENO instructions. Boundaries of 
finally block could be stored in the same structure. This will make try/except/
finally virtually zero-overhead.

In the third step we could generate duplicates of finally blocks. This will be 
easier if other changes already applied and tested.

Currently there is other problem with Antoine's PR (I didn't know about them 
when made a review). There is a gap between calling the __enter__ method and 
the SETUP_FINALLY instruction. If the exception is raised in the gap, the 
__exit__ method will be never called. For example:

a = []
with CM() as a[0]: # IndexError
...

I still haven't fixed this problem. Maybe the simplest solution would be to 
return the SETUP_WITH instruction which calls __enter__ and creates the finally 
block prior to saving the result of __enter__.

--

___
Python tracker 

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

[issue32213] assertRaises and subTest context managers cannot be nested

[R. David Murray]

R. David Murray  added the comment:

Yes, that's an easy mistake to make.  I avoided it by only running one of the 
tests cases at a time, and I'll admit I had to think about it for a while to 
understand what was going on in your first case.

--

___
Python tracker 

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

[issue32205] test.pythoninfo does not print the cross-built sysconfig data

[STINNER Victor]

STINNER Victor  added the comment:

"make pythoninfo" is an alias for ./python -m test.pythoninfo. I added to 
support Python compiled in shared mode (./configure --enable-shared) and macOS 
which requires ./python.exe.

Obviously, for a specific buildbot or specific script, you are free to run 
directly ./python -m test.pythoninfo, rather than running "make pythoninfo" ;-)

--

___
Python tracker 

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

[issue32205] test.pythoninfo does not print the cross-built sysconfig data

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-32210: Add the versions of the Android SDK and NDK to 
test.pythoninfo.

--

___
Python tracker 

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

[issue32213] assertRaises and subTest context managers cannot be nested

[R. David Murray]

Change by R. David Murray :


--
resolution:  -> not a bug

___
Python tracker 

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

[issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo

[STINNER Victor]

STINNER Victor  added the comment:

Maybe add a collect_android() function which would exit early if 
sys.getandroidapilevel() doesn't exist?

> * The NDK version can be obtained by parsing the file 
> $ANDROID_NDK_ROOT/source.properties.
> * The versions of the SDK build-tools, emulator and platform-tools packages 
> as well as those of the system images can be obtained by parsing the output 
> of "$ANDROID_SDK_ROOT/tools/bin/sdkmanager --list".

You are free to add whatever you want/need, but just try to handle properly 
errors to collect other info even if these data cannot be read.

--

___
Python tracker 

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

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Mark Shannon  added the comment:

On 04/12/17 16:56, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka  added the comment:
> 
> Right, this is similar to how the JSR/RET pair was used in for calling the
> finally block.
> 
> It seems the main drawback of duplicating of the finally code is not 
> increasing
> the code size (which can be exponential in degenerate cases), but the problem
> with determining the boundaries of the finally block.

What exactly is the problem?
Why do you need to determine the boundaries of finally blocks?

...

> 
> This is the first step. In the second step I'm going to get rid of dynamic
> PyTryBlock and instructions like SETUP_EXCEPT and POP_BLOCK. I think all
> necessary information can be determined at compile time and saved in an
> auxiliary structure, similarly as line numbers are saved in the packed
> co_lnotab array instead of be set by SET_LINENO instructions. Boundaries of
> finally block could be stored in the same structure. This will make 
> try/except/
> finally virtually zero-overhead.

Fine, but it isn't necessary for this issue. The overhead of try/except 
is already quite low.

> 
> Currently there is other problem with Antoine's PR (I didn't know about them
> when made a review). There is a gap between calling the __enter__ method and
> the SETUP_FINALLY instruction. 

That wasn't a problem with the original patch.

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +4612
stage: resolved -> patch review

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[STINNER Victor]

STINNER Victor  added the comment:

I wrote the PR 4700 to create the GIL in Py_Initialize().

Would you be ok to backport this fix to Python 2.7 and 3.6 as well?

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Paul Ganssle]

Change by Paul Ganssle :


--
pull_requests: +4611

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Mark Shannon]

Mark Shannon  added the comment:

Actually looking back at the original patch, the gap between __enter__ and 
SETUP_FINALLY *was* in the original patch. My mistake. 

The fix would to be restore SETUP_WITH. The complexity we really want to get 
rid of is at the end of the with statement not the start.

--

___
Python tracker 

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

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

[Neil Schemenauer]

Neil Schemenauer  added the comment:

After studying the patch and doing some reading, I prefer the finally-block 
duplication approach as well.  Java does it that way as well and it works for 
them.  It would be be interesting to compile a large body of packages and see 
what the increase in bytecode size actually is with the duplication.  My gut 
feeling is that it will not be a big deal.

There is a bug with the PR regarding the final bodies.  Exits from the final 
body cause the whole fblock stack to unwind, not just the blocks enclosing the 
final body.  Unwind looks at 'c' to get the fblock stack. I think we need to 
allocate fblockinfo on the C stack and then use a back pointer to enclosing 
block.  When you get into a final body that creates its own fblockinfo (e.g. a 
try/except inside the finally), the current code doesn't work.

The fact that the whole test suite passes with these issues tells me that the 
amount of stuff happening in final bodies must be pretty simple in most code.  

I spent a good part of Sunday trying to understand how the PR works.  It seems 
to me that the ceval/bytecode changes are pretty solid.  The compiler needs 
some bug fixes.  Further optimisations could be done at a later time.  I'm 
curious to see Serhiy's approach though.

--

___
Python tracker 

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

[issue20891] PyGILState_Ensure on non-Python thread causes fatal error

[Guido van Rossum]

Guido van Rossum  added the comment:

For 2.7 I hesitate to OK this, who knows what skeletons are still in that
closet. It doesn't sound like a security fix to me. For 3.6 I'm fine with
it as a bugfix.

--

___
Python tracker 

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

[issue32205] test.pythoninfo does not print the cross-built sysconfig data

[Xavier de Gaye]

Xavier de Gaye  added the comment:

I may have misunderstood the scope of pythoninfo. On Android the readline or 
sqlite versions are known at build time since they have to be built at that 
time, but much more useful information can be obtained (or will be obtained) 
from python running on the device or the emulator.

For the NDK and SDK versions (issue 32210), these can be printed by the 'all' 
target for the NDK and by one of the emulator targets for the SDK.

This means that both this issue and #32210 may be closed as wont fix.

--

___
Python tracker 

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

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

[Neil Schemenauer]

Neil Schemenauer  added the comment:

Don't be sorry.  We are all passionate about making Python better.  distutils 
will be better once we gets this sorted out.  Berker deserves credit for seeing 
an issue and developing on a fix for it.  The collaboration between all the 
core developers is making the final fix better than what any one of us could 
make.

The process is working quite well IMHO.  I had a small patch a few days ago 
that I was considering just committing without reviews.  I went through the 
review process though and the patch was better as a result of the review 
feedback I got.

The documentation says that the argument needs to be a list of strings or a 
string.  So, unless we change the documentation, a string must be accepted 
without warnings or errors.  The current PR works pretty well.  Figuring out 
how to best warn is the trickiest bit.  Sometimes it seems like 
DepreciationWarning doesn't work as we would like, since it often gets 
suppressed.  It seems pip is especially "good" at hiding it.

--

___
Python tracker 

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +4613

___
Python tracker 

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

[issue32208] Improve semaphore documentation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The changes you are proposing sound reasonable to me.  Would you like to submit 
a pull request for them?

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, pitrou
stage:  -> needs patch
versions:  -Python 3.4, Python 3.5, Python 3.8

___
Python tracker 

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

[issue32175] Add hash auto-randomization

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Agreed this is not desirable at this point.  Let's leave 2.7 like it is.

--
nosy: +pitrou

___
Python tracker 

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

[issue21621] Add note to 3.x What's New re Idle changes in bugfix releases

[Terry J. Reedy]

Terry J. Reedy  added the comment:

#21961 ends with the entry I added for 3.4 and 3.5.  3.7 (and checking 3.6) 
will be a new issue.

--
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Add What's New for Idle.

___
Python tracker 

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 21255fc3932a60c064f85c0fe68f2840f390ebe4 by Terry Jan Reedy in 
branch 'master':
bpo-30928: Update idlelib/NEWS.txt to 2017 Dec 3. (#4701)
https://github.com/python/cpython/commit/21255fc3932a60c064f85c0fe68f2840f390ebe4


--

___
Python tracker 

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4614

___
Python tracker 

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

[issue32175] Add hash auto-randomization

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Marking as closed for the reasons listed by the other respondents.

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

___
Python tracker 

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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +4615
stage: needs patch -> patch review

___
Python tracker 

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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thanks.  I am still puzzled why the nested within nested try-except did not 
work as I expected, but I care more about fixing this. The result based on your 
suggestion is better (to read, I think) than extra nesting that did work.

--
stage: patch review -> needs patch

___
Python tracker 

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 6e687948b0025a1ab0d0773efe62ce64f0c745fc by Terry Jan Reedy (Miss 
Islington (bot)) in branch '3.6':
bpo-30928: Update idlelib/NEWS.txt to 2017 Dec 3. (GH-4701) (#4702)
https://github.com/python/cpython/commit/6e687948b0025a1ab0d0773efe62ce64f0c745fc


--

___
Python tracker 

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

[issue32214] Implement PEP 557: Data Classes

[Eric V. Smith]

New submission from Eric V. Smith :

PR to follow. Development was at https://github.com/ericvsmith/dataclasses

--
assignee: eric.smith
components: Library (Lib)
messages: 307596
nosy: eric.smith, ned.deily
priority: normal
severity: normal
status: open
title: Implement PEP 557: Data Classes
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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Terry J. Reedy]

Change by Terry J. Reedy :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue32214] Implement PEP 557: Data Classes

[Eric V. Smith]

Change by Eric V. Smith :


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

___
Python tracker 

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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 1e2fcac4972530aa2c963d7e4011021df5ba866e by Terry Jan Reedy in 
branch 'master':
bpo-32207: Improve tk event exception tracebacks in IDLE. (#4703)
https://github.com/python/cpython/commit/1e2fcac4972530aa2c963d7e4011021df5ba866e


--

___
Python tracker 

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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4617

___
Python tracker 

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +4618

___
Python tracker 

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

[issue32214] Implement PEP 557: Data Classes

[Eric V. Smith]

Eric V. Smith  added the comment:


New changeset f0db54a0a1823534606ed5ce5a772365ba694c41 by Eric V. Smith in 
branch 'master':
bpo-32214: Implement PEP 557: Data Classes (#4704)
https://github.com/python/cpython/commit/f0db54a0a1823534606ed5ce5a772365ba694c41


--

___
Python tracker 

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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 9da33c82124f27eb58ba4cf145675fe7a1035744 by Terry Jan Reedy (Miss 
Islington (bot)) in branch '3.6':
bpo-32207: Improve tk event exception tracebacks in IDLE. (GH-4703) (#4705)
https://github.com/python/cpython/commit/9da33c82124f27eb58ba4cf145675fe7a1035744


--

___
Python tracker 

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

[issue32207] IDLE: run's tk update adds context traceback on callback error

[Terry J. Reedy]

Change by Terry J. Reedy :


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

[issue32214] Implement PEP 557: Data Classes

[Eric V. Smith]

Change by Eric V. Smith :


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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 2c0c68d927bfa557f98bac26644f5b64c4b135a7 by Terry Jan Reedy in 
branch 'master':
bpo-30928: update idlelib/NEWS.txt. (#4706)
https://github.com/python/cpython/commit/2c0c68d927bfa557f98bac26644f5b64c4b135a7


--

___
Python tracker 

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

[issue30928] Copy modified blurbs to idlelib/NEWS.txt

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4619

___
Python tracker 

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

[issue32175] Add hash auto-randomization

[STINNER Victor]

STINNER Victor  added the comment:

By the way, for a few other reasons, Python 3 is more secure than Python 2.7. 
If you care of security, please upgrade!

--

___
Python tracker 

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

[issue32210] Add the versions of the Android SDK and NDK to test.pythoninfo

[STINNER Victor]

STINNER Victor  added the comment:

Oh, I forgot that pythoninfo already has:

call_func(info_add, 'sys.androidapilevel', sys, 'getandroidapilevel')

Well, that's the *build time* API level, not the most useful one, but still 
useful.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Martin Panter]

Martin Panter  added the comment:

P-ganssle seems to be proposing to limit parsing to exactly what 
“datetime.isoformat” produces; i.e. whole number of seconds, milliseconds or 
microseconds. Personally I would prefer it without this limitation, like in 
Mathieu’s patches. But P-ganssle has done some documentation, so perhaps we can 
combine the work of each?

--
nosy: +p-ganssle

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Martin Panter]

Martin Panter  added the comment:

The other difference is Mattieu guarantees ValueError for invalid input 
strings, which I think is good.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

The better is the enemy of the good here.  Given the history of this issue, I 
would rather accept a well documented restrictive parser than wait for a more 
general code to be written.  Note that we can always relax the parsing rules in 
the future.

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Mathieu Dupuy]

Mathieu Dupuy  added the comment:

I'm right now available again to work on this issue. I'll submit a pull
request within a week with all issues addressed

Le 4 déc. 2017 11:45 PM, "Alexander Belopolsky"  a
écrit :

>
> Alexander Belopolsky  added the comment:
>
> The better is the enemy of the good here.  Given the history of this
> issue, I would rather accept a well documented restrictive parser than wait
> for a more general code to be written.  Note that we can always relax the
> parsing rules in the future.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Paul Ganssle]

Paul Ganssle  added the comment:

> The better is the enemy of the good here.  Given the history of this issue, I 
> would rather accept a well documented restrictive parser than wait for a more 
> general code to be written.  Note that we can always relax the parsing rules 
> in the future.

This is in fact the exact reason why I wrote the isoformat parser like I did, 
because ISO 8601 is actually a quite expansive standard, and this is the least 
controversial subset of the features. In fact, I spent quite a bit of time on 
adapting the general purpose ISO8601 parser I wrote for dateutil *into* one 
that only accepts the output of isoformat() because it places a minimum burden 
on ongoing support, so it's not really a matter of waiting for a more general 
parser to be written.

I suggest that for Python 3.7 we *only* support output of isoformat(). Many 
general iso8601 parsers exist, including the one I have already implemented for 
python-dateutil (which will be part of the dateutil 2.7.0 release). We can have 
further discussion later about what exactly should be supported in Python 3.8, 
but even in the pre-release discussions I'm already seeing pushback about some 
of the more unusual 8601 formats, and it's a *lot* easier to explain (in 
documentation) that `fromisoformat()` is intended to be the inverse of 
`isoformat()` than it is to explain which variations of ISO 8601 are and are 
not supported (fractional minutes? if you're following the standard, the 
separator has to be a T, so what other variations of the standard are allowed?).

--

___
Python tracker 

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

[issue32208] Improve semaphore documentation

[Garrett Berg]

Garrett Berg  added the comment:

Gave it a shot!

--
keywords: +patch
pull_requests: +4620
stage: needs patch -> patch review

___
Python tracker 

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

[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string

[Brian Forst]

New submission from Brian Forst :

We're moving some code from Python 2.7 to 3.6 and found a weird performance 
issue using SQLite in-memory and on-disk DBs with the built-in sqlite3 library. 
In Python 2.7, the two update statements below (excerpted from the attached 
file) run in the same amount of time. In Python 3.6 the update statement with 
the table name on a separate line runs 400x-600x slower with the example data 
provided in the file.

"""
UPDATE tbl
SET col2 = NULL
WHERE col1 = ?
"""

"""
UPDATE
  tbl
SET col2 = NULL
WHERE col1 = ?
"""

We have verified this using Python installs from python.org on macOS Sierra and 
Windows 7 for Python 2.7 and 3.6.

We have tried formatting the SQL strings in different ways and it appears that 
the speed change only occurs when the table name is on a different line than 
the "UPDATE".

This also appears to be hitting some type of quadratic behaviour as with 10x 
less records, it only takes 10-15x as long. With the demo in the file we are 
seeing it take 1.6s on the fast string and ~1000s on the slow string.

--
components: Interpreter Core, Library (Lib)
files: sqlite3_27_36_performance_bug.py
messages: 307609
nosy: bforst
priority: normal
severity: normal
status: open
title: sqlite3 400x-600x slower depending on formatting of an UPDATE statement 
in a string
type: performance
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file47315/sqlite3_27_36_performance_bug.py

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

+1 on what Paul said.

Mathieu, the goal for 3.7 will be to get Paul's PR merged.  It will be great if 
you could help in reviewing it.  We can return to the features in your PR 
during the 3.8 development cycle.

--

___
Python tracker 

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

[issue28556] typing.py upgrades

[Ivan Levkivskyi]

Change by Ivan Levkivskyi :


--
pull_requests: +4621

___
Python tracker 

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

[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string

[R. David Murray]

R. David Murray  added the comment:

I can confirm that there is a difference on linux as well, using the sqlite 
version for both 2.7 and 3.7:

rdmurray@pydev:~/python/p27[2.7]>./python sqlite3_27_36_performance_bug.py
First step: 3.22849011421
Second step: 3.2167429924

rdmurray@pydev:~/python/p37[master]>./python 
../p27/sqlite3_27_36_performance_bug.py
First step: 3.2722721099853516
Second step: 4.094221353530884

(I changed time.clock() to time.time()).

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

[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string

[R. David Murray]

R. David Murray  added the comment:

...using the *same* sqlite version...

--

___
Python tracker 

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

[issue32215] sqlite3 400x-600x slower depending on formatting of an UPDATE statement in a string

[R. David Murray]

Change by R. David Murray :


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

[issue32216] Document PEP 557 Data Classes

[Eric V. Smith]

New submission from Eric V. Smith :

The documentation needs to be added.

--
assignee: docs@python
components: Documentation
messages: 307614
nosy: docs@python, eric.smith
priority: high
severity: normal
status: open
title: Document PEP 557 Data Classes
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

[issue28791] update sqlite to latest version before beta 1

[Ned Deily]

Ned Deily  added the comment:


New changeset ca7562a7fea61646c1b40ace04deecf9903d34a1 by Ned Deily (Mariatta) 
in branch 'master':
bpo-28791: Update macOS installer to use SQLite 3.21.0. (#4245)
https://github.com/python/cpython/commit/ca7562a7fea61646c1b40ace04deecf9903d34a1


--

___
Python tracker 

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

[issue28791] update sqlite to latest version before beta 1

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +4622

___
Python tracker 

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

[issue32217] freeze.py fails to work.

[Decorater]

New submission from Decorater :

It seems on my system installed python 3.6.0 when invoking python 3.6.3's 
freeze.py it seems to fail with this traceback:

python ..\externals\cpython\Tools\freeze\freeze.py pyeimport.py
Traceback (most recent call last):
  File "..\externals\cpython\Tools\freeze\freeze.py", line 491, in 
main()
  File "..\externals\cpython\Tools\freeze\freeze.py", line 220, in main
flagged_version = version + sys.abiflags
AttributeError: module 'sys' has no attribute 'abiflags'

--
components: Demos and Tools, Windows
messages: 307615
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: freeze.py fails to work.
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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Paul Ganssle]

Paul Ganssle  added the comment:

> The other difference is Mattieu guarantees ValueError for invalid input 
> strings, which I think is good.

I forgot to address this - but I don't think this is a difference in 
approaches. If you pass `None` or an int or something, the problem is with the 
type, not the value, so at a minimum you're looking at TypeError and ValueError 
- and those are the only exceptions raised in my patch.

(I'll note that my patch does not accept bytes, though this is something of an 
artificial limitation, since the patch makes use of the fact that all valid 
isoformat() strings will contain at most exactly 1 non-ascii character in 
position 10, so we could easily work around this, but I think the trend for 
CPython is to avoid blurring the lines between bytes and str rather than 
encouraging their interchangeable use.)

--

___
Python tracker 

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

[issue28791] update sqlite to latest version before beta 1

[Ned Deily]

Ned Deily  added the comment:


New changeset a72e7bf563d5a9fb706a1775f5ae883a91b8a99f by Ned Deily in branch 
'3.6':
[3.6] bpo-28791: Update macOS installer to use SQLite 3.21.0. (#4245) (#4711)
https://github.com/python/cpython/commit/a72e7bf563d5a9fb706a1775f5ae883a91b8a99f


--

___
Python tracker 

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

[issue28791] update SQLite libraries for Windows and macOS installers

[Ned Deily]

Ned Deily  added the comment:

> Should we mark issue 30952 'deferred blocker' too?

No, that's a different matter.  AFAICT, there is no standard option for that.

--

___
Python tracker 

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

[issue32217] freeze.py fails to work.

[R. David Murray]

R. David Murray  added the comment:

Does the 3.6.0 freeze fail under 3.6.0, or the 3.6.3 freeze fail under 3.6.3?  
If not, there's no bug to report.

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

[issue28791] update SQLite libraries for Windows and macOS installers

[Ned Deily]

Ned Deily  added the comment:

I've updated the macOS installer for 3.7.0 and for 3.6.4.  I'll leave this open 
for possible updating the Windows installer for 3.6.x (OK by me) and for 
possible updates for 2.7.x.

--
stage: patch review -> needs patch
title: update sqlite to latest version before beta 1 -> update SQLite libraries 
for Windows and macOS installers
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