[issue39444] Incorrect description of sorting for PrettyPrinter

2020-01-24 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Closing is fine with me.

--

___
Python tracker 

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



[issue39374] Key in sort -> Callable Object instead of function

2020-01-24 Thread Juhana Jauhiainen


Juhana Jauhiainen  added the comment:

I created a pull request for this issue. It adds the description "(or other 
callable)" to two places in sorting documentation.

"function (or other callable) to be called on each list element prior to making
comparisons."

and later

"The value of the *key* parameter should be a function (or other callable) that 
takes a single argument and returns a key to use for sorting purposes."

--
nosy: +Juhana.Jauhiainen

___
Python tracker 

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



[issue39451] enum.Enum reference count leaks

2020-01-24 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +barry, eli.bendersky, ethan.furman

___
Python tracker 

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



[issue39444] Incorrect description of sorting for PrettyPrinter

2020-01-24 Thread Steven D'Aprano


Steven D'Aprano  added the comment:

I don't think that any change is needed here. Adding "their default" to 
insertion order doesn't really help: if the reader knows dicts are now ordered, 
adding "default" is redundant; if the reader doesn't know, they'll still be 
confused. "What default insertion order? Dicts don't know their insertion 
order!" (Well actually they do.)

In a handful of more releases, most Python programmers won't even know, or will 
have forgotten, that there was ever a time that dicts didn't preserve insertion 
order, just as most of them don't know that there was ever a time that sorting 
wasn't stable or that dicts lacked an `update` method :-)

No offense to Steven here, but the problem wasn't with the docs (they are 
correct and accurate) but with his outdated knowledge of dicts. It's a 
perfectly understandable mistake to make, but it was a mistake.

I'm closing the task, but if anyone feels strongly enough to re-open it, I 
won't object.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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



[issue39374] Key in sort -> Callable Object instead of function

2020-01-24 Thread Roundup Robot


Change by Roundup Robot :


--
keywords: +patch
pull_requests: +17560
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18177

___
Python tracker 

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



[issue39451] enum.Enum reference count leaks

2020-01-24 Thread Dan Gass


New submission from Dan Gass :

Given
(1) instantiation of an enumeration class with an invalid value
(2) a try/except around the instantiation where the exception is ignored

Then:
An unneeded reference to the bad value is lost (as well as other values that I 
suspect are local variables within a participating method)

When run, the attached sample script shows before and after reference counts 
which demonstrate the potential resource leaks. The sample script includes the 
output from running the script on Python version 3.7.5 within the module 
docstring.

The root cause appears to be in the exception handling in the Enum.__new__ 
method (in the area where it calls the _missing_ hook). The attached sample 
script includes a simplified version of those methods that should help pinpoint 
the code in question and confirm the root cause.

Not being an exception nitty-gritty expert, I have suspicions that users should 
be warned about using this pattern of exception handling. I suspect this 
pattern would be worth avoiding in the Enum implementation.

I am willing to take a stab at submitting a patch for Enum. I hesitate slightly 
not knowing if there are specific reasons for the code existing in its current 
form. Alternatively, I plan on being at PyCon2020 for the sprints and could be 
available then to work on it.

--
components: Library (Lib)
files: sample.py
messages: 360670
nosy: dan.g...@gmail.com
priority: normal
severity: normal
status: open
title: enum.Enum reference count leaks
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file48863/sample.py

___
Python tracker 

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



[issue39353] Deprecate the binhex module, binhex4 and hexbin4 standards

2020-01-24 Thread Martin Panter

Martin Panter  added the comment:

Of course I would prefer “crc_hqx” to stay, because we use it at work. But I 
understand if you think it is not popular enough to justify maintaining it.

But I was more asking if the deprecation notice should point the way forward. 
This function is no longer recommended, so what should users do instead? Or at 
least explain why it is deprecated.

In my case, I may eventually write or resurrect a simple Python CRC 
implementation that shifts one bit at a time. But other people may desire a 
faster C implementation.

--

___
Python tracker 

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



[issue39449] New Assignment operator

2020-01-24 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

This is a syntax change and it should be discussed in python-ideas mailing list 
first and would require a PEP. I would suggest closing it now and reopening it 
if the idea is accepted.

--
nosy: +xtreak

___
Python tracker 

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



[issue39388] IDLE: Changes to keybindings aren't reverted on cancel

2020-01-24 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Thank you for the reminder.  There must be other changes not being cancelled, 
but I will finish this fix instead of measuring the bug ;-).

--

___
Python tracker 

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



[issue39450] unittest TestCase shortDescription does not strip whitespace

2020-01-24 Thread Steve C


Change by Steve C :


--
keywords: +patch
pull_requests: +17559
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18175

___
Python tracker 

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



[issue39450] unittest TestCase shortDescription does not strip whitespace

2020-01-24 Thread Steve C


New submission from Steve C :

When running unit tests with the --verbose flag test descriptions are run using 
the first line of the test case's docstring. If the first character of the 
docstring is a newline, no description is printed.
Examples:
Current code expects docstrings to look like
'''It should return blah blah
This is a test...
'''
Where the description starts on the first line.

Some Python developers start the string on the next line. Example:
'''
It should return blah blah
This is a test...
'''

Lib.unittest.case.TestCase:shortDescription should first strip the docstrip of 
beginning and trailing whitespace.

--
components: Library (Lib)
messages: 360666
nosy: Steve C2
priority: normal
severity: normal
status: open
title: unittest TestCase shortDescription does not strip whitespace
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



