[issue27973] urllib.urlretrieve() fails on second ftp transfer

2020-01-02 Thread David Bolen


David Bolen  added the comment:

I'd be happy to test an updated PR 17774 on a Windows builder, but I don't 
actually see any change yet.  It still appears to hold the earlier 
NamedTemporaryFile with mode='w' change from a few days ago.

--

___
Python tracker 

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



[issue27973] urllib.urlretrieve() fails on second ftp transfer

2020-01-02 Thread Senthil Kumaran


Senthil Kumaran  added the comment:

Thanks for the suggestion, David. I have updated the PR 17774 to use 
temp_support instead of NamedTemporaryFile. Please review this.

--

___
Python tracker 

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



[issue39158] ast.literal_eval() doesn't support empty sets

2020-01-02 Thread Raymond Hettinger


Raymond Hettinger  added the comment:


New changeset 4fcf5c12a37a8d3d8d6303c44c223dbc8d568cfd by Raymond Hettinger in 
branch 'master':
bpo-39158: ast.literal_eval() doesn't support empty sets (GH-17742)
https://github.com/python/cpython/commit/4fcf5c12a37a8d3d8d6303c44c223dbc8d568cfd


--

___
Python tracker 

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



[issue39158] ast.literal_eval() doesn't support empty sets

2020-01-02 Thread Raymond Hettinger


Change by Raymond Hettinger :


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



[issue36051] Drop the GIL during large bytes.join operations?

2020-01-02 Thread Inada Naoki


Inada Naoki  added the comment:

> (slowdowns because releasing/acquiring the GIL is not free, particularly when 
> contended) 

Yes, it's relatively high.  We shouldn't release the GIL only for ~0.5ms.  
That's why 1MB~ seems nice threshold.

