[issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

The approach I've taken in my PR is similar to the one that Arfrever proposed 
(albeit different in the details due to other changes in the startup code since 
that patch was written).

For the embedding case, I've simply noted in the What's New section of the 
porting guide that embedding applications need to configure a 
`error::BytesWarning` filter explicitly if they want to treat BytesWarning as 
errors (in addition to setting the flag to request that the warnings be emitted 
in the first place).

--

___
Python tracker 

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



[issue32222] pygettext doesn't extract docstrings for functions with type annotated params

2017-12-06 Thread Toby Harradine

Toby Harradine  added the comment:

Another correction; I said that this is occurring for return type annotations; 
this is not true. This is only occurring for functions with annotated 
*arguments*.

The cause of this issue is in pygettext's TokenEater.__suiteseen method. This 
method eats tokens until it sees a colon operator, after which it assumes a 
function docstring may follow. In the case of a function with annotated 
arguments, obviously this is incorrect, as colons would appear before the final 
colon of the 'suite'.

--

___
Python tracker 

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



[issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options

2017-12-06 Thread Nick Coghlan

Change by Nick Coghlan :


--
pull_requests: +4647
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



[issue32098] Hardcoded value in Lib/test/test_os.py:L1324:URandomTests.get_urandom_subprocess()

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

https://github.com/python/cpython/commit/fb77e0d855e841f42c3fa504efe79eefca9efafb

--

___
Python tracker 

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



[issue32098] Hardcoded value in Lib/test/test_os.py:L1324:URandomTests.get_urandom_subprocess()

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


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



[issue32212] few discrepancy between source and docs in logging

2017-12-06 Thread R. David Murray

R. David Murray  added the comment:

It does matter, though, because in Python you can specify a positional argument 
as if it were a keyword argument if you use the name from the source rather 
than the documented name.  We have made other doc corrections along these 
lines.  We've even done it for C functions where you can't specify the argument 
as if it were a keyword argument, though that is considerably more rare.

That's a different question from the question of whether typing/linters should 
care, though.  Arguably they should recommend specifying them as positionals.

--
status: pending -> open

___
Python tracker 

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



[issue30862] parent logger should also check the level

2017-12-06 Thread TaoQingyun

TaoQingyun <845767...@qq.com> added the comment:

Sorry to disturb. When calling `logging.basicConfig(level=logging.ERROR)`, I 
expect only the ERROR or above level will be logged. so the level argument if 
set should also pass to the handler.

--

___
Python tracker 

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



[issue32239] decimal module exception args incorrect for c module

2017-12-06 Thread Joshua Ringer

New submission from Joshua Ringer :

Exception instance args for decimal errors are supposed to be a descriptive 
string. However, in the c module, they are currently a list of one containing 
the underlying exception class. The pure python module is correct.

See the following interpreter output for further detail:

Python 3.6.3 (default, Oct  4 2017, 06:09:15)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from _pydecimal import Decimal
>>> Decimal('badstring')
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_pydecimal.py",
 line 597, in __new__
"Invalid literal for Decimal: %r" % value)
  File 
"/usr/local/Cellar/python3/3.6.3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/_pydecimal.py",
 line 4081, in _raise_error
raise error(explanation)
decimal.InvalidOperation: Invalid literal for Decimal: 'badstring'
>>> from _decimal import Decimal
>>> Decimal('badstring')
Traceback (most recent call last):
  File "", line 1, in 
decimal.InvalidOperation: []

--
components: Library (Lib)
messages: 307788
nosy: joshringer
priority: normal
severity: normal
status: open
title: decimal module exception args incorrect for c module
type: behavior
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



[issue32098] Hardcoded value in Lib/test/test_os.py:L1324:URandomTests.get_urandom_subprocess()

2017-12-06 Thread Pablo Galindo Salgado

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +4646
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



[issue31972] Inherited docstrings for pathlib classes are confusing

2017-12-06 Thread Pablo Galindo Salgado

Change by Pablo Galindo Salgado :


--
pull_requests: +4645

___
Python tracker 

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



[issue31972] Inherited docstrings for pathlib classes are confusing

2017-12-06 Thread Éric Araujo

Change by Éric Araujo :


--
pull_requests:  -4644

___
Python tracker 

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



[issue31972] Inherited docstrings for pathlib classes are confusing

2017-12-06 Thread Pablo Galindo Salgado

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +4644
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



[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

2017-12-06 Thread paul j3

paul j3  added the comment:

In the recently pushed, https://bugs.python.org/issue14191, "argparse doesn't 
allow optionals within positionals"

we added new parsing functionality by defining a new parser method:

parse_intermixed_args

It added functionality without requiring a new parameter for the parser (no 
point in confusing users with parameters they don't need or understand).  It 
was also a good fit because it worked on top of the default parser, fidling 
with the nargs to parse positionals and options in different runs. 

I would like to see something similar for this problem.  Define a

parser.parse_opt_args() method 

that tries, as much as possible to follow the optparse strategy.  As I 
commented previously, the difference in behavior starts at the top.  

argparse distinguishes between flag (optiona) and argument strings based on the 
dash(es), and then allocates strings to the Actions based on that pattern and 
nargs.  It also alternates between handling positionals and optionals.

optparse passes all the remaining strings to an Action, lets it consume what it 
wants, and resumes parsing with the remainder.  It does not handle positionals; 
those are just accumulated in an 'extras' list (sort of like parse_known_args 
without any defined positionals).

An unknown in this approach is whether the argparse.Action class(es) can be 
adapted to this 'consume what you want' strategy.  It would be nice if such an 
alternative parser could be written that doesn't require any changes to the 
Action.  We don't have to go so far as to allow custom Action classes that 
imitate optparse Options.

But I haven't thought about this problem since 2013.  I don't sense either, 
from other bug/issues, or Stackoverflow questions, that this is a pressing need.

--

___
Python tracker 

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



[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

For the POSIX case, we're going to fix the implementation to always handle that 
the same way as it does the "C" locale: 
https://bugs.python.org/issue30672#msg307784

So the main question to address with the refactoring here will be capturing the 
expected behaviour for the 'locale setting is an empty string' case.

--

___
Python tracker 

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



[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

As discussed in https://bugs.python.org/issue32238 and 
https://mail.python.org/pipermail/python-dev/2017-December/151105.html, I now 
think the right answer for the POSIX case is to ensure the legacy locale 
detection logic always treats that the same way as it does the C locale.

LANG=UTF-8 I'm still not sure about - as I understand it, that's a partial 
locale that only defines LC_CTYPE, which may be why the libc implementation 
ignores it if you try to set it as a general category default.

--

___
Python tracker 

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



[issue32238] Handle "POSIX" in the legacy locale detection

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

Oops, I forgot I already had an open issue for this discrepancy - I just hadn't 
decided how to resolve it yet.

Marking as a duplicate of https://bugs.python.org/issue30672

--
superseder:  -> PEP 538: Unexpected locale behaviour on *BSD (including Mac OS 
X)

___
Python tracker 

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



[issue32238] Handle "POSIX" in the legacy locale detection

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

Added a dependency on https://bugs.python.org/issue32002, as we should finish 
the test case refactoring proposed there before adjusting the `POSIX` locale 
handling on macOS and other *BSD systems.

--
dependencies: +test_c_locale_coercion fails when the default LC_CTYPE != "C"

___
Python tracker 

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



[issue32238] Handle "POSIX" in the legacy locale detection

2017-12-06 Thread Nick Coghlan

New submission from Nick Coghlan :

Right now, the legacy locale detection introduced in PEP 538 doesn't trigger 
for "LANG=POSIX" and "LC_CTYPE=POSIX" on macOS and other *BSD systems.

This is because we're looking specifically for "C" as the response from 
"setlocale(LC_CTYPE, NULL)", which works on Linux (where glibc reports "C" if 
you configured "POSIX"), but not on *BSD systems (where POSIX and C behave the 
same way, but are still reported as distinct locales).

As per Jakub Wilk's comments at 
https://mail.python.org/pipermail/python-dev/2017-December/151105.html, this 
isn't right: we should allow either string to be returned from setlocale, and 
consider both of them as indicating a legacy locale to be coerced to an 
explicitly UTF-8 based one if possible.

--
components: FreeBSD, Interpreter Core, Unicode, macOS
messages: 307781
nosy: ezio.melotti, koobs, ncoghlan, ned.deily, ronaldoussoren, vstinner
priority: normal
severity: normal
stage: test needed
status: open
title: Handle "POSIX" in the legacy locale detection
type: behavior
versions: Python 3.7, Python 3.8

___
Python tracker 

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



[issue32234] Add context management to mailbox.Mailbox

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

I don't know the mailbox API particularly well, but the fact the object offers 
all three of lock(), unlock() and close() as methods does imply a fair bit of 
inherent ambiguity.

One option would be to offer a module level "mailbox.locked()" API to handle 
the lock/unlock case, and then have native context management on the mailbox 
itself that was akin to "contextlib.closing".


(Note regarding contextlib.locked(): the reason we don't currently have that is 
because there's no consistent protocol for locking method names. 
acquire()/release() and lock()/unlock() would be the most popular pairings, so 
we could technically offer both "contextlib.acquired()" and 
"contextlib.locked()", but the duplication still seems a bit dubious to me)

--

___
Python tracker 

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



[issue30718] open builtin function: specifying the size of buffer has no effect for text files

2017-12-06 Thread Alexey Izbyshev

Alexey Izbyshev  added the comment:

Yes, clarifying buffering for text mode in open() would be nice.

@direprobs: just in case you didn't know, you can achieve what you want with 
something like the following in pre-3.7:

with open("/dev/null", "wb", buffering=10) as outb, \
io.TextIOWrapper(outb, write_through=True) as out:
out.write("x" * 20)

Sadly, write_through can't be passed to open(), but it can be changed on 
existing TextIOWrapper since 3.7 (via new reconfigure() method).

--
nosy: +izbyshev

___
Python tracker 

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



[issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

Oh, more tests are failing:

test_ensurepip leaked [1, 1, 1] references, sum=3
test_hashlib leaked [1, 1, 1] references, sum=3
test_importlib leaked [5, 5, 5] references, sum=15

--

___
Python tracker 

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



[issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3

2017-12-06 Thread STINNER Victor

New submission from STINNER Victor :

The commit eea3cc1ef0dec0af193eedb4c1164263fbdfd8cc introduced the following 
regression:

vstinner@apu$ make && ./python -m test -R 3:3 test_xml_etree
(...)
test_xml_etree leaked [1, 1, 1] references, sum=3

--
messages: 30
nosy: nascheme, vstinner
priority: normal
severity: normal
status: open
title: test_xml_etree leaked [1, 1, 1] references, sum=3
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



[issue32224] socket.create_connection needs to support full IPv6 argument

2017-12-06 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

I think we still want the full tuple passed to connect().  We may want
to truncate the tuple when used for other purposes.

Le 07/12/2017 à 00:41, Matthew Stoltenberg a écrit :
> 
> Matthew Stoltenberg  added the comment:
> 
> The naive change is to have the host, port tuple assignment use only the 
> first two values from address. I can open a PR with that change (and update 
> the docstring for the function) if that's the right change. For reference, 
> the python socketpair implementation (if _socket is missing it) ignores 
> flow_info and scope_id, but I'm not sure that's the right thing to do.
> 
> --
> 
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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



[issue32236] open() shouldn't silently ignore buffering=1 in binary mode

2017-12-06 Thread Alexey Izbyshev

New submission from Alexey Izbyshev :

The fact that "buffering=1" is usable only in text mode is documented for 
open(). In binary mode, setting buffering to 1 is silently ignored and 
equivalent to using default buffer size. I argue that such behavior is:

1. Inconsistent
For example, attempts to use buffering=0 in text mode or to specify encoding in 
binary mode raise ValueError.

2. Dangerous
Consider the following code fragment running on *nix (inspired by real-world 
code):

with open("fifo", "wb", buffering=1) as out:
for line in lines:
out.write(line)

"fifo" refers to a FIFO (named pipe). For each line, len(line) <= PIPE_BUF. 
Because of line buffering, such code must be able to safely assume that each 
write() is atomic, so that even in case of multiple writers no line read by a 
FIFO reader will ever get intermixed with another line. And it's so in Python 
2. After migration to Python 3 (assuming that line is now bytes), this code 
still works on Linux because of two factors:
a) PIPE_BUF is 4096, and so is the default IO buffer size (usually)
b) When a write() is going to overflow the buffer, BufferedWriter first flushes 
and then processes the new write() (based on my experiment). So, each OS 
write() is called with complete lines only and is atomic per (a).

But PIPE_BUF is 512 on Mac OS X (I don't know about default buffer size). So, 
we are likely to have a subtle 2-to-3 migration issue.

I suggest to raise a ValueError if buffering=1 is used for binary mode. Note 
that issue 10344 (msg244354) and issue 21332 would have been uncovered earlier 
if it was done from the beginning.

--
components: IO
messages: 307775
nosy: izbyshev, pitrou
priority: normal
severity: normal
status: open
title: open() shouldn't silently ignore buffering=1 in binary mode
type: behavior
versions: Python 3.7

___
Python tracker 

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



[issue32224] socket.create_connection needs to support full IPv6 argument

2017-12-06 Thread Matthew Stoltenberg

Matthew Stoltenberg  added the comment:

The naive change is to have the host, port tuple assignment use only the first 
two values from address. I can open a PR with that change (and update the 
docstring for the function) if that's the right change. For reference, the 
python socketpair implementation (if _socket is missing it) ignores flow_info 
and scope_id, but I'm not sure that's the right thing to do.

--

___
Python tracker 

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



[issue13322] buffered read() and write() does not raise BlockingIOError

2017-12-06 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Yes, I think adding a note in the docs is reasonable.

--

___
Python tracker 

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



[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

N! I loved Subversion so much! ... just kidding. Thanks for getting rid of 
Subversion.

It became much easier to build CPython on Windows nowadays!

--

___
Python tracker 

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



[issue32224] socket.create_connection needs to support full IPv6 argument

2017-12-06 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Also note that a regular socket.connect() call supports the full form address:

>>> sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
>>> sock.connect(('::1', 12345, 0, 0))

Matthew, are you interested in submitting a Github PR for this issue?

--
nosy: +gregory.p.smith, pitrou
stage:  -> needs patch
versions: +Python 2.7, Python 3.7 -Python 3.4

___
Python tracker 

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



[issue13322] buffered read() and write() does not raise BlockingIOError

2017-12-06 Thread Alexey Izbyshev

Alexey Izbyshev  added the comment:

Yes, your claim is confirmed by the fact that there have been little interest 
in this issue since 2011. Still, non-blocking behavior is incorrectly specified 
in the docs and is inconsistent (as investigated by Martin). And obscure errors 
like in my example or in Issue 13858 show that I/O stack is confused too. To 
prevent people from tripping on it, would you consider recommending against 
usage of I/O stack for non-blocking operations in io module docs?

--

___
Python tracker 

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



[issue30450] Pull Windows dependencies from GitHub rather than svn.python.org

2017-12-06 Thread Zachary Ware

Zachary Ware  added the comment:

This has been backported and working for nearly 3 months now; closing.

As for whether to continue operating svn.python.org now that we're officially 
away from it: that can be determined elsewhere, probably by the box dying and 
deciding for us :)

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



[issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

Thank you!

--

___
Python tracker 

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



[issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe crashing with error code C0000005

2017-12-06 Thread Zachary Ware

Zachary Ware  added the comment:

The worker is happy, closing the issue.

--
keywords: +buildbot
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue32212] few discrepancy between source and docs in logging

2017-12-06 Thread Vinay Sajip

Vinay Sajip  added the comment:

I don't have a problem with tweaking the documentation where discrepancies are 
found between source and doc for keyword arguments, but in both the examples 
you give, the arguments are positional, not keyword. Therefore in my opinion 
your code should be e.g.

logger.setLevel(logging.DEBUG)

and

stream_handler.setFormatter(formatter)

without using keyword arguments. For positionals, as I see it, the name 
shouldn't matter, nor should any minor discrepancy between doc and source.

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

___
Python tracker 

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



[issue30862] parent logger should also check the level

2017-12-06 Thread Vinay Sajip

Vinay Sajip  added the comment:

> Maybe I misunderstand.

I think you do misunderstand. The level of the handler created by basicConfig 
doesn't have any level set, so it will process any message it is asked to 
handle. This is working as designed.

--

___
Python tracker 

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



[issue13322] buffered read() and write() does not raise BlockingIOError

2017-12-06 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Generally I doubt anyone is using the non-blocking semantics of the Python 3 
I/O stack.  People doing non-blocking I/O generally do it with sockets instead, 
which tend to reproduce quite literally the POSIX behaviour and error codes.

--
versions:  -Python 3.2, Python 3.3, 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



[issue31506] Improve the error message logic for object_new & object_init

2017-12-06 Thread Sanyam Khurana

Change by Sanyam Khurana :


--
pull_requests: +4643
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



[issue13322] buffered read() and write() does not raise BlockingIOError

2017-12-06 Thread Alexey Izbyshev

Alexey Izbyshev  added the comment:

For added fun: at least one part of the standard library doesn't expect None 
returns from read() in the buffering layer.

>>> import os
>>> r, w = os.pipe2(os.O_NONBLOCK)
>>> f = os.fdopen(r, 'r')
>>> f.read()
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/izbyshev/workspace/cpython/Lib/codecs.py", line 321, in decode
data = self.buffer + input
TypeError: can't concat NoneType to bytes

Note that nonblock-none.patch doesn't seem to address that.

--
nosy: +izbyshev
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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



[issue18943] argparse: default args in mutually exclusive groups

2017-12-06 Thread paul j3

paul j3  added the comment:

That's not how flagged (optionals) arguments work.

The default value is used if the flag is not provided at all.  One of your 
arguments is a 'store_true'.  Its default value if False, which is changed to 
True if the '--device-get-capabilities' flag is provided.

"nargs='?'" provides a third option, assigning the 'const' value if the flag is 
used without an argument.

In any case your problem isn't with a required mutually exclusive group 
(defaults or not).  It has to do with understanding optionals and their 
defaults.

--

___
Python tracker 

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



[issue32123] Make the API of argparse.HelpFormatter public

2017-12-06 Thread paul j3

paul j3  added the comment:

A difficulty with writing a public API is that useful changes can occur at 
almost any level of the class.

The existing subclasses modify small, but deep methods, ones that handle things 
like line wrapping.

On the other hand, most of the issues you cite deal with higher level issues, 
either the top most method of the formatter, or alternatives to 
parser.format_help or parser._get_formatter (which create and populate a 
formatter object).

I've also responded to issues dealing with intermediate levels things, like the 
need for a more robust usage formatting, and changing how help lines are 
constructed.

The argparse documentation is a mix of how-to and formal API.  Mostly it 
describes how to perform common parsing tasks.  Even though argparse consists 
of classes, the documentation does not formally describe the classes, and their 
subclassing and all methods.  It's not a reference API.

--
nosy: +paul.j3

___
Python tracker 

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



[issue18943] argparse: default args in mutually exclusive groups

2017-12-06 Thread Vincas Dargis

Vincas Dargis  added the comment:

On 2017-12-06 19:43, paul j3 wrote:
> With one flag but not its argument, I get the error that you display.  That 
> has nothing to do with the grouping.
> 
> 0932:~/mypy/argdev$ python3 issue18943.py --ptz-get-status
> usage: issue18943.py [-h]
>   (--device-get-capabilities | --ptz-absolute-move x y z 
> | --ptz-get-status MEDIA_PROFILE)
> issue18943.py: error: argument --ptz-get-status: expected one argument

In my example I pasted, I had hardcoded arguments:

```
pprint.pprint(parser.parse_args(['--ptz-get-status']))
``

I expected `python myscript.py --ptz-get-status` to work, because default value 
is set.

I do not compute that "With one flag but not its argument", sorry. It has 
default argument set, shoudn't that work?

Thanks!

--

___
Python tracker 

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



[issue32234] Add context management to mailbox.Mailbox

2017-12-06 Thread sblondon

sblondon  added the comment:

Currently, the implementation of .close() methods call flush() and
unlock() if it's needed.

About the ambiguity for the enter call, I think the context manager
should provide access to Mailbox, not a lock. If a lock is needed, we
could imagine another context manager:
with mailbox.Mailbox as mbox:
   #read messages, ...
   with mbox.lock():
  #actions that need lock

Do you think it's better?

--

___
Python tracker 

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



[issue18943] argparse: default args in mutually exclusive groups

2017-12-06 Thread paul j3

paul j3  added the comment:

Did you copy the output right?  Testing your parser:

Without any arguments, I get the exclusive group error - the group is required:

0930:~/mypy/argdev$ python3 issue18943.py 
usage: issue18943.py [-h]
 (--device-get-capabilities | --ptz-absolute-move x y z | 
--ptz-get-status MEDIA_PROFILE)
issue18943.py: error: one of the arguments --device-get-capabilities 
--ptz-absolute-move --ptz-get-status is required

0931:~/mypy/argdev$ python3 --version
Python 3.5.2

With one flag but not its argument, I get the error that you display.  That has 
nothing to do with the grouping.

0932:~/mypy/argdev$ python3 issue18943.py --ptz-get-status
usage: issue18943.py [-h]
 (--device-get-capabilities | --ptz-absolute-move x y z | 
--ptz-get-status MEDIA_PROFILE)
issue18943.py: error: argument --ptz-get-status: expected one argument

--

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Stefan Krah

Change by Stefan Krah :


--
assignee:  -> skrah
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> compile error

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Stefan Krah

Stefan Krah  added the comment:


New changeset bd4ed77f73d37df325fc8f1e193b3ce6bc08094d by Stefan Krah in branch 
'master':
bpo-32233: Fix build with --with-system-libmpdec. (#4739)
https://github.com/python/cpython/commit/bd4ed77f73d37df325fc8f1e193b3ce6bc08094d


--

___
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()

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:


New changeset 92a3c6f493ad411e4cf0acdf305ef4876aa90669 by Victor Stinner in 
branch 'master':
bpo-32030: Add _PyImport_Fini2() (#4737)
https://github.com/python/cpython/commit/92a3c6f493ad411e4cf0acdf305ef4876aa90669


--

___
Python tracker 

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



[issue25910] Fixing links in documentation

2017-12-06 Thread Jim Fulton

Change by Jim Fulton :


--
nosy:  -j1m

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Stefan Krah

Change by Stefan Krah :


--
pull_requests: +4642
stage:  -> patch review

___
Python tracker 

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



[issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

See bpo-31170 for expat 2.2.3 bug (and maybe also bpo-30947).

--
nosy: +vstinner

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Stefan Krah

Stefan Krah  added the comment:

I suggest to restore the logic from 75c0d4f6bb97e723adc3a03c0ff6aaaee0c6981a .

--

___
Python tracker 

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



[issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205

2017-12-06 Thread Serhiy Storchaka

Change by Serhiy Storchaka :


--
resolution:  -> third party

___
Python tracker 

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



[issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205

2017-12-06 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

This means that you need to update the expat library. Expat version 2.2.3 
contains a bug, it affects not only Python, but all depending applications.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue32234] Add context management to mailbox.Mailbox

2017-12-06 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

There is an ambiguity. What should the context manager do? Should it call a 
close() on exit (as the OP implies)? Or call lock() on enter and unlock() on 
exit as in Barry's example? Both behaviors look reasonable.

"In the face of ambiguity, refuse the temptation to guess" and "Explicit is 
better than implicit". This is perhaps the reason why this feature is not 
implemented yet. Perhaps there were discussions about this in the past.

contextlib.closing() can be used for explicit requesting the first behavior. 
Maybe it's a time to add contextlib.locked() or something like.

--
nosy: +ncoghlan, r.david.murray, serhiy.storchaka, yselivanov

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Stefan Krah

Stefan Krah  added the comment:

At some point linking explicitly against libm was added. The build
still worked until 8acaa31eec removed detect_math_libs().

--
nosy: +skrah

___
Python tracker 

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



[issue32235] [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 3.6 branches 20171205

2017-12-06 Thread Matthias Klose

New submission from Matthias Klose :

Seen with recent Debian and Ubuntu builds, 

builds configured with --with-system-expat, expat version 2.2.3.

==
ERROR: test_expat224_utf8_bug (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_xml_etree.py", line 1513, in 
test_expat224_utf8_bug
self.check_expat224_utf8_bug(text)
  File "/usr/lib/python2.7/test/test_xml_etree.py", line 1500, in 
check_expat224_utf8_bug
root = ET.XML(xml)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1311, in XML
parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1657, in feed
self._parser.Parse(data, 0)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc3 in position 2047: 
unexpected end of data

==
ERROR: test_expat224_utf8_bug_file (test.test_xml_etree.BugsTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_xml_etree.py", line 1518, in 
test_expat224_utf8_bug_file
root = ET.fromstring(raw)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1311, in XML
parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1657, in feed
self._parser.Parse(data, 0)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1020-1021: 
unexpected end of data

--
messages: 307749
nosy: doko
priority: normal
severity: normal
status: open
title: [2.7 regression] test_xml_etree test_xml_etree_c failures with 2.7 and 
3.6 branches 20171205

___
Python tracker 

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



[issue25910] Fixing links in documentation

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:


New changeset 1b4587a2462fc05a14be87123083322103a1f55b by Victor Stinner 
(Sanyam Khurana) in branch 'master':
bpo-25910: Fixes redirection from http to https (#4674)
https://github.com/python/cpython/commit/1b4587a2462fc05a14be87123083322103a1f55b


--
nosy: +vstinner

___
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()

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:


New changeset 6bf992a1ac6f3f4d0f83ead9c6403a76afdbe6eb by Victor Stinner in 
branch 'master':
bpo-32030: Add pymain_get_global_config() (#4735)
https://github.com/python/cpython/commit/6bf992a1ac6f3f4d0f83ead9c6403a76afdbe6eb


--

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Ned Deily

Change by Ned Deily :


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

___
Python tracker 

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



[issue13959] Re-implement parts of imp in pure Python

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:


New changeset 672b6baa71010f236ee8c8ce912e98cb542385c6 by Victor Stinner in 
branch 'master':
bpo-32030: pass interp to _PyImport_Init() (#4736)
https://github.com/python/cpython/commit/672b6baa71010f236ee8c8ce912e98cb542385c6


--
nosy: +vstinner

___
Python tracker 

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



[issue32232] building extensions as builtins is broken in 3.7

2017-12-06 Thread Ned Deily

Change by Ned Deily :


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

___
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()

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
pull_requests: +4641

___
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()

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:


New changeset 672b6baa71010f236ee8c8ce912e98cb542385c6 by Victor Stinner in 
branch 'master':
bpo-32030: pass interp to _PyImport_Init() (#4736)
https://github.com/python/cpython/commit/672b6baa71010f236ee8c8ce912e98cb542385c6


--

___
Python tracker 

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



[issue13959] Re-implement parts of imp in pure Python

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
pull_requests: +4640

___
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()

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
pull_requests: +4639

___
Python tracker 

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



[issue32234] Add context management to mailbox.Mailbox

2017-12-06 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

Yes, I think this is a good idea.  Would you like to submit a PR for it?

FWIW, we have this code in Mailman 3:

class Mailbox(MMDF):
"""A mailbox that interoperates with the 'with' statement."""

def __enter__(self):
self.lock()
return self

def __exit__(self, *exc):
self.flush()
self.unlock()
# Don't suppress the exception.
return False

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



[issue32030] PEP 432: Rewrite Py_Main()

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
pull_requests: +4638

___
Python tracker 

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



[issue32234] Add context management to mailbox.Mailbox

2017-12-06 Thread sblondon

New submission from sblondon :

mailbox.Mailbox has a .close() method that should be called at the end of 
Mailbox use.
I think it would be nice to use Mailbox instances with a 'with' statement so 
.close() will be called it automatically. So there is no need to check for 
which format it's required (yes for mbox, no for Maildir, etc.)

So the source code:
mbox = mailbox.mbox("/path/to/mbox")
...
mbox.close()

could become:
with mailbox.mbox("/path/to/mbox") as mbox:
...

--
components: Library (Lib)
messages: 307744
nosy: sblondon
priority: normal
severity: normal
status: open
title: Add context management to mailbox.Mailbox
type: enhancement

___
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

2017-12-06 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

> Maybe we should just close this issue as 'wont fix' then.

I would be okay with any of these resolutions:

* Close as `wont fix`
* Just call `ip link` (without list)
* Add a new getter such that both `ip link` and `ip link list` are called.

How to handle exceptions in the getters should be addressed in a new issue.

--

___
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

2017-12-06 Thread Barry A. Warsaw

Barry A. Warsaw  added the comment:

On Dec 6, 2017, at 02:06, Xavier de Gaye  wrote:
> 
> Whatever the change made to fix this issue, it is not possible to add a test 
> case for this change.

Even with say, exception raising mocks for the getters?

> So following the suggestion made by Barry in PR 4696, we can add (in another 
> issue) a new keyword parameter to getnode() named 'methods' whose value may 
> be None (the default, meaning try all the known methods) or a tuple 
> containing a subset of the following methods ('unix', 'ifconfig', 'ip', 
> 'arp', 'lanscan', 'netstat',  'random') that would raise an exception if the 
> value cannot be obtained using one of the requested method tried in the 
> requested order. This would also improve the documentation on the methods 
> getnode() is using. Then if we decide to make the change for 'ip link' in the 
> current issue, one can add a test case that would first test for the 
> avaibility of the ip command and if the command exists would fail if 
> getnode(methods=('ip',)) raises an exception.

I am thinking about this slightly differently.

What if getnode() accepted a `handler` argument and the code was changed to 
something like this:

1 file changed, 4 insertions(+), 2 deletions(-)
Lib/uuid.py | 6 --

modified   Lib/uuid.py
@@ -656,7 +656,7 @@ def _random_getnode():

 _node = None

-def getnode():
+def getnode(handler=None):
 """Get the hardware address as a 48-bit positive integer.

 The first time this runs, it may launch a separate program, which could
@@ -677,7 +677,9 @@ def getnode():
 for getter in getters + [_random_getnode]:
 try:
 _node = getter()
-except:
+except Exception as error:
+if handler is not None:
+handler(getter, error)
 continue
 if _node is not None:
 return _node

`handler` could log some diagnostics, reraise the exception, raise 
StopIteration, etc.  Then we could use that in the test suite too, because we 
could mock a getter to raise an exception and then pass in a handler that 
verified the exception was raised with the expected getter.

(Maybe we spell `handler` as `error_handler`.)

--

___
Python tracker 

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



[issue32232] building extensions as builtins is broken in 3.7

2017-12-06 Thread Matthias Klose

Matthias Klose  added the comment:

that patch lets the build succeed. two additional includes and a little bit of 
shuffling

--
keywords: +patch
Added file: https://bugs.python.org/file47325/ext-as-builtins.diff

___
Python tracker 

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



[issue32229] Simplify hiding developer warnings in user facing applications

2017-12-06 Thread R. David Murray

R. David Murray  added the comment:

Ah, OK, that makes more sense.  I don't run into warnings other than 
DeprecationWarnings in practice, so I tend to forget about them :)

I think specifying warnings filters is pretty inscrutable, in general.

--

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Matthias Klose

Matthias Klose  added the comment:

proposed patch, however I don't know the rationale for that change compared to 
3.7alpha2.

--
keywords: +patch
Added file: https://bugs.python.org/file47324/issue32233.diff

___
Python tracker 

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



[issue32233] [3.7 Regression] build with --with-system-libmpdec is broken

2017-12-06 Thread Matthias Klose

New submission from Matthias Klose :

in setup.py, for the _decimal module the libararies are now set exclusively to 
['m'], without checking if this is really needed, and overriding the external 
mpdec library, breaking the build.  Is there any reason to override that?

--
components: Build
messages: 307738
nosy: doko
priority: normal
severity: normal
status: open
title: [3.7 Regression] build with --with-system-libmpdec is broken
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



[issue32229] Simplify hiding developer warnings in user facing applications

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

Note: for consistency with the underlying action names, the API should probably 
be called "warnings.ignore_warnings". I'd still keep the proposed parameter 
name as "show" though (and we may want to consider introducing that as a more 
semantically meaningful alias for "default").

--

___
Python tracker 

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



[issue32229] Simplify hiding developer warnings in user facing applications

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

Warnings aren't off by default in general - we just add implicit "ignore" 
filters for a few specific types.

So the primary functionality is to opt in to hiding *all* warnings, but to do 
it in a way that can be overridden by PYTHONWARNINGS, the interpreter's "-W" 
switch and the new "-X dev" mode.

For that, the usage looks like:

import warnings
warnings.hide_warnings()

Essentially, it flips the default behaviour over to "ignore everything", but 
reverts to the regular default if there are any config settings supplied.

The odd structure of my opening message arises from the fact that *given* such 
a modified default, it's then surprisingly tricky to say "hide warnings, except 
for those from modules I'm responsible for". That latter complication then 
becomes the rationale for the design of the proposed "show" parameter to carve 
out exceptions to the overall "hide everything" filter.

--

___
Python tracker 

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



[issue32232] building extensions as builtins is broken in 3.7

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
nosy: +eric.snow, ncoghlan

___
Python tracker 

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



[issue32232] building extensions as builtins is broken in 3.7

2017-12-06 Thread Matthias Klose

New submission from Matthias Klose :

building extensions statically in linking these into the python binary is 
currently broken on 3.7.

I'm attaching the change that worked for me in 3.7alpha2, but doesn't work 
anymore with alpha3. Currently investigating.  When building extensions as 
builtins, these should benefit from the knowledge about the core interpreter.

x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O3 -Wall -Wstrict-prototypes -g 
-fdebug-prefix-map=/home/packages/python/3.7/python3.7-3.7.0~a3=. 
-fstack-protector-strong -Wformat -Werror=format-security-std=c99 -Wextra 
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration  -IObjects -IInclude -IPython -I. 
-I../Include -Wdate-time -D_FORTIFY_SOURCE=2   -DPy_BUILD_CORE  -c 
../Modules/_elementtree.c -o Modules/_elementtree.o
In file included from ../Include/pyatomic.h:10:0,
 from ../Include/Python.h:53,
 from ../Modules/_elementtree.c:16:
../Modules/_elementtree.c: In function 'element_dealloc':
../Include/pystate.h:314:34: error: '_PyRuntime' undeclared (first use in this 
function); did you mean 'PyRun_File'?
 #  define _PyThreadState_Current _PyRuntime.gilstate.tstate_current
  ^
../Include/pyatomic.h:533:5: note: in expansion of macro 
'_Py_atomic_load_explicit'
 _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed)
 ^~~~
../Include/pystate.h:316:31: note: in expansion of macro 
'_Py_atomic_load_relaxed'
  ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
   ^~~
../Include/pystate.h:316:56: note: in expansion of macro 
'_PyThreadState_Current'
  ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
^~
../Include/object.h:1069:34: note: in expansion of macro 'PyThreadState_GET'
 PyThreadState *_tstate = PyThreadState_GET(); \
  ^
../Modules/_elementtree.c:634:5: note: in expansion of macro 
'Py_TRASHCAN_SAFE_BEGIN'
 Py_TRASHCAN_SAFE_BEGIN(self)
 ^~
../Include/pystate.h:314:34: note: each undeclared identifier is reported only 
once for each function it appears in
 #  define _PyThreadState_Current _PyRuntime.gilstate.tstate_current
  ^
../Include/pyatomic.h:533:5: note: in expansion of macro 
'_Py_atomic_load_explicit'
 _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed)
 ^~~~
../Include/pystate.h:316:31: note: in expansion of macro 
'_Py_atomic_load_relaxed'
  ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
   ^~~
../Include/pystate.h:316:56: note: in expansion of macro 
'_PyThreadState_Current'
  ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
^~
../Include/object.h:1069:34: note: in expansion of macro 'PyThreadState_GET'
 PyThreadState *_tstate = PyThreadState_GET(); \
  ^
../Modules/_elementtree.c:634:5: note: in expansion of macro 
'Py_TRASHCAN_SAFE_BEGIN'
 Py_TRASHCAN_SAFE_BEGIN(self)
 ^~
../Include/pyatomic.h:56:5: error: '__atomic_load_ptr' undeclared (first use in 
this function); did you mean '__atomic_load_n'?
 atomic_load_explicit(&(ATOMIC_VAL)->_value, ORDER)
 ^
../Include/pyatomic.h:533:5: note: in expansion of macro 
'_Py_atomic_load_explicit'
 _Py_atomic_load_explicit(ATOMIC_VAL, _Py_memory_order_relaxed)
 ^~~~
../Include/pystate.h:316:31: note: in expansion of macro 
'_Py_atomic_load_relaxed'
  ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
   ^~~

--
components: Build
messages: 307735
nosy: doko
priority: normal
severity: normal
status: open
title: building extensions as builtins is broken in 3.7
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



[issue32229] Simplify hiding developer warnings in user facing applications

2017-12-06 Thread R. David Murray

R. David Murray  added the comment:

I haven't been following that discussion, and isolated from that that 
discussion the title of this issue and this proposal make no sense to me.  
Warnings are off by default, so you don't need to hide them.  In what context 
does this get used?  If this is going to be used to implement turning warnings 
on for the main application, why isn't it named "show_warnings"?

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



[issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin

2017-12-06 Thread Ronald Oussoren

Ronald Oussoren  added the comment:

I don't know if the issue has been fixed on macOS, and I'd be surprised if Ned 
would know this without testing.

Anyways, I think it is worthwhile to perform the testing that Antoine mentioned 
on a recent version of macOS (I'd start on 10.13, than work backward when the 
issue isn't present there). 

A big question is how far back we want to support. The binary installers still 
support macOS 10.6, even though that's long out of support.

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

"-W options > PYTHONWARNINGS > BytesWarning > -X dev > default filters"

Hum, sorry, according to bpo-20361 (and bpo-32231 which has been marked as a 
duplicate of bpo-20361), -b and -bb options must have the priority over 
-W/PYTHONWARNINGS. So it gives something closer to:

-b and -bb > -W > PYTHONWARNINGS > ignore::BytesWarning > -X dev > default 
filters

where ignore::BytesWarning is only not added if -b or -bb is used.

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

If we wanted to go that way, then I'd go back to my original code order for - 
putting the '-X dev' setting first in sys.warnoptions, so both PYTHONWARNINGS 
and -W options override it.

Then https://bugs.python.org/issue32231 would determine the relative precedence 
of the BytesWarning filter. (I still think the interaction between "-Wd" and 
"-bb" is weird, but we can argue about that on the other issue).

--

___
Python tracker 

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



[issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options

2017-12-06 Thread STINNER Victor

Change by STINNER Victor :


--
nosy: +ncoghlan, vstinner

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

I prefer to not talk about sys.warnoptions since, as you wrote, the order is 
reversed.

IMHO the priority should be (high priority > low priority):

  -W options > PYTHONWARNINGS > BytesWarning > -X dev > default filters

With:

* BytesWarning: "ignore" by default, "default" for -b, "error" for -bb.
* default filters: 4 filters added in release mode

[('ignore', None, , None, 0),
 ('ignore', None, , None, 0),
 ('ignore', None, , None, 0),
 ('ignore', None, , None, 0)]

  or 1 filter for pydebug build:

[('default', None, , None, 0)]


Currently, only "-W options > PYTHONWARNINGS" goes into sys.warnoptions, 
whereas "BytesWarning > -X dev > default filters" is added by the warnings 
module ("init_filters()").

--

___
Python tracker 

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



[issue32231] -bb option should override -W options

2017-12-06 Thread Serhiy Storchaka

Serhiy Storchaka  added the comment:

This looks like a duplicate of issue20361.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> -W command line options and PYTHONWARNINGS environmental 
variable should not override -b / -bb command line options

___
Python tracker 

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



[issue32231] -bb option should override -W options

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

One potential complication here is that embedding applications would inherit 
the requirement to do both:

Py_BytesWarningFlag = 2;

and

PySys_AddWarnOption(L"error::BytesWarning");

to request errors. That's probably OK though, since we're getting into pretty 
esoteric configuration behaviour at that point.

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

Right, I hit some of those corner cases myself before I realised that 
pymain_add_warnings_options was the right place to inject "default" into 
sys.warnoptions after your refactoring improvements. It provides a nice pivot 
point where the command line machinery can decide relative priority and turn 
things into a neatly ordered list.

That gives the following priority order in my PR:

- first we add the filters from PYTHONWARNINGS
- then we optionally add an extra "default" entry based on 
core_config->dev_mode (which may be from either PYTHONDEVMODE or from "-X dev")
- then we add the filters from "-W" command line options

The "last added, first applied" behaviour of "warnings.simplefilter" then means 
that later entries in that list take precedence over earlier entries.

If we go on to also implement https://bugs.python.org/issue32231, then we'd add 
a 4th step to inject a "default::BytesWarning" or "error::BytesWarning" filter 
at the end based on cmdline->bytes_warning.

--

___
Python tracker 

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



[issue32231] -bb option should override -W options

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

I'm hesitant to put the *true* default filters in sys.warnoptions, as folks use 
"bool(sys.warnoptions)" as a check for "Were any warning options set via the 
environment or the command line?", and we don't want to invalidate that use 
case.

However, I'm definitely a fan of having the warnings module *only* look at 
sys.warnoptions, and requiring *all* command line options to route their filter 
settings through that channel.

https://bugs.python.org/issue32230 adjusts "-X dev" to work that way, and I'm 
suggesting we do the same here for "-b".

That way, we can fully define the relative ordering of PYTHONWARNINGS, "-X 
dev", "-W", and "-b" inside pymain_add_warnings_options (and only the true 
default filters will be appended by the warnings module itself).

--

___
Python tracker 

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



[issue32231] -bb option should override -W options

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

IMHO the root issue is that there are different options which set warnings 
filters:

- PYTHONWARNINGS/-W will fill sys.warnoptions
- sys.flags.bytes_warning (-b, -bb) and sys.flags.dev_mode (-X dev, 
PYTHONDEVMODE=1) which change the default filters

vstinner@apu$ ./python -W default -b -c 'import pprint, sys, warnings; 
pprint.pprint(warnings.filters); pprint.pprint(sys.warnoptions)'
[('default', None, , None, 0),
 ('default', None, , None, 0),
 ('default', None, , None, 0)]
['default']

Why default::BytesWarning isn't in sys.warnoptions?

I suggest to experiment to create all filters at once in a single list, rather 
than having sys.warnoptions on one side and init_filters() (Python/_warnings.c) 
on another side.

It was on my TODO list for the PEP 432 :-) Currently, when Python is embedded, 
it's not easy to control filters created by init_filters() which can be an 
issue. I expect a feature like Py_SetPath() to override *all* warnings filters, 
not only "add" filters on top on existing filters, for the specific case of 
embedded Python.

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

> It isn't good to have "-X dev" do magical things that can't already be 
> replicated with other options.

While it might be nice to be able to replicate -X dev "manually", I didn't try 
to implement that. The current implementation of this option is more complex 
than what I expected, especially for warnings.

> Writing that issue made me realise another quirk with `-X dev` though: as a 
> command line option, it should really take precedence over PYTHONWARNINGS, 
> while remain subordinate to other explicit -W options.

IMHO -X dev should change the default, but let the developer overrides options 
set by -X dev. For example, -X dev -bb works as expected: raise BytesWarning, 
and this is a test for that. There is also a test for -X dev -W error: -W error 
has the priority over -X dev, I did that on purpose.

When I started to implement -X dev, I didn't expect so many corner cases. The 
problem is that the code reading the "configuration" (command line arguments, 
environment variables, a few configuration files, etc.) was spreaded around 
CPython code. You know that very well, since you wrote the PEP 432 :-) Fix the 
implementation of -X dev was my first motivation to work on the implementation 
of the PEP 432: bpo-32030.

For PYTHONWARNINGS vs -X dev, I'm not sure. It's rare to use PYTHONWARNINGS. I 
put PYTHONWARNINGS and -W options at the same level. If someone uses 
PYTHONWARNINGS, warnings are likely already well understood. Overriding 
PYTHONWARNINGS with -X dev can be seen as a bug. Sometimes, you cannot set 
command line options, only environment variable. There is -X dev, but there is 
also PYTHONDEVMODE=1 ...

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

In relation to the utility of sys.warnoptions: it also lets other modules (like 
the unittest module) inspect the warnings that have been specified on the 
command line.

If it wasn't for that use case, I wouldn't be concerned about the fact that `-X 
dev` doesn't currently set it.

--

___
Python tracker 

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



[issue32231] -bb option should override -W options

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

(From the discussion at https://bugs.python.org/issue32230#msg307721)

Another benefit we'd gain from this approach is that we could easily omit the 
filter entirely in the case where neither -b nor -bb is set: in those 
situations, BytesWarning won't be emitted at all, so we don't really need to 
define a filter for it.

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

No, we don't need to worry about BytesWarning if neither -b nor -bb are set, as 
the interpreter doesn't even emit the warning in that case.

The only thing the warnings machinery gets used for is to print the messages 
and/or raise the exceptions (so it would arguably be clearer to omit the filter 
entirely in the case where the flag isn't set at all).

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

First I proposed that -X dev behaves as -Wd -b, but Antoine Pitrou and Serhiy 
Storchaka asked to remove -b:

https://mail.python.org/pipermail/python-dev/2017-November/150517.html
https://mail.python.org/pipermail/python-dev/2017-November/150519.html
https://mail.python.org/pipermail/python-dev/2017-November/150520.html

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

I filed https://bugs.python.org/issue32231 to cover having -bb always override 
other warnings settings when it comes to handling BytesWarning.

Writing that issue made me realise another quirk with `-X dev` though: as a 
command line option, it should really take precedence over PYTHONWARNINGS, 
while remain subordinate to other explicit -W options.

I've adjusted the PR to implement that change, but haven't added a test case 
that ensures the behaviour persists.

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread STINNER Victor

STINNER Victor  added the comment:

> If we want "-bb" to take precedence over the passed in "-W" settings

It's not only that. Without -b nor -bb, the default::Warning filter should 
still come after ignore::BytesWarning, since these warnings must be ignored by 
default.

--

___
Python tracker 

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



[issue32231] -bb option should override -W options

2017-12-06 Thread Nick Coghlan

New submission from Nick Coghlan :

When implementing the "-X dev" mode, Victor was asked to make it behave 
differently from "-Wd", such that "python -bb -X dev" would still raise errors 
for bytes comparisons.

I don't think making "-X dev" and "-Wd" inconsistent with each other is the 
right way to address that request. Instead, I think we should find a way to 
make "-bb" *always* take precedence over any supplied "-W" options.

One way to do that would be to adopt an approach similar to what I've proposed 
for "-X dev" in https://bugs.python.org/issue32230: instead of making the 
warnings module aware of the "-bb" setting, we'd instead adjust the 
initialisation code to inject "error::BytesWarning" into sys.warnoptions 
*after* all of the entries from environment variables and the command line.

--
messages: 307717
nosy: ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: -bb option should override -W options
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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Nick Coghlan  added the comment:

It isn't good to have "-X dev" do magical things that can't already be 
replicated with other options.

If we want "-bb" to take precedence over the passed in "-W" settings (which I 
agree would be a reasonable change), we should make that change universally, 
not restrict it to "-X dev".

--

___
Python tracker 

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



[issue32230] -X dev doesn't set sys.warnoptions

2017-12-06 Thread Nick Coghlan

Change by Nick Coghlan :


--
keywords: +patch
pull_requests: +4637
stage: test needed -> 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

2017-12-06 Thread Xavier de Gaye

Xavier de Gaye  added the comment:

Attached ip_link.strace and ip_link_list.strace, the output of strace for the 
'ip link' and 'ip link list' commands.

At the end of the process, both commands create an PF_NETLINK socket to receive 
from the kernel link information through the NETLINK_ROUTE group. The sendto() 
function fails with EACCES for 'ip link list' and its SELinux avc record 
relates to this event (the netlink prefix used throughout the documentation [1] 
is 'nlmsg' and the resource denied in the avc record is 'nlmsg_write'). The 
SELinux avc record for 'ip link' relates to a failed attempt to open 
"/data/misc/net/group" (it does not exist).

[1] http://man7.org/linux/man-pages/man7/netlink.7.html

--
Added file: https://bugs.python.org/file47323/ip_link_list.strace

___
Python tracker 

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



[issue32220] multiprocessing: passing file descriptor using reduction breaks duplex pipes on darwin

2017-12-06 Thread Antoine Pitrou

Antoine Pitrou  added the comment:

Le 06/12/2017 à 05:08, Nate a écrit :
> 
> This is a hard case to test for, as timing matters. The duplex pipe doesn't 
> get confused/corrupted unless one process is sending/receiving a message over 
> the pipe at the same moment that another process is executing your 
> acknowledge logic. It's reproducible, but not 100%.

Our test runner has support for running a test in a loop until it fails.
For example `./python -m test -m "*FDPass*" -F -v test_socket`

Combined with perhaps a new test case, this could help you diagnose if
indeed the workaround is obsolete.

(perhaps our resident macOS experts can help too :-))

--

___
Python tracker 

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



  1   2   >