[issue10740] sqlite3 module breaks transactions and potentially corrupts data

2020-01-24 Thread Géry

Géry  added the comment:

With Berker Peksag's patch merged in 2016, in the default non auto-commit mode, 
sqlite3 implicitly issues a BEGIN statement before any non SELECT statement not 
already in a transaction, EXCEPT DDL statements, for backwards compatibility 
reasons:

+/* For backwards compatibility reasons, do not start a transaction if a
+   DDL statement is encountered.  If anybody wants transactional DDL,
+   they can issue a BEGIN statement manually. */
+if (self->connection->begin_statement && 
!sqlite3_stmt_readonly(self->statement->st) && !self->statement->is_ddl) {
+if (sqlite3_get_autocommit(self->connection->db)) {
+result = _pysqlite_connection_begin(self->connection);
+if (!result) {
+goto error;
+}
+Py_DECREF(result);
 }
 }

Is there any plan to cover DDL statements as well in a future Python version 
and deprecate the old behaviour? That would avoid having to insert BEGIN 
statements manually for getting transactional DDL statements, like in psycopg2 
for PostgreSQL databases.

--
nosy: +maggyero

___
Python tracker 

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



[issue12915] Add inspect.locate and inspect.resolve

2020-01-24 Thread Éric Araujo

Éric Araujo  added the comment:

With the lack of support, I suggest closing this.

--

___
Python tracker 

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



[issue39448] Add regen-frozen makefile target

2020-01-24 Thread Neil Schemenauer


Change by Neil Schemenauer :


--
keywords: +patch
pull_requests: +17558
pull_request: https://github.com/python/cpython/pull/18174

___
Python tracker 

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



[issue39444] Incorrect description of sorting for PrettyPrinter

2020-01-24 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

How about 'in their default insertion order'?

--
nosy: +terry.reedy

___
Python tracker 

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



[issue11553] Docs for: import, packages, site.py, .pth files

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue39441] mimetypes.guess_extension unable to get non-lowercase mimetype

2020-01-24 Thread Terry J. Reedy


Change by Terry J. Reedy :


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



[issue12915] Add inspect.locate and inspect.resolve

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue11978] Report correct coverage.py data for tests that invoke subprocesses

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue13306] Add diagnostic tools to importlib?

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue13306] Add diagnostic tools to importlib?

2020-01-24 Thread Brett Cannon


Brett Cannon  added the comment:

I'm going to close this as I think this belongs more on PyPI than in the stdlib 
(feel free to re-open if you disagree, Nick).

--
nosy: +brett.cannon
resolution:  -> rejected
stage: needs patch -> 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



[issue13886] readline-related test_builtin failure

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue13328] pdb shows code from wrong module

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue8987] Distutils doesn't quote Windows command lines properly

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue8912] `make patchcheck` should check the whitespace of .c/.h files

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue8901] Windows registry path not ignored with -E option

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue8627] Unchecked PyErr_WarnPy3k return value in Objects/typeobject.c

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue8400] zipimporter find_module fullname mis-documented

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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



[issue10572] Move test sub-packages to Lib/test

2020-01-24 Thread Brett Cannon


Change by Brett Cannon :


--
versions: +Python 3.9 -Python 3.6

___
Python tracker 

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



[issue10572] Move test sub-packages to Lib/test

2020-01-24 Thread Brett Cannon


Brett Cannon  added the comment:

In case anyone cares, this is still a thing.

--

___
Python tracker 

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



[issue39392] Python Turtle is not filling alternate overlapping areas of a shape with same color

2020-01-24 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

Your SO question is essentially a duplicate.  As I answered there, the graphics 
systems of Unix and Windows, used by tk and hence tkinter, handle filling of 
self-intersecting polygons differently.  On Windows, if one draws a line from 
the outside to a particular region without going through an intersection, each 
line crossing toggles 'fill', starting with 'off' in the outside.

The rule seems to be reversed for overlapping items, such as circles.  On 
Windows, all three circles are yellow, whereas on macOS, the 60 circle is 
white, even if drawn last!

So, no bug.  The best we can do is document 'filling' for turtle.  Our tkinter 
doc does not include tk widgets, in particular Canvas, and we cannot edit 
external sources.

What happens with multiple fill colors?  Blended, or last wins?

# 1 fill block
from turtle import *
color('black', 'yellow')
begin_fill()
circle(40)
color('black', 'red')
circle(60)
color('black', 'blue')
circle(80)
end_fill()

On Windows, 3 circles drawn, then all filled with blue.  The same is true if 
the circle order is reversed.

# multiple fill blocks
from turtle import *
color('black', 'yellow')
begin_fill()
circle(40)
end_fill()
color('black', 'red')
begin_fill()
circle(60)
end_fill()
color('black', 'blue')
begin_fill()
circle(80)
end_fill()

On Windows, each circle fills with its color after it is drawn.  Same final 
result.  It is different if drawing order is reversed.  The rule seems to be: 
lines are drawn with the current line color; fill is done at the end of each 
fill block with the current (last) fill color.

--
assignee:  -> docs@python
components: +Documentation -Tkinter
nosy: +docs@python, terry.reedy
stage:  -> needs patch
type: behavior -> 
versions: +Python 3.8, Python 3.9

___
Python tracker 

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



[issue39449] New Assignment operator

2020-01-24 Thread Arthur Fibich


New submission from Arthur Fibich :