>  If the threshold is too low then users can always choose not to use 
> multi-threading (and in general one doesn't expect much from it in Python)

I don't like this idea.  We shouldn't force users to change their program from 
multi threaded to single threaded.  So we need to avoid large performance 
regression.


> but if the threshold is too high then users have no recourse. That being 
> said, 65536 does still seem a bit low based on the results available.

But they can get the benefit when input is too large. 65536 seems "too low" to 
me.

--

___
Python tracker 

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



[issue33944] Deprecate and remove pth files

2020-01-02 Thread Andre Roberge


Change by Andre Roberge :


--
nosy: +aroberge

___
Python tracker 

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



[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

2020-01-02 Thread And Clover


And Clover  added the comment:

HTTP generally isn't an RFC 822-family standard. Its headers look a lot like 
it, but they have their own defined syntax that differs in niggling little 
details. Using mail parsing code for HTTP isn't usually the right thing.

HTTP has always used its own syntax definitions for the headers on the main 
request/response entities, but it has traditionally partially deferred to RFC 
822-family specs for the definitions of structured entity bodies. This is moot, 
however, as the reality of what browsers support has rarely coincided with 
those specs.

Nowadays HTML5.2 explicitly defers to RFC 7578 for definition of 
multipart/form-data headers. (This RFC is a replacement for the vague and 
broken RFC 2388.) As is to be expected for an HTML5-related spec, RFC 7578 
shrugs and documents existing browser behaviour [section 4.2]:

- some browsers do UTF-8
- some browsers do data mangling (IE's %-encoding sadness)
- some browsers might do something else

but it explicitly rules out the solution proposed here:

"The encoding method described in [RFC5987], which would add a 'filename*' 
parameter to the Content-Disposition header field, MUST NOT be used."

The introductions of both RFC 5987 and RFC 6266 explicitly exclude 
multipart/form-data headers from their remit.

So in summary:

- we shouldn't do anything
- the situation with submitted filenames will continue to be broken for 
everyone indefinitely

--
nosy: +aclover

___
Python tracker 

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



[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

2020-01-02 Thread Pablo Galindo Salgado


Change by Pablo Galindo Salgado :


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

___
Python tracker 

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



[issue30427] isinstance checks in os.path.normcase redundant with os.fspath

2020-01-02 Thread Brett Cannon


Brett Cannon  added the comment:

Yep, it looks like this is fixed, Batuhan. Thanks for letting us know!

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



[issue34444] Module's __file__ should be absolute always ("." in sys.path)

2020-01-02 Thread Brett Cannon


Brett Cannon  added the comment:

RE: "This could be done when inserting something into `sys.path` maybe then 
only?" That would require a custom object instead of a standard list for 
sys.path which could detect insertion and then do the automatic absolute path 
resolution which as you pointed out will inevitably break things for someone 
somewhere.

--

___
Python tracker 

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



[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

2020-01-02 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

> I'm a little confused: there's a program in this issue to demonstrate the 
> problem.  Can I do something to make it easier for you to use?

Sorry for the confusion, I was asking because at the time of asking I didn't 
have access to a computer to check myself.

I will investigate tonight as soon as I can get to my computer.

--

___
Python tracker 

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



[issue39198] Lock may not be released in Logger.isEnabledFor

2020-01-02 Thread Derek Brown


Derek Brown  added the comment:

PR is here: https://github.com/python/cpython/pull/17689

--

___
Python tracker 

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



[issue39198] Lock may not be released in Logger.isEnabledFor

2020-01-02 Thread Derek Brown


New submission from Derek Brown :

If an exception were to be thrown in a particular block of code (say, by 
asyncio timeouts or stopit) within the `isEnabledFor` function of `logging`, 
the `logging` global lock may not be released appropriately, resulting in 
deadlock.

--
components: Library (Lib)
messages: 359219
nosy: derektbrown
priority: normal
severity: normal
status: open
title: Lock may not be released in Logger.isEnabledFor
type: crash
versions: Python 3.6, Python 3.7

___
Python tracker 

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



[issue39195] re._compile should check if the argument is a compiled pattern before checking cache and flags

2020-01-02 Thread Recursing


Recursing  added the comment:

Rereading the documentation it's actually well documented, and I fully agree.

Thanks for your time

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



[issue39198] Lock may not be released in Logger.isEnabledFor

2020-01-02 Thread Derek Brown


Change by Derek Brown :


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

___
Python tracker 

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



[issue39197] Support the title and description arguments for mutually exclusive argument groups

2020-01-02 Thread signing_agreement


New submission from signing_agreement :

add_mutually_exclusive_group has one flag, required=False. Yet, regardless of 
specifying required=True, the help message calls the group "optional 
arguments". It would be nice to be able to add title and description for 
mutually exclusive groups.

Right now, programmers can only do changes via
parser._action_groups[1].title = 'mutually exclusive required arguments'

--
components: Library (Lib)
messages: 359217
nosy: signing_agreement
priority: normal
severity: normal
status: open
title: Support the title and description arguments for mutually exclusive 
argument groups
type: enhancement
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



[issue39196] json fails to encode dictionary view types

2020-01-02 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

To handle non-standard types you can implement the default() method in the 
subclass of json.JSONEncoder 
(https://docs.python.org/3/library/json.html#json.JSONEncoder.default) or pass 
the corresponding argument to json.JSONEncoder() or json.dumps().

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue39195] re._compile should check if the argument is a compiled pattern before checking cache and flags

2020-01-02 Thread Serhiy Storchaka


Serhiy Storchaka  added the comment:

PR 17799 improves the performance of an uncommon case at the cost of reducing 
the performance of a common case. I doubt this is a good change.

If you have a compiled pattern, it is better to use its methods.

--
nosy: +serhiy.storchaka

___
Python tracker 

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



[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

2020-01-02 Thread Ned Batchelder


Ned Batchelder  added the comment:

Pablo, thanks, but that PR does not fix this problem.

I'm a little confused: there's a program in this issue to demonstrate the 
problem.  Can I do something to make it easier for you to use?

--

___
Python tracker 

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



[issue39195] re._compile should check if the argument is a compiled pattern before checking cache and flags

2020-01-02 Thread Recursing


Recursing  added the comment:

I now know that the correct and fastest way to do this is to use 
pattern.search, but I still think this change would be an improvement

--

___
Python tracker 

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



[issue39196] json fails to encode dictionary view types

2020-01-02 Thread Joe Gordon


New submission from Joe Gordon :

Python 3 fails to encode dictionary view objects. Assuming this is an expected 
behavior, what is the thinking behind it? I was unable to find any 
documentation around this.

> import json; json.dumps({}.values())
"TypeError: Object of type dict_values is not JSON serializable"

--
components: Library (Lib)
messages: 359212
nosy: jogo
priority: normal
severity: normal
status: open
title: json fails to encode dictionary view types
type: behavior
versions: Python 3.5, Python 3.6, 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



[issue39195] re._compile should check if the argument is a compiled pattern before checking cache and flags

2020-01-02 Thread Recursing


Change by Recursing :


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

___
Python tracker 

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



[issue39192] relationlist module

2020-01-02 Thread Mark Dickinson


Mark Dickinson  added the comment:

I'm going to close this here. The issue can be re-opened if there's consensus 
on python-ideas or elsewhere that it's useful.

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

___
Python tracker 

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



[issue39195] re._compile should check if the argument is a compiled pattern before checking cache and flags

2020-01-02 Thread Recursing


New submission from Recursing :

In the re module, re._compile gets called when using most re methods.
In my use case (which I think is not rare) I have a small number of compiled 
patterns that I have to match against a large number of short strings

profiling showed that half of the total runtime was still spent in re._compile, 
checking for the type of the flags and trying to get the pattern in a cache

Example code that exhibits this behavior:

import re

pattern = re.compile("spam")
string = "Monty pythons"
for _ in range(100):
re.search(pattern, string)

--
components: Library (Lib)
messages: 359210
nosy: Recursing
priority: normal
severity: normal
status: open
title: re._compile should check if the argument is a compiled pattern before 
checking cache and flags
type: performance
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



[issue39192] relationlist module

2020-01-02 Thread Mark Dickinson


Mark Dickinson  added the comment:

Thanks for the suggestion. If you want to get this added to core Python, 
there's a bit more you'll need to do here: first, you'd need to persuade the 
core developers that this functionality is needed. Some real-world motivating 
examples would help a lot with this. Second, if there's widespread acceptance 
of the idea, it would be useful to have an implementation that includes 
accompanying tests and documentation. (Especially documentation: it's not at 
all clear to me just looking at the code what exact problem it's solving.)

In this case, I'd suggest taking this to the python-ideas mailing list for 
further discussion 
(https://mail.python.org/mailman3/lists/python-ideas.python.org/).

You can also take a look at this part of the developer guide for more 
guidelines on adding new functionality to Python: 
https://devguide.python.org/stdlibchanges/

--
nosy: +mark.dickinson

___
Python tracker 

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



[issue15273] Remove unnecessarily random behavior from test_unparse.py

2020-01-02 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

> I guess this resolved with PR 17738

Yup. Closing as per PR 17738.

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



[issue38870] Expose ast.unparse in the ast module

2020-01-02 Thread Pablo Galindo Salgado

Pablo Galindo Salgado  added the comment:


New changeset 7b35bef9787cd80ed1e12124f759b4be03c849db by Pablo Galindo 
(Batuhan Taşkaya) in branch 'master':
bpo-38870: Throw ValueError on invalid yield from usage (GH-17798)
https://github.com/python/cpython/commit/7b35bef9787cd80ed1e12124f759b4be03c849db


--

___
Python tracker 

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



[issue38870] Expose ast.unparse in the ast module

2020-01-02 Thread Batuhan


Change by Batuhan :


--
pull_requests: +17233
pull_request: https://github.com/python/cpython/pull/17798

___
Python tracker 

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



[issue39186] Windows installer instructions refer to mercurial

2020-01-02 Thread Zachary Ware


Zachary Ware  added the comment:

Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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



[issue15273] Remove unnecessarily random behavior from test_unparse.py

2020-01-02 Thread Batuhan


Batuhan  added the comment:

I guess this resolved with PR 17738

--

___
Python tracker 

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



[issue38870] Expose ast.unparse in the ast module

2020-01-02 Thread Batuhan


Change by Batuhan :


--
pull_requests: +17232
pull_request: https://github.com/python/cpython/pull/17797

___
Python tracker 

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



[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

2020-01-02 Thread Guido van Rossum


Guido van Rossum  added the comment:

No doubt because your getter returns None.

--

___
Python tracker 

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



[issue39173] _AttributeHolder of argparse should support the sort function or not?

2020-01-02 Thread SilentGhost


SilentGhost  added the comment:

The answer to the SO question seems rather complete to me and the only thing to 
be done on our side would be to document Formatter class and perhaps provide 
example implementation for sorting formatter. Assuming Raymond goes ahead with 
#39058 I'm still not sure who the proposed additional argument would be 
interesting to.

--

___
Python tracker 

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



[issue35457] robotparser reads empty robots.txt file as "all denied"

2020-01-02 Thread Andre Burgaud


Andre Burgaud  added the comment:

Thanks @xtreak for providing some clarification on this behavior! I can write 
some tests to cover this behavior, assuming that we agree that an empty file 
means "unlimited access". This was worded as such in the old internet draft 
from 1996 (section 3.2.1 in https://www.robotstxt.org/norobots-rfc.txt). The 
current draft is more ambiguous with "If no group satisfies either condition, 
or no groups are present at all, no rules apply." 
https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.1

https://www.robotstxt.org/robotstxt.html clearly states that an empty file 
gives full access, but I'm getting lost in figuring out which is the official 
spec at the moment :-)

--

___
Python tracker 

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



[issue39191] Coroutine is awaited despite an exception in run_until_complete()

2020-01-02 Thread Andrew Svetlov


Change by Andrew Svetlov :


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

___
Python tracker 

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



[issue39191] Coroutine is awaited despite an exception in run_until_complete()

2020-01-02 Thread Andrew Svetlov


Andrew Svetlov  added the comment:

Agree, this is a bug.

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



[issue39194] asyncio.open_connection returns a closed client when server fails to authenticate client certificate

2020-01-02 Thread Jonathan Martin


New submission from Jonathan Martin :

I'm trying to use SSL to validate clients connecting a an asyncio socket server 
by specifying CERT_REQUIRED and giving a `cafile` containing the client 
certificate to allow. client and server code attached.

Certificates are generated with:

openssl req -x509 -newkey rsa:2048 -keyout client.key -nodes -out client.cert 
-sha256 -days 100

openssl req -x509 -newkey rsa:2048 -keyout server.key -nodes -out server.cert 
-sha256 -days 100

Observed behavior with python 3.7.5 and openSSL 1.1.1d
--

When the client tries to connect without specifying a certificate, the call to 
asyncio.open_connection succeeds, but the received socket is closed right away, 
or to be more exact an EOF is received.

Observed behavior with python 3.7.4 and openSSL 1.0.2t
--

When the client tries to connect without specifying a certificate, the call to 
asyncio.open_connection fails.

Expected behavior
-

I'm not sure which behavior is to be considered the expected one, although I 
would prefer to connection to fail directly instead of returning a dead client. 
Wouldn't it be better to have only one behavior?

Note that when disabling TLSv1.3, the connection does fail to open:
ctx.maximum_version = ssl.TLSVersion.TLSv1_2

This can be reproduces on all latest releases of 3.6, 3.7, and 3.8 (which all 
have openssl 1.1.1d in my case)

--
assignee: christian.heimes
components: SSL, asyncio
files: example_code.py
messages: 359200
nosy: Jonathan Martin, asvetlov, christian.heimes, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.open_connection returns a closed client when server fails to 
authenticate client certificate
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48824/example_code.py

___
Python tracker 

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



[issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault

2020-01-02 Thread ggbang


Change by ggbang :


Added file: https://bugs.python.org/file48823/crashc1.md

___
Python tracker 

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



[issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault

2020-01-02 Thread ggbang

New submission from ggbang :

python version:
Python 3.9.0a2 (default, Dec 25 2019, 20:42:47) 
[GCC 7.5.0] on linux

crash log:
``` bash

 code:x86:64 
   0x555afb88 <_PyEval_EvalFrameDefault+4056> movrdx, QWORD PTR 
[rsi+rdx*8+0x18]
   0x555afb8d <_PyEval_EvalFrameDefault+4061> addQWORD PTR [rdx], 0x1
   0x555afb91 <_PyEval_EvalFrameDefault+4065> test   eax, eax
 → 0x555afb93 <_PyEval_EvalFrameDefault+4067> movQWORD PTR [rcx], rdx
   0x555afb96 <_PyEval_EvalFrameDefault+4070> jne0x555af226 
<_PyEval_EvalFrameDefault+1654>
   0x555afb9c <_PyEval_EvalFrameDefault+4076> movrdx, r12
   0x555afb9f <_PyEval_EvalFrameDefault+4079> subrdx, QWORD PTR 
[rsp+0x8]
   0x555afba4 <_PyEval_EvalFrameDefault+4084> addr12, 0x2
   0x555afba8 <_PyEval_EvalFrameDefault+4088> movDWORD PTR [rbx+0x68], 
edx
─
 source:Python/ceval.c+1352 
   1347  
   1348  case TARGET(LOAD_CONST): {
   1349  PREDICTED(LOAD_CONST);
   1350  PyObject *value = GETITEM(consts, oparg);
   1351  Py_INCREF(value);
 → 1352  PUSH(value);
   1353  FAST_DISPATCH();
   1354  }
   1355  
   1356  case TARGET(STORE_FAST): {
   1357  PREDICTED(STORE_FAST);

 threads 
[#0] Id 1, Name: "python", stopped, reason: SIGSEGV
──
 trace 
[#0] 0x555afb93 → _PyEval_EvalFrameDefault(f=, 
throwflag=)
[#1] 0x5568ad59 → _PyEval_EvalFrame(tstate=0x55b237b0, throwflag=0x0, 
f=0x77eee440)
[#2] 0x5568ad59 → _PyEval_EvalCode(tstate=0x55b237b0, 
_co=0x77ebdd40, globals=0x77f12480, locals=0x77f12480, args=0x0, 
argcount=0x0, kwnames=0x0, kwargs=0x0, kwcount=0x0, kwstep=0x2, defs=0x0, 
defcount=0x0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
[#3] 0x5568b0c6 → _PyEval_EvalCodeWithName(qualname=0x0, name=0x0, 
closure=0x0, kwdefs=0x0, defcount=0x0, defs=0x0, kwstep=0x2, kwcount=0x0, 
kwargs=0x0, kwnames=0x0, argcount=0x0, args=0x0, locals=0x77f12480, 
globals=0x77f12480, _co=0x77ebdd40)
[#4] 0x5568b0c6 → PyEval_EvalCodeEx(closure=0x0, kwdefs=0x0, defcount=0x0, 
defs=0x0, kwcount=0x0, kws=0x0, argcount=0x0, args=0x0, locals=0x77f12480, 
globals=0x77f12480, _co=0x77ebdd40)
[#5] 0x5568b0c6 → PyEval_EvalCode(co=0x77ebdd40, 
globals=0x77f12480, locals=0x77f12480)
[#6] 0x556d6f1e → run_eval_code_obj(locals=0x77f12480, 
globals=0x77f12480, co=0x77ebdd40)
[#7] 0x556d6f1e → run_pyc_file(filename=, 
flags=0x7fffdc68, locals=0x77f12480, globals=0x77f12480, 
fp=0x55b85360)
[#8] 0x556d6f1e → PyRun_SimpleFileExFlags(flags=, 
closeit=, filename=, fp=)
[#9] 0x556d6f1e → PyRun_SimpleFileEx(f=, p=, 
c=)
─
_PyEval_EvalFrameDefault (f=, throwflag=) at 
Python/ceval.c:1352
1352PUSH(value);
gef➤  exploitable
Description: Access violation on destination operand
Short description: DestAv (8/22)
Hash: f01ce56ffe2792b45d9959e69a1ae15d.6dcf66201de3c2adc2e25e04dbdb55e8
Exploitability Classification: EXPLOITABLE
Explanation: The target crashed on an access violation at an address matching 
the destination operand of the instruction. This likely indicates a write 
access violation, which means the attacker may control the write address and/or 
value.
Other tags: AccessViolation (21/22)
```

--
components: Interpreter Core
files: c1
messages: 359199
nosy: ggbang
priority: normal
severity: normal
status: open
title: Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
type: security
versions: Python 3.9
Added file: https://bugs.python.org/file48822/c1

___
Python tracker 

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



[issue39192] relationlist module

2020-01-02 Thread wyz23x2


wyz23x2  added the comment:

I've written a handy tool--RelationList. This type can easily create relations 
between elements in lists.

--
Added file: https://bugs.python.org/file48821/relationlist.py

___
Python tracker 

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



[issue39192] relationlist module

2020-01-02 Thread wyz23x2


Change by wyz23x2 :


--
components:  -Demos and Tools
versions: +Python 3.9 -Python 3.8

___
Python tracker 

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



[issue39192] relationlist module

2020-01-02 Thread wyz23x2


New submission from wyz23x2 :

I've written a handy tool--RelationList. This type can easily create relations 
between elements in lists.

--
components: Demos and Tools
files: relationlist.py
messages: 359197
nosy: asvetlov, dkaveshnikov, wyz23x2, yselivanov
priority: normal
severity: normal
status: open
title: relationlist module
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file48820/relationlist.py

___
Python tracker 

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



[issue39191] Coroutine is awaited despite an exception in run_until_complete()

2020-01-02 Thread Kaveshnikov Denis


New submission from Kaveshnikov Denis :

Hi, I found that if to call run_until_complete() in the task while the event 
loop will be running, a coroutine sent to run_until_complete() will be 
performed despite the exception raised from run_until_complete().
It seems to me, it would be better to cancel such a coroutine or just do 
nothing with it.

--
components: asyncio
files: test_event_loop.py
messages: 359196
nosy: asvetlov, dkaveshnikov, yselivanov
priority: normal
severity: normal
status: open
title: Coroutine is awaited despite an exception in run_until_complete()
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48819/test_event_loop.py

___
Python tracker 

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



[issue39152] Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure

2020-01-02 Thread Giovanni Lombardo


Giovanni Lombardo  added the comment:

I've modified the `Scale.configure` implementation as follows:

```
   def configure(self, cnf=None, **kw):
"""Modify or query scale options.

Setting a value for any of the "from", "from_" or "to" options
generates a <> event."""
if cnf:
kw.update(cnf)
retval = Widget.configure(self, **kw)
if any(['from' in kw, 'from_' in kw, 'to' in kw]):
self.event_generate('<>')
return retval
```

It works as expected for my project, but I don't have regression tests or 
exahustive code checking in place to verify it behaves correctly for all use 
cases. How can we manage to perform those tests?

--

___
Python tracker 

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



[issue39190] _result_handler dies on raised exceptions [multiprocessing]

2020-01-02 Thread Sindri Guðmundsson

Change by Sindri Guðmundsson :


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

___
Python tracker 

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



[issue39190] _result_handler dies on raised exceptions [multiprocessing]

2020-01-02 Thread Sindri Guðmundsson

New submission from Sindri Guðmundsson :

Raising an Exception in a callback handler of apply_async and/or map_async will 
kill the _result_handler thread. This causes unexpected behavior as all 
subsequent callbacks won't be called and worse, pool.join will deadlock.

The documentation states that callbacks should return immediately but it does 
not warn the user against raising an exception.

Attached are steps to reproduce.

--
components: Library (Lib)
files: test_pool_error.py
messages: 359194
nosy: Sindri Guðmundsson
priority: normal
severity: normal
status: open
title: _result_handler dies on raised exceptions [multiprocessing]
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48818/test_pool_error.py

___
Python tracker 

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



[issue36051] Drop the GIL during large bytes.join operations?

2020-01-02 Thread Bruce Merry


Bruce Merry  added the comment:

I'm realising that the benchmark makes it difficult to see what's going on 
because it doesn't separate overhead costs (slowdowns because 
releasing/acquiring the GIL is not free, particularly when contended) from 
cache effects (slowdowns due to parallel threads creating more cache pressure 
than threads that take turns). inada.naoki's version of the benchmark is better 
here because it uses the same input data for all the threads, but the output 
data will still be different in each thread.

For example, on my system I see a big drop in speedup (although I still get 
speedup) with the new benchmark once the buffer size gets to 2MB per thread, 
which is not surprising with an 8MB L3 cache.

My feeling is that we should try to ignore cache effects when picking a 
threshold, because we can't predict them generically (they'll vary by workload, 
thread count, CPU etc) whereas users can benchmark specific use cases to decide 
whether multithreading gives them a benefit. If the threshold is too low then 
users can always choose not to use multi-threading (and in general one doesn't 
expect much from it in Python) but if the threshold is too high then users have 
no recourse. That being said, 65536 does still seem a bit low based on the 
results available.

I'll try to write a variant of the benchmark in which other threads just spin 
in Python without creating memory pressure to see if that gives a different 
picture. I'll also run the benchmark on a server CPU when I'm back at work.

--

___
Python tracker 

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



[issue39125] Type signature of @property not shown in help()

2020-01-02 Thread Nguyễn Gia Phong

Change by Nguyễn Gia Phong :


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



[issue39114] Python 3.9.0a2 changed how finally/return is traced

2020-01-02 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:


New changeset 04ec7a1f7a5b92187a73cd02670958444c6f2220 by Pablo Galindo in 
branch 'master':
bpo-39114: Fix tracing of except handlers with name binding (GH-17769)
https://github.com/python/cpython/commit/04ec7a1f7a5b92187a73cd02670958444c6f2220


--

___
Python tracker 

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



[issue39166] Python 3.9.0a2 changed how "async for" traces its final iteration

2020-01-02 Thread Pablo Galindo Salgado


Pablo Galindo Salgado  added the comment:

Can you check if this is fixed with the changes in:

https://github.com/python/cpython/pull/17769

--
nosy: +pablogsal

___
Python tracker 

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



[issue16399] argparse: append action with default list adds to list instead of overriding

2020-01-02 Thread hai shi


hai shi  added the comment:

I update the doc of argparse and think this bpo could be closed when PR merged.

--
nosy: +rhettinger

___
Python tracker 

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



[issue39173] _AttributeHolder of argparse should support the sort function or not?

2020-01-02 Thread hai shi


hai shi  added the comment:

1)>You'd need to elaborate on that. I've been using argparse for years and 
never once had presentational aspects affected by work. So, again, what is the 
actual use case for this?
  _AttributeHolder_ has sorted the args in `_get_kwargs()` and the offspring 
class override this function. So you have accepted this default behavior(do not 
use sorted attributes).
2)some guys have discussed this question in stackoverflow, such as: 
https://stackoverflow.com/questions/12268602/sort-argparse-help-alphabetically
3)This bpo stay in discussion stage and receive everyone's opinion ;)

--

___
Python tracker 

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



[issue16399] argparse: append action with default list adds to list instead of overriding

2020-01-02 Thread hai shi


Change by hai shi :


--
nosy: +shihai1991

___
Python tracker 

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



[issue39189] Use io.DEFAULT_BUFFER_SIZE for filecmp BUFSIZE variable

2020-01-02 Thread Bahram Aghaei


New submission from Bahram Aghaei :

Hello there,

I was reading the `filecmp` module and I noticed that it defined the BUFSIZE 
manually, I think it's better to stick to the io.DEFAULT_BUFFER_SIZE variable 
for both consistency and easy to maintain in the future.


Cheers,

--
components: Library (Lib)
messages: 359188
nosy: Bahram Aghaei
priority: normal
pull_requests: 17229
severity: normal
status: open
title: Use io.DEFAULT_BUFFER_SIZE for filecmp BUFSIZE variable
type: enhancement
versions: Python 2.7, 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



[issue39188] recent change when passing a Union to a function

2020-01-02 Thread Kevin Schlossser


New submission from Kevin Schlossser :

OK so There was a change made to fix issue 26628. Something was forgotten 
about.. On Windows there is the VARIANT Union which gets used all over the 
Windows API. This change is going to really break a lot of peoples code and 
there are no code examples of what needs to be done to fix the now broken 
ctypes, what needs to be done instead of passing a Union? what new structure 
has been made that Windows is going to se as a Union? 
That is a huge change to make with no kind of notice that it was going to be 
done. Now I know it is publicly visible on your issue tracker, but come on now 
the issue was made 4 years ago and then all of a sudden out of no where boom 
broken software.. Now If that issue was a major issue and it was causing all 
kinds of grief I would think that it 
A. would have been fixed sooner... and 
B. there would have been more then a handful of people where the original "bug" 
caused a problem. 

I am wondering if maybe this bug is a NIX issue. there are simply way to many 
programs out that are running on Windows and Unions are being passed all the 
time in functions and no problems are occurring. If there were problems with it 
in Windows you would have 1000's of reports of crashing from this problem. 

A change like that should be posted on the Python website before it gets made 
so that all possible repercussions can be looked at.

--
components: ctypes
messages: 359187
nosy: Kevin Schlossser
priority: normal
severity: normal
status: open
title: recent change when passing a Union to a function
type: behavior
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



[issue39134] can't construct dataclass as ABC (or runtime check as data protocol)

2020-01-02 Thread Alexander Hirner


Alexander Hirner  added the comment:

This results in E(x=None).

I'd need to look into that to understand why.

--
Added file: https://bugs.python.org/file48817/dc2_repro.py

___
Python tracker 

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



[issue39168] Generic type subscription is a huge toll on Python performance

2020-01-02 Thread Naveen Durai


Change by Naveen Durai :


--
nosy: +Naveen Durai

___
Python tracker 

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



[issue35457] robotparser reads empty robots.txt file as "all denied"

2020-01-02 Thread Karthikeyan Singaravelan


Karthikeyan Singaravelan  added the comment:

There is a behavior change. parse() sets the modified time and unless the 
modified time is set the can_fetch method returns false. In Python 2 the parse 
method was called only when the file is non-empty [0] but in Python 3 it's 
always called though the file is empty [1] . The change was done with 
1afc1696167547a5fa101c53e5a3ab4717f8852c to always read parse and then in 
122541beceeccce4ef8a9bf739c727ccdcbf2f28 modified function was always called 
during parse thus setting the modified_time to return True from can_fetch in 
the end.

I think the behavior of robotparser for empty file was undefined allowing these 
changes and it will be good to have a test for this behavior.

[0] 
https://github.com/python/cpython/blob/f82e59ac4020a64c262a925230a8eb190b652e87/Lib/robotparser.py#L66-L67
[1] 
https://github.com/python/cpython/blob/149175c6dfc8455023e4335575f3fe3d606729f9/Lib/urllib/robotparser.py#L69-L70

--
nosy: +berker.peksag, xtreak

___
Python tracker 

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