It's just a personal thing, but I kind of miss the following possibility in 
Python (and likewise every other language I know):
Like 
a += 1 
is the same as
a = a + 1

I'd love to see
a .= b()
as an opportunity to express
a = a.b()

Possible usages are for example linked lists or other structures, where a 
class's attributes or methods are/return an object of the same type.

--
components: Interpreter Core
messages: 360659
nosy: Arthur Fibich
priority: normal
severity: normal
status: open
title: New Assignment operator
type: enhancement
versions: Python 3.9

___
Python tracker 

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



[issue39447] imaplib documentation claims that commands return a string, but they return bytes

2020-01-24 Thread Daniel Kahn Gillmor


Daniel Kahn Gillmor  added the comment:

I should note that the "header of the response" appears to also be a bytes 
object, not a string object.

--

___
Python tracker 

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



[issue39374] Key in sort -> Callable Object instead of function

2020-01-24 Thread Terry J. Reedy


Terry J. Reedy  added the comment:

I agree that we should keep 'function', as it is often used at least somewhat 
generically (as in Library Manual 'Built-in Functions' chapter). I marked this 
as an easy first PR.

--
keywords: +easy, newcomer friendly
nosy: +terry.reedy

___
Python tracker 

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



[issue38076] Make struct module PEP-384 compatible

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

> there's still probably some underlying issue in multiprocessing.

Whoa, I've never heard that before!  

--

___
Python tracker 

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



[issue39448] Add regen-frozen makefile target

2020-01-24 Thread Neil Schemenauer


New submission from Neil Schemenauer :

Updating the frozen module "__hello__" code inside Python/frozen.c is currently 
a manual process.  That's a bit tedious since it adds some extra work in the 
case that bytecode changes are made.  I've created a small script and a 
makefile target to automates the process.

--
messages: 360655
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: Add regen-frozen makefile target
type: enhancement

___
Python tracker 

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



[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

FTR, #39376 is related (avoid the process-global env vars in the first place).

--
nosy: +eric.snow

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

I suppose it fixed the bug. But I cannot confirm because I cannot reproduce the 
original bug.

--

___
Python tracker 

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



[issue39447] imaplib documentation claims that commands return a string, but they return bytes

2020-01-24 Thread Daniel Kahn Gillmor

New submission from Daniel Kahn Gillmor :

The imaplib documentation says:


> Each command returns a tuple: (type, [data, ...]) where type is usually 
> 'OK' or 'NO', and data is either the text from the command response, or 
> mandated results from the command. Each data is either a string, or a
> tuple. If a tuple, then the first part is the header of the response, 
> and the second part contains the data (ie: ‘literal’ value).

However, "Each data is either a string, or a tuple" does not appear to be 
correct.   If the element of data is not a tuple, it appears to be a bytes 
object, not a string (because it is dealing with network streams of bytes 
internally)

This is probably old documentation left over from python 2, when strings and 
bytes were the same.

--
components: email
messages: 360652
nosy: barry, dkg, r.david.murray
priority: normal
severity: normal
status: open
title: imaplib documentation claims that commands return a string, but they 
return bytes
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



[issue22724] byte-compile fails for cross-builds

2020-01-24 Thread Xavier de Gaye


Xavier de Gaye  added the comment:

PYTHON_FOR_BUILD does not use PYTHONPATH in the implementation of (closed) PR 
17420 and should fix the current issue as a side effect.

FWIW, PR 17420 fixes cross-compilation of third-party extension modules by 
replacing the complex PYTHON_FOR_BUILD command line set in configure.ac by the 
more simple command:

"PYTHON_FOR_BUILD='PYTHON_PROJECT_BASE=$(abs_builddir) '$interp"

In this PR finding the path name of the target sysconfigdata module when needed 
is done by the sysconfig module and by distutils using the 
Misc/python-config.sh.in script instead of using PYTHONPATH.

Since PYTHONPATH is not used in PR 17420, the current issue should also be 
fixed by the PR. See also Benedikt OP that provided a hint for the fix.

--
nosy: +xdegaye

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread miss-islington


miss-islington  added the comment:


New changeset 1a274359283d3d1f4f60dd527843f72e0368caf3 by Miss Islington (bot) 
in branch '3.7':
bpo-39430: Fix race condition in lazy imports in tarfile. (GH-18161)
https://github.com/python/cpython/commit/1a274359283d3d1f4f60dd527843f72e0368caf3


--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread miss-islington


miss-islington  added the comment:


New changeset ea4a61fec842c94107eef46e5030b89a086f94bb by Miss Islington (bot) 
in branch '3.8':
bpo-39430: Fix race condition in lazy imports in tarfile. (GH-18161)
https://github.com/python/cpython/commit/ea4a61fec842c94107eef46e5030b89a086f94bb


--
nosy: +miss-islington

___
Python tracker 

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



[issue38076] Make struct module PEP-384 compatible

2020-01-24 Thread Dino Viehland


Dino Viehland  added the comment:

One more data point: Backporting this change to Python 3.6 (I just happened to 
have it applied there already, so I haven't tried it on 3.7 or 3.8) has no 
crash and no hangs in multiprocessing on Linux.  So something definitely 
changed in multiproessing which is causing the hang on shutdown, and forces us 
into this code path where we crash as well.

--

___
Python tracker 

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



[issue38972] [venv] Link to instructions to change PowerShell execution policy for venv activation

2020-01-24 Thread Brett Cannon


Brett Cannon  added the comment:

https:/go.microsoft.com/fwlink/?LinkID=135170 is the link to the MS docs.

The command is:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

--

___
Python tracker 

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



[issue39446] Documentation should reflect that all dicts are now ordered

2020-01-24 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

See also https://bugs.python.org/issue33609 .

--
nosy: +xtreak

___
Python tracker 

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



[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

@Raymond, What do you think about adding a helpful note or two in the docs?

--
nosy: +rhettinger

___
Python tracker 

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



[issue39446] Documentation should reflect that all dicts are now ordered

2020-01-24 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +inada.naoki, rhettinger

___
Python tracker 

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



[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

2020-01-24 Thread Eric Snow


Eric Snow  added the comment:

First of all, thanks for asking about this.  Everything is working as expected. 
 Let's look at why.

First, be sure the behavior of descriptors is clear: the descriptor protocol is 
only triggered by "dotted access" on an object ("obj.attr").  So you should 
expect it only where you see that syntax used.

Let's look at your examples now.

> FirstClass().descriptor = None

In this case there are 2 dotted accesses.  The first one happens in __init__() 
when the object is created.  The second is the rest of the above line.

> class SecondClass(metaclass=SecondClassMeta):
>descriptor = None
>
> SecondClass.descriptor = None

In this case there is only one dotted access, in that last line.  The object in 
this case is SecondClass and its class is SecondClassMeta.  Unlike with 
FirstClass, the *class* in the second example (SecondClassMeta) does not have a 
__init__() with the dotted access.  Instead there is only the one dotted access 
afterward.  If SecondClassMeta had the same __init__() that FirstClass had then 
you would have seen a second trigger of the descriptor.

It seems you expected assignments (name binding) in the class definition body 
to be treated the same as dotted access.  They are not.  This is because when a 
class definition body is evaluated, the class object does not exist yet.  The 
steps for class creation go like this:

1. figure out the metaclass (by default "type")
2. calls its __prepare__() method to get a namespace
3. execute the class body (like a function) with that namespace as the locals
4. create the class object, passing in that namespace

Python has worked this way since version 2.2 (PEP 252).  See: 
https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

If you want to get clever you could return a namespace object from your 
metaclass __prepare__ that triggers the descriptor protocol as you expected.  
However, I would not recommend that.  Getting clever with metaclasses is best 
avoided.  The default behavior is much simpler.  That won't be changing.

> It looks to me like an undesirable asymmetry between the descriptors 
> behaviour when in classes vs when in metaclasses. Is that intended? If it is, 
> I think it should be highlighted in the descriptors documentation.

Regardless, metaclasses are used infrequently and combining them with 
descriptors (especially relative to class definitions) is even less common.  So 
pointing out the caveats of this case may not be worth the time of all future 
readers of those docs.

That said, clearly it would have helped you in this case. :)  So here are some 
*possible* places to clarify (very briefly):

* descriptors howto
   + about mixing descriptors with metaclasses
   + a list enumerating places where descriptors are *not* invoked
* language reference (metaclasses section)
   + a warning saying something like "Avoid metaclasses if you can help it and 
only use them if you have a clear understanding of Python's object model (and 
dotted access)"
* language reference (descriptors/dotted access section)
   + a list enumerating places where descriptors are *not* invoked

Which of those do you think would have helped you the most?

--
nosy: +eric.snow

___
Python tracker 

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



[issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs docs

2020-01-24 Thread Antoine Pitrou


Antoine Pitrou  added the comment:

As mentioned on the attached PR, the first argument is positional, so it 
doesn't matter that the name in the docs is not the same as the name in the 
code.

The name "bytes_object" makes it clear which type of object is accepted, which 
makes it a better fit IMHO than "data".  Therefore, I'm going to close this 
issue.

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



[issue39446] Documentation should reflect that all dicts are now ordered

2020-01-24 Thread Michael Shields


New submission from Michael Shields :

As of Python 3.7, dicts always preserve insertion order. This is mentioned 
briefly in the release notes, but it would also be helpful to mention it in the 
language reference, and in the discussion of collections.OrderedDict.

--
assignee: docs@python
components: Documentation
messages: 360642
nosy: Michael Shields, docs@python
priority: normal
severity: normal
status: open
title: Documentation should reflect that all dicts are now ordered
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread Eric V. Smith


Eric V. Smith  added the comment:

> Should `dataclass.Field.type` become a property that evaluates the annotation 
> at runtime much in the same way that `get_type_hints` works?

I think not. But maybe a function that evaluates all of the field types. Or 
maybe an @dataclass parameter to cause it to happen at definition time.

At this point, this seems more like fodder for python-ideas.

--

___
Python tracker 

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



[issue39414] Multiprocessing resolving object as None

2020-01-24 Thread Ned Deily


Change by Ned Deily :


--
nosy: +davin, pitrou

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread David Hagen


David Hagen  added the comment:

Should `dataclass.Field.type` become a property that evaluates the annotation 
at runtime much in the same way that `get_type_hints` works?

--
nosy: +drhagen

___
Python tracker 

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



[issue39405] Using relative path as a --prefix during configure.

2020-01-24 Thread Éric Araujo

Éric Araujo  added the comment:

Hello!  I suggest you bring your question to the forum, which is a better place 
to have discussions than the issue tracker :)

https://discuss.python.org/c/users/7

--
nosy: +eric.araujo
status: open -> pending

___
Python tracker 

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



[issue39445] h5py not playing nicely with subprocess and mpirun

2020-01-24 Thread Rafael Laboissière

New submission from Rafael Laboissière :

* Preamble:

The problem reported hereafter possibly comes from the h5py module, which is 
not part of Python per se. This problem has been already reported to the h5py 
developers: https://github.com/h5py/h5py/issues/1467

and also against the Debian package python3-h5py: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946986

I apologize if this issue report is considered abusive.  Please, feel free to 
close it, if it is the case.

* The problem:

The combination of "import h5py", "subprocess.Popen", and "mpirun" is yielding 
a weird result. Consider these two scripts:

#
### File name: bugtest-without-h5py.py
import subprocess
simulationProc = subprocess.Popen("mpirun",
  shell=True,
  stdout=subprocess.PIPE,
  stderr=subprocess.PIPE)
(stdout, stderr) = simulationProc.communicate()
returnCode = simulationProc.wait()
print("stdout = ", stdout)
print("stderr = ", stderr)
print("return code = ", returnCode)
#

#
### File name: bugtest-with-h5py.py
import subprocess
import h5py
simulationProc = subprocess.Popen("mpirun",
  shell=True,
  stdout=subprocess.PIPE,
  stderr=subprocess.PIPE)
(stdout, stderr) = simulationProc.communicate()
returnCode = simulationProc.wait()
print("stdout = ", stdout)
print("stderr = ", stderr)
print("return code = ", returnCode)
#

The only difference between them is the line containing "import h5py" in the 
second.

Here is the result when running the first script:

   $ python3 bugtest-without-h5py.py
   stdout =  b''
   stderr =  
b'--\nmpirun
 could not find anything to do.\n\nIt is possible that you forgot to specify 
how many processes to run\nvia the "-np" 
argument.\n--\n'
   return code =  1

and here is the result for the second script:

   $ python3 bugtest-with-h5py.py
   stdout =  b''
   stderr =  b''
   return code =  1

It seems that, when h5py is imported, the mpirun command is not even launched 
by subprocess.Popen, even though there is noting in this call that is related 
to h5py.

When "mpirun" is replaced by other commands (e.g. "date"), then the output is 
identical for both scripts, as it should be.

As I wrote in the preamble, this is possibly a problem with h5py.  I am 
reporting it here because the developers of the subprocess module may have an 
idea about the origin of the problem or give me a hint on how to debug the it.

The tests were done on a Debian bullseye system with the following versions:

h5py 2.10.0 (compiled with MPI support)
Python 3.7.6

--
components: Library (Lib)
messages: 360638
nosy: Rafael Laboissière
priority: normal
severity: normal
status: open
title: h5py not playing nicely with subprocess and mpirun
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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Ethan Furman


Ethan Furman  added the comment:

Brett:
--
> It's covered in the language reference where import semantics are
> explained. It isn't explicitly called out in higher-level docs that
> I'm aware of because it only really comes up in edge cases like
> importing in a thread which we actively discourage unless there's a
> compelling reason not to.

When was this change made?  Assuming it is, in fact, a change.  It seems like 
most of the stdlib could be called in a thread, so the practice of lazily 
importing a module wholesale might need to be audited and proactively fixed.  
Maybe that could be a newcomer's easy(ish) project?

--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Ethan Furman


Ethan Furman  added the comment:


New changeset 9017e0bd5e124ae6d2ed94b9e9cacb2e86270980 by Ethan Furman (Serhiy 
Storchaka) in branch 'master':
bpo-39430: Fix race condition in lazy imports in tarfile. (GH-18161)
https://github.com/python/cpython/commit/9017e0bd5e124ae6d2ed94b9e9cacb2e86270980


--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17556
pull_request: https://github.com/python/cpython/pull/18171

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17557
pull_request: https://github.com/python/cpython/pull/18172

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Ethan Furman


Ethan Furman  added the comment:

Thanks, Serhiy!  I had no idea of those changes to import.

This does raise the question, though, of whether accessing an empty module's 
attributes should either:
- wait for the module to finish initializing; or
- raise an exception immediately with better information
?

It seems like this is a trap waiting for anybody using threaded code and 
on-demand imports.

--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Brett Cannon


Brett Cannon  added the comment:

It's covered in the language reference where import semantics are explained. It 
isn't explicitly called out in higher-level docs that I'm aware of because it 
only really comes up in edge cases like importing in a thread which we actively 
discourage unless there's a compelling reason not to.

--

___
Python tracker 

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



[issue39380] ftplib uses latin-1 as default encoding

2020-01-24 Thread Dong-hee Na


Dong-hee Na  added the comment:

I agree with inada.naoki

--
nosy: +corona10

___
Python tracker 

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



[issue39444] Incorrect description of sorting for PrettyPrinter

2020-01-24 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

dicts preserve their insertion order from Python 3.6 and is reflected in the 
documentation unless I am missing something here.

--
nosy: +xtreak

___
Python tracker 

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



[issue38631] Replace Py_FatalError() with regular Python exceptions

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 656c45ec9a9dc2e94cec199ebde553a6979e0e05 by Victor Stinner in 
branch 'master':
bpo-38631: Avoid Py_FatalError() in GC collect() (GH-18164)
https://github.com/python/cpython/commit/656c45ec9a9dc2e94cec199ebde553a6979e0e05


--

___
Python tracker 

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



[issue39444] Incorrect description of sorting for PrettyPrinter

2020-01-24 Thread Steven DeRose


New submission from Steven DeRose :

The doc for pprint.PrettyPrinter at 
https://docs.python.org/3/library/pprint.html says:

If sort_dicts is true (the default), dictionaries will be formatted with 
their keys sorted, otherwise they will display in insertion order

I believe the insertion order is not even known by normal dicts (only by 
OrderedDict), so I think the last phrase must be wrong. If it's somehow 
correct, it deserves explaining

--
assignee: docs@python
components: Documentation
messages: 360630
nosy: TextGeek, docs@python
priority: normal
severity: normal
status: open
title: Incorrect description of sorting for PrettyPrinter
versions: Python 3.8

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Maciej Gol

Maciej Gol  added the comment:

This is a HUGE eye opener! Didn't know of that 'import' vs 'from x import
y' difference. Thanks a lot! Is it documented somewhere ?

pt., 24 sty 2020, 15:08 użytkownik Serhiy Storchaka 
napisał:

>
> Serhiy Storchaka  added the comment:
>
> It is intended to support circular imports. Let foo.py contains "import
> bar" and bar.py contains "import foo". When you execute "import foo", the
> import machinery first creates an empty module foo, adds it to sys.modules,
> reads foo.py and executes it in the namespace of module foo. When the
> interpreter encounters "import bar" in foo.py, the import machinery creates
> an empty module bar, adds it to sys.modules, reads bar.py and executes it
> in the namespace of module bar. When the interpreter encounters "import
> foo" in bar.py, the import machinery takes the module foo from sys.modules.
> So you break an infinite cycle and can import modules with cyclic
> dependencies.
>
> You can argue that cyclic import does not look as a good practice, but
> actually it is pretty common case when you import a submodule in a package.
> If foo/__init__.py contains "from .bar import Bar", the foo module must be
> imported before you import foo.bar, but is not completely initialized at
> that time yet.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread Eric V. Smith


Eric V. Smith  added the comment:

Well the type comes from the annotation, so this makes sense to me. If 
dataclasses were to call get_type_hints() for every field, it would defeat the 
purpose of PEP 563 (at least for dataclasses).

--

___
Python tracker 

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



[issue8901] Windows registry path not ignored with -E option

2020-01-24 Thread Zackery Spytz


Change by Zackery Spytz :


--
pull_requests: +17555
pull_request: https://github.com/python/cpython/pull/18169

___
Python tracker 

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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Manuel Barkhau


Manuel Barkhau  added the comment:

> If you pass a string, you will get a string, so existing code will continue 
> to work as before.

Somebody might have code that is running against a flat directory and have 
written their ignore function expecting to get a pathlib.Path, because that's 
the only case they encountered. This change would break their code and so would 
an upgrade to 3.9 with the patch that was just merged.

--

___
Python tracker 

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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:

I don't think we need to change anything on < 3.8, but 3.8 and 3.9 will always 
convert *src* to str via os.fspath(), which IMO is more consistent (e.g. 
os.path.* functions and others do the same).

--

___
Python tracker 

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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

> For completeness, a similar problem is present also on python < 3.8 if 
> passing a pathlib.Path type as *src*

I do not think this is a problem. If you pass a string, you will get a string, 
so existing code will continue to work as before. The only problem if you pass 
a string, but get an unexpected type.

--

___
Python tracker 

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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Manuel Barkhau


Manuel Barkhau  added the comment:

> For completeness, a similar problem is present also on python < 3.8

Fair point. I'll have a look.

--

___
Python tracker 

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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Manuel Barkhau


Change by Manuel Barkhau :


--
pull_requests: +17554
pull_request: https://github.com/python/cpython/pull/18168

___
Python tracker 

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



[issue39443] Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs

2020-01-24 Thread Hugo Ricateau


New submission from Hugo Ricateau :

Assume one has defined the following descriptor:
```
class Descriptor:
def __set__(self, instance, value):
print('SET')
```

On the one hand, for the class-instance pair, the behaviour is as follows:
```
class FirstClass:
descriptor = Descriptor()

def __init__(self):
self.descriptor = None

FirstClass().descriptor = None
```
results in "SET" being displayed twice; i.e. both assignations triggered the 
__set__ method of the descriptor.

On the other hand, for the metaclass-class pair, the behaviour is the following:
```
class SecondClassMeta(type):
descriptor = Descriptor()

class SecondClass(metaclass=SecondClassMeta):
descriptor = None

SecondClass.descriptor = None
```
results in "SET" being displayed only once: the first assignation (the one in 
the class definition) did not triggered __set__.

It looks to me like an undesirable asymmetry between the descriptors behaviour 
when in classes vs when in metaclasses. Is that intended? If it is, I think it 
should be highlighted in the descriptors documentation.

Best

--
components: Interpreter Core
messages: 360623
nosy: Hugo Ricateau
priority: normal
severity: normal
status: open
title: Inhomogeneous behaviour for descriptors in between the class-instance 
and metaclass-class pairs
type: behavior
versions: 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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:

For completeness, a similar problem is present also on python < 3.8 if passing 
a pathlib.Path type as *src*: the callback function will receive a pathlib.Path 
type once, and then string types.

--

___
Python tracker 

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



[issue39390] shutil.copytree - 3.8 changed argument types of the ignore callback

2020-01-24 Thread Giampaolo Rodola'


Giampaolo Rodola'  added the comment:


New changeset 88704334e5262c6cd395a0809d4ef810f33f3ca5 by Giampaolo Rodola 
(mbarkhau) in branch 'master':
bpo-39390 shutil: fix argument types for ignore callback (GH-18122)
https://github.com/python/cpython/commit/88704334e5262c6cd395a0809d4ef810f33f3ca5


--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

It is intended to support circular imports. Let foo.py contains "import bar" 
and bar.py contains "import foo". When you execute "import foo", the import 
machinery first creates an empty module foo, adds it to sys.modules, reads 
foo.py and executes it in the namespace of module foo. When the interpreter 
encounters "import bar" in foo.py, the import machinery creates an empty module 
bar, adds it to sys.modules, reads bar.py and executes it in the namespace of 
module bar. When the interpreter encounters "import foo" in bar.py, the import 
machinery takes the module foo from sys.modules. So you break an infinite cycle 
and can import modules with cyclic dependencies.

You can argue that cyclic import does not look as a good practice, but actually 
it is pretty common case when you import a submodule in a package. If 
foo/__init__.py contains "from .bar import Bar", the foo module must be 
imported before you import foo.bar, but is not completely initialized at that 
time yet.

--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Maciej Gol


Maciej Gol  added the comment:

By the way, thanks a lot for the fix <3

--

___
Python tracker 

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



[issue39430] tarfile.open(mode="r") race condition when importing lzma

2020-01-24 Thread Maciej Gol


Maciej Gol  added the comment:

> PR 18161 fixes race condition by using "from ... import ..."
> which waits until the module be completely initialized if the specified
> names are not set.

Correct me if I'm wrong, but I think the behavior of 'import lzma' in
this case (vulnerable to race conditions) is not as intended? Shouldn't we also 
fix
the 'import' statement itself?

In general, I understand that due to how dynamic Python is, it might not be
possible to load every single name at import time using `import` and using
`from x import y` brings more determinism (because we have a safeguard now).

But, looking at the stacktrace from ipython the problem lies in a sequence of
import statements, not dynamic python coding. Shouldn't the importing mechanism
be more deterministic in such case? For sure, it should not return an empty 
module
(this is the case when race condition occurs).

I think a race condition caused by simply using `import` statements
(not `from x import y`) is a big caveat in the statement itself and how python
imports work.

Haven't checked if the cause is isolated to how tarfile works, or works in 
general, though :-(

--

___
Python tracker 

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



[issue38473] AttributeError on asserting autospecced mock object added using attach_mock

2020-01-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17552
pull_request: https://github.com/python/cpython/pull/18166

___
Python tracker 

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



[issue38473] AttributeError on asserting autospecced mock object added using attach_mock

2020-01-24 Thread miss-islington


Change by miss-islington :


--
pull_requests: +17553
pull_request: https://github.com/python/cpython/pull/18167

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread Wojciech Łopata

Wojciech Łopata  added the comment:

> Isn't that the entire point of "from __future__ import annotations"?
I'm not complaining about Foo.__annotations__ storing strings instead of types. 
I'm complaining about dataclass.Field.type being a string instead of type. I 
don't think the former needs to imply the latter. I'm trying to access Field 
objects at runtime, when it should already be possible to resolve the types, as 
far as I understand.


> Also, please show the traceback when reporting errors so that I can see 
> what's going on.

That's the error I get trying to use dataclasses_serialization module:

$ cat test.py 
from __future__ import annotations
from dataclasses import dataclass
from dataclasses_serialization.json import JSONSerializer

@dataclass
class Foo:
x: int

JSONSerializer.deserialize(Foo, {'x': 42})
$ python3 test.py 
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py",
 line 125, in dict_to_dataclass
for fld, fld_type in zip(flds, fld_types)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py",
 line 126, in 
if fld.name in dct
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/toolz/functoolz.py",
 line 303, in __call__
return self._partial(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py",
 line 234, in deserialize
if issubclass(cls, type_):
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py",
 line 72, in issubclass
return original_issubclass(cls, classinfo)
TypeError: issubclass() arg 1 must be a class

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 9, in 
JSONSerializer.deserialize(Foo, {'x': 42})
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/toolz/functoolz.py",
 line 303, in __call__
return self._partial(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py",
 line 238, in deserialize
return self.deserialization_functions[dataclass](cls, serialized_obj)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/toolz/functoolz.py",
 line 303, in __call__
return self._partial(*args, **kwargs)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py",
 line 131, in dict_to_dataclass
cls
dataclasses_serialization.serializer_base.DeserializationError: Missing one or 
more required fields to deserialize {'x': 42} as 

--

___
Python tracker 

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



[issue38473] AttributeError on asserting autospecced mock object added using attach_mock

2020-01-24 Thread Chris Withers


Chris Withers  added the comment:


New changeset 66b00a9d3aacf6ed49412f48743e4913104a2bb3 by Chris Withers 
(Karthikeyan Singaravelan) in branch 'master':
bpo-38473: Handle autospecced functions and methods used with attach_mock 
(GH-16784)
https://github.com/python/cpython/commit/66b00a9d3aacf6ed49412f48743e4913104a2bb3


--

___
Python tracker 

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



[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:

On non-Windows platforms, Python now requires setenv() and unsetenv()
functions to build.

setenv() and unsetenv() should be available on all platforms supported by 
Python. If it's not the case, someone can maintain a downstream patch which is 
a revert of commit b8d1262e8afe7b907b4a394a191739571092acdb.

If someone asks to support a platform which doesn't provide setenv() and 
unsetenv(), we can revisit the idea of unsetting variables set by Python at 
exit, to workaround putenv() issue: something like my (abandonned) PR 18078.

--

___
Python tracker 

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



[issue39395] The os module should unset() environment variable at exit

2020-01-24 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



[issue39395] The os module should unset() environment variable at exit

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset b8d1262e8afe7b907b4a394a191739571092acdb by Victor Stinner in 
branch 'master':
bpo-39395: putenv() and unsetenv() always available (GH-18135)
https://github.com/python/cpython/commit/b8d1262e8afe7b907b4a394a191739571092acdb


--

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread Eric V. Smith


Eric V. Smith  added the comment:

Isn't that the entire point of "from __future__ import annotations"?

Also, please show the traceback when reporting errors so that I can see what's 
going on.

--

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread Karthikeyan Singaravelan


Change by Karthikeyan Singaravelan :


--
nosy: +eric.smith

___
Python tracker 

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



[issue39409] AIX: FAIL: test_specific_values (test.test_cmath.CMathTests)

2020-01-24 Thread Michael Felt


Michael Felt  added the comment:

I am looking at this, as/when I can. Was hoping for a ancient school option to 
have the compiler stop with assembly code generation ipv objdump. However, I 
have not been successful there.

Found objdump, and I'll work from that - and also do some of the tests from the 
closed issues suggested.

Also, noticed that at least one AIX bot turned green again (23-01-2020), so 
I'll have to look into what else has changed.

--

___
Python tracker 

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



[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type

2020-01-24 Thread Wojciech Łopata

Change by Wojciech Łopata :


--
title: from __future__ import annotations breaks dataclasses.Field.type -> from 
__future__ import annotations makes dataclasses.Field.type a string, not type

___
Python tracker 

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



[issue39442] from __future__ import annotations breaks dataclasses.Field.type

2020-01-24 Thread Wojciech Łopata

New submission from Wojciech Łopata :

I've checked this behaviour under Python 3.7.5 and 3.8.1.

```
from __future__ import annotations
from dataclasses import dataclass, fields

@dataclass
class Foo:
x: int

print(fields(Foo)[0].type)
```

With annotations imported, the `type` field of Field class becomes a string 
with a name of a type, and the program outputs 'int'.

Without annotations, the `type` field of Field class is a type, and the program 
outputs .

I found this out when using dataclasses_serialization module. Following code 
works fine when we remove import of annotations:

```
from __future__ import annotations
from dataclasses import dataclass
from dataclasses_serialization.json import JSONSerializer

@dataclass
class Foo:
x: int

JSONSerializer.deserialize(Foo, {'x': 42})
```

TypeError: issubclass() arg 1 must be a class

--
components: Library (Lib)
messages: 360611
nosy: lopek
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks dataclasses.Field.type
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



[issue39380] ftplib uses latin-1 as default encoding

2020-01-24 Thread Inada Naoki


Inada Naoki  added the comment:

Can we have some deprecation period?

def __init__(self, ..., encoding=None):
...
if encoding is not None:
self.encoding = encoding
else:
warnings.warn("The default encoding of the FTP class will be changed 
from 'latin1' to 'utf-8' in 3.11. Pass the encoding explicitly for now.",
DeprecationWarning)

--
nosy: +inada.naoki

___
Python tracker 

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



[issue38631] Replace Py_FatalError() with regular Python exceptions

2020-01-24 Thread STINNER Victor


Change by STINNER Victor :


--
pull_requests: +17551
pull_request: https://github.com/python/cpython/pull/18164

___
Python tracker 

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



[issue39413] Implement os.unsetenv() on Windows

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 161e7b36b1ea871a1352ccfc1d4f4c1eda76830f by Victor Stinner in 
branch 'master':
bpo-39413: Implement os.unsetenv() on Windows (GH-18163)
https://github.com/python/cpython/commit/161e7b36b1ea871a1352ccfc1d4f4c1eda76830f


--

___
Python tracker 

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



[issue39424] [easy] test_signal: test_pidfd_send_signal() uses deprecated assertRaisesRegexp() method

2020-01-24 Thread STINNER Victor


Change by STINNER Victor :


--
title: test_signal: test_pidfd_send_signal() uses deprecated 
assertRaisesRegexp() method -> [easy] test_signal: test_pidfd_send_signal() 
uses deprecated assertRaisesRegexp() method

___
Python tracker 

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



[issue38691] [easy] importlib: PYTHONCASEOK should be ignored when using python3 -E

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:

sys.flags.ignore_environment should be used.

--
keywords: +newcomer friendly
title: importlib: PYTHONCASEOK should be ignored when using python3 -E -> 
[easy] importlib: PYTHONCASEOK should be ignored when using python3 -E

___
Python tracker 

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



[issue39361] [C API] Document PyTypeObject.tp_print removal in What's New In Python 3.9

2020-01-24 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



[issue39361] [C API] Document PyTypeObject.tp_print removal in What's New In Python 3.9

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:


New changeset 2d5097663d7f80921fb07cdcd26c9d59cf71f1a2 by Victor Stinner (Ammar 
Askar) in branch 'master':
bpo-39361: Document the removal of PyTypeObject.tp_print (GH-18125)
https://github.com/python/cpython/commit/2d5097663d7f80921fb07cdcd26c9d59cf71f1a2


--

___
Python tracker 

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



[issue39035] Travis CI fail on backports: pyvenv not installed

2020-01-24 Thread STINNER Victor


STINNER Victor  added the comment:

I didn't notice the error in the last days, so I close the issue.

I would be nice to merge PR 17623, but that can be done later (by Larry 
Hastings, the 3.5 release manager).

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



  1   2   >