[issue34767] Optimize asyncio.Lock

[Zackery Spytz]

Change by Zackery Spytz :


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

___
Python tracker 

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

[issue36373] Deprecate explicit loop parameter in all public asyncio APIs

[miss-islington]

miss-islington  added the comment:


New changeset 6d64a8f49eb321116f585c4b036c81bb976d2d5c by Miss Islington (bot) 
(Emmanuel Arias) in branch 'master':
bpo-36373:  Deprecate explicit loop parameter in all public asyncio APIs 
[streams] (GH-13671)
https://github.com/python/cpython/commit/6d64a8f49eb321116f585c4b036c81bb976d2d5c


--
nosy: +miss-islington

___
Python tracker 

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

[issue36373] Deprecate explicit loop parameter in all public asyncio APIs

[miss-islington]

Change by miss-islington :


--
pull_requests: +13712
pull_request: https://github.com/python/cpython/pull/13833

___
Python tracker 

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

[issue37158] Speed-up statistics.fmean()

[Raymond Hettinger]

Change by Raymond Hettinger :


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

___
Python tracker 

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

[issue37159] Use copy_file_range() in shutil.copyfile() (server-side copy)

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
title: Have shutil.copyfile() use copy_file_range() -> Use copy_file_range() in 
shutil.copyfile() (server-side copy)

___
Python tracker 

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

[issue37159] Have shutil.copyfile() use copy_file_range()

[Giampaolo Rodola']

Change by Giampaolo Rodola' :


--
nosy: +StyXman, desbma, facundobatista, martin.panter, ncoghlan, neologix, 
pablogsal, petr.viktorin, vstinner

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

> Please open a new issue to discuss how it can used in shutil ;-)

Use copy_file_range() in shutil.copyfile():
https://bugs.python.org/issue37159

--

___
Python tracker 

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

[issue37159] Have shutil.copyfile() use copy_file_range()

[Giampaolo Rodola']

New submission from Giampaolo Rodola' :

This is a follow up of issue33639 (zero-copy via sendfile()) and issue26828 
(os.copy_file_range()). On [Linux 4.5 / glib 2.27] shutil.copyfile() will use 
os.copy_file_range() instead of os.sendfile(). According to my benchmarks 
performances are the same but when dealing with NFS copy_file_range() is 
supposed to attempt doing a server-side copy, meaning there will be no exchange 
of data between client and server, making the copy operation an order of 
magnitude faster.

Before proceeding unit-tests for big-file support should be added first 
(issue37096). We didn't hit the 3.8 deadline but I actually prefer to land this 
in 3.9 as I want to experiment with it a bit (copy_file_range() is quite new, 
issue26828 is still a WIP).

--
components: Library (Lib)
files: patch.diff
keywords: patch
messages: 344671
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: Have shutil.copyfile() use copy_file_range()
type: performance
versions: Python 3.9
Added file: https://bugs.python.org/file48392/patch.diff

___
Python tracker 

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

[issue37158] Speed-up statistics.fmean()

[Raymond Hettinger]

New submission from Raymond Hettinger :

fmean() can be sped-up by converting count() from a function to a generator and 
by using enumerate() to do the counting.

-- Baseline ---
$ ./python.exe -m timeit -r11 -s 'from statistics import fmean' -s 
'data=list(map(float, range(1000)))' 'fmean(iter(data))'
2000 loops, best of 11: 108 usec per loop

-- Patched -- 
$ ./python.exe -m timeit -r11 -s 'from statistics import fmean' -s 
'data=list(map(float, range(1000)))' 'fmean(iter(data))'
5000 loops, best of 11: 73.1 usec per loop

--
assignee: steven.daprano
components: Library (Lib)
messages: 344670
nosy: rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: Speed-up statistics.fmean()
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

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Tal Einat]

Tal Einat  added the comment:

Michael, your willingness to help, and the work on this issue and PR, are 
greatly appreciated!

Reading through the discussion here again, and the one referenced by Ned, I 
tend to agree with the point that having *yet another* spelling for OS checking 
is perhaps not a good idea.  The point that needing to see exactly which check 
is done in certain edge-cases is another good point against adding such new 
constants.  Moreover, regardless of my opinion, there isn't a consensus and at 
this point I don't think there will be.

Considering the above, perhaps it would be better to use only a single, 
"canonical" idiom throughout the tests, or at least from this point forward (to 
avoid a codebase-wide change)? Steve Dower said he would "prefer sys.platform 
to be canonical".

I do suffer from having all of os.name, sys.platform and platform.system() used 
in various places, and it not being clear when one should be used instead of 
another.

--

___
Python tracker 

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

[issue21872] LZMA library sometimes fails to decompress a file

[Ma Lin]

Ma Lin  added the comment:

fix-bug.diff fixes this bug, I will submit a PR after thoroughly understanding 
the problem.

--
keywords: +patch
Added file: https://bugs.python.org/file48391/fix-bug.diff

___
Python tracker 

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

[issue37157] shutil: add reflink=False to file copy functions to control clone/CoW copies (use copy_file_range)

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

I'm attaching an initial PoC using FICLONE on Linux and clonefile(3) on OSX. It 
is also possible to support Windows but it requires a ReFS partition to test 
against which I currently don't have.  I opted for exposing reflink() as a 
separate function, mostly because:

- conceptually standard copy and CoW copy are 2 different things
- shutil already provides a distinction between copy functions (copy(), 
copy2(), copyfile()) which can be used as callbacks for copytree() and move(). 
As such one can follow the same approach and do:

   >>> copytree(src, dst, copy_function=reflink).

This initial patch provides a callback=None parameter in case the CoW operation 
fails because not supported by the underlying filesystems but this is debatable 
because we can get different errors depending on the platform (which is not 
good). As such a more generic ReflinkNotSupportedError exception is probably a 
better choice.

--
keywords: +patch
Added file: https://bugs.python.org/file48390/cow.diff

___
Python tracker 

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

[issue37134] Use PEP570 syntax in the documentation

[Grant Jenks]

Grant Jenks  added the comment:

Pablo, I never intended disrespect toward you personally. And I am sorry my 
words came across that way. I would rather the feature be one of Python's more 
esoteric qualities.

I think Carol has described the most reasonable way forward. And in particular, 
I like this creative idea:

> A Sphinx extension may also be made to show a simple user-friendly view and 
> with a click the fully accurate view.

I agree too with Raymond in this point:

> I don't think inclusion in 3.9 should be automatic.

As anecdata: I showed the PEP and feature to an intermediate class of 15 
professional software engineers today. The first question I got was, "when 
should I use that in my Python code?" And I think the answer is rarely. We 
reviewed the motivating cases in the PEP and those made sense to them. But I 
was left feeling concern that if it were prominent and frequent in the docs 
then people will be likely to imitate, not least of which through simple 
copy/paste, what they see there without understanding the C-API and why it is 
that way.

--

___
Python tracker 

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

[issue35763] IDLE calltips: make positional note less obtrusive

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue37089] `import Lib.os` works on windows (but shouldn't)

[Eryk Sun]

Eryk Sun  added the comment:

sys.prefix is usually argv0_path, but in a virtual environment argv0_path is 
set from "home" in pyvenv.cfg in order to find the standard library, and, if 
the site module is imported, sys.prefix is set to the virtual environment 
directory. Since for Windows site.getsitepackages() also includes sys.prefix, 
and since argv0_path and sys.prefix are different in this case, sys.path ends 
up with both of them. AFAIK, it needs neither of them.

Adding argv0_path to sys.path is a vestige of the NT installation scheme in the 
1990s. The old scheme had a "Bin" directory that contained "python.exe" and I 
presume the Python DLL and standard-library extension modules. The old setup.py 
installer [1] had the following code to set the value of the "PythonPath" 
registry key:

path = []
pwd = nt.getcwd()
for i in ["Bin",
  "Lib",
  "Lib\\win",
  "Lib\\tkinter",
  "Lib\\test",
  "Lib\\dos_8x3"]:
i = pwd + "\\" + i
path.append(i)
sys.path[1:] = path
pathvalue = strop.join(path, ";")
#print "Setting PythonPath to", pathvalue
win32api.RegSetValue(corehandle, "PythonPath", win32con.REG_SZ, pathvalue)

Note the presence of the "Bin" directory in the list.

Early NT releases used PC/getpath_nt.c [2], which was inconsistent with 
Modules/getpath.c in several ways. PC/getpathp.c was added in 1997. Early on, 
code was added to PC/getpathp.c to include the application directory in 
sys.path [3] in order to "make it work on NT". This was before it supported the 
registry "PythonPath" value that would have included the "Bin" directory.

[1] 
https://github.com/python/cpython/blob/8f1b6519803ffa7aef45beb58bda654533cb1fa8/PC/setup_nt/setup.py
[2] 
https://github.com/python/cpython/blob/8f1b6519803ffa7aef45beb58bda654533cb1fa8/PC/getpath_nt.c
[3] 
https://github.com/python/cpython/commit/8f1b6519803ffa7aef45beb58bda654533cb1fa8

--
nosy: +eryksun

___
Python tracker 

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

[issue35763] IDLE calltips: make positional note less obtrusive

[miss-islington]

miss-islington  added the comment:


New changeset 3d75bd15ac82575967db367c517d7e6e703a6de3 by Miss Islington (bot) 
in branch '3.7':
bpo-35763: Make IDLE calltip note about '/' less obtrusive (GH-13791)
https://github.com/python/cpython/commit/3d75bd15ac82575967db367c517d7e6e703a6de3


--

___
Python tracker 

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

[issue35763] IDLE calltips: make positional note less obtrusive

[miss-islington]

miss-islington  added the comment:


New changeset 39346ff60ac14bb83521c7e4f87304d0ad6478c2 by Miss Islington (bot) 
in branch '3.8':
bpo-35763: Make IDLE calltip note about '/' less obtrusive (GH-13791)
https://github.com/python/cpython/commit/39346ff60ac14bb83521c7e4f87304d0ad6478c2


--
nosy: +miss-islington

___
Python tracker 

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

[issue35763] IDLE calltips: make positional note less obtrusive

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 949fe976d5c62ae63ed505ecf729f815d0baccfc by Terry Jan Reedy in 
branch 'master':
 bpo-35763: Make IDLE calltip note about '/' less obtrusive (GH-13791)
https://github.com/python/cpython/commit/949fe976d5c62ae63ed505ecf729f815d0baccfc


--

___
Python tracker 

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

[issue35763] IDLE calltips: make positional note less obtrusive

[miss-islington]

Change by miss-islington :


--
pull_requests: +13709
pull_request: https://github.com/python/cpython/pull/13830

___
Python tracker 

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

[issue35763] IDLE calltips: make positional note less obtrusive

[miss-islington]

Change by miss-islington :


--
pull_requests: +13710
pull_request: https://github.com/python/cpython/pull/13831

___
Python tracker 

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

[issue36827] Overriding __new__ method with itself changes behaviour of the class

[Vedran Čačić]

Vedran Čačić  added the comment:

The point is, constructing via __new__ and initializing via __init__ are two 
mechanisms that aren't really orthogonal, and various heuristics are trying to 
guess whether the arguments you call your class with are meant for __new__ or 
for __init__. [Usually, immutable objects are __new__able, and mutable ones are 
__init__able -- and crucially, objects are usually not both. For example, list 
is __init__able, but tuple is __new__able.] Those heuristics assume you won't 
have both __init__ and __new__ implemented on your object. It mostly works if 
you have a hierarchy of __new__able objects, or a hierarchy of __init__able 
objects, but as you noticed, it usually breaks if you have an __init__able 
class derived from a __new__able one, or vice versa. If you're really trying 
for a most general solution, please note that __init__ is redundant: everything 
__init__ does can be done with __new__ (but not vice versa). So, you should 
just have a hierarchy of __new__able classes.

--
nosy: +veky

___
Python tracker 

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

[issue36839] Support the buffer protocol in code objects

[Inada Naoki]

Inada Naoki  added the comment:

I'm sorry, I thought "fantasy" was good metaphor.
I just meant "the estimation seems too optimistic and rough. discussion should 
not based on it".

--

___
Python tracker 

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

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Ah, right. It doesn't actually validate the mode string (it just stores it for 
when open is called, assuming open will validate it). So yeah, it silently 
accepts any string, not just valid mode strings. Not a contractual guarantee or 
anything, just how FileType.__init__ is implemented.

--

___
Python tracker 

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

[issue36602] Recursive directory list with pathlib.Path.iterdir

[Laurie Opperman]

Change by Laurie Opperman :


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

[issue35763] IDLE calltips: make positional note less obtrusive

[Terry J. Reedy]

Change by Terry J. Reedy :


--
type: enhancement -> behavior
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

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Demid]

Demid  added the comment:

If you will run `python test.py hello.txt, where test.py is:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('echo', type=argparse.FileType)
args = parser.parse_args()
print(args.echo)

You will receive:
FileType('hello.txt')

I think that can be confusing for someone who will forget to invoke FileType 
constructor.

‐‐‐ Original Message ‐‐‐
On Tuesday, June 4, 2019 10:27 PM, Michele Angrisano  
wrote:

>
>
> Michele angrisanomichele.angris...@gmail.com added the comment:
>
> Reading the examples in the doc, it's clear the behavior when FileType takes 
> an argument. What's the behavior of FileType when is called without any 
> argument?
>
> -
>
> nosy: +mangrisano
>
> Python tracker rep...@bugs.python.org
> https://bugs.python.org/issue37150

--

___
Python tracker 

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

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Michele Angrisano]

Michele Angrisano  added the comment:

Yes, I meant that. Thanks! :)

--

___
Python tracker 

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

[issue37134] Use PEP570 syntax in the documentation

[STINNER Victor]

STINNER Victor  added the comment:

Tim Peters: "I haven't looked at anything in this PR, so just popping in to 
confirm that the first time I saw stuff like: len(obj, /) in the docs I had no 
idea at all what it was trying to say.  I thought it was a typo. (...)"

Carol Willing: "I confess that I had a similar reaction as Tim when I saw 
functions with a trailing `/`."

I'm quite sure that many users have same reaction the first time they meet 
"@decorator", "*args", "def func(*, arg)", etc. PEP 570 introduces a syntax 
which was still illegal in Python 3.7, so it's normal to be surprised when we 
meet a new syntax.

In a few years, people will be used to that, but will be surprised by yet 
another new syntax ;-)

The best we can do is to enhance the documentation to properly document "/", 
directly in the reference documentation. Sphinx is a great help to add links. 
And we can maybe extend Sphinx to add even more inline hints.

--

The "/" character was discussed in length in the PEP 570. Many people 
complained... but nobody succeed to came up with a better syntax. The PEP has 
been accepted and its now part of the *Python language*.

As explained in length in the PEP 570, the "/" syntax is *not* new. For 
example, it is used for years in Python docstrings. Paul Ganssle also mentioned 
that this notation is "already used in the numpy documentation IIRC".

--

I don't think that we must hide some syntax like "*args" or "def func(*, arg)" 
from the doc, just because people learning Python might be surprised at the 
first read. I don't think that the reference documentation should be used to 
learn Python. They are way better resources than that to learn Python. 
Moreover, it's not really written like a tutorial. We have some 
https://docs.python.org/dev/howto/ for that.

>From my point of view, the *reference* documentation is more used by people 
>who are already used to Python and so know the Python syntax. Trying to hide 
>the real API in the *reference* documentation sounds weird (wrong) to me. The 
>doc should document the real behavior. The PEP 570 makes is possible, whereas 
>previously, the doc was lying.

If you consider that "len(obj, /)" is a typo, maybe we must fix len to accept 
obj as a keyword parameter? But they are good reasons why it's a positional 
only parameter. I don't think that anyone wants to change that. The current 
trend is more the opposite: convert some positional-or-keyword parameters to 
positional-only parameters, especially for functions taking a single parameter.

In short, I concur with Brett who wrote:

> Anyway, from my personal view, I think we should use the syntax. It's 
> officially part of the language at this point and so avoiding it in the docs 
> seems odd, like we're saying that we're ashamed of this syntax and you should 
> pretend it doesn't exist when it does and it isn't going anywhere. Otherwise 
> aren't we're forcing users to realize that the function definition in the 
> docs deviates from what is definable in this one instance and that one has to 
> read the full text to know that something is doable syntactically but we're 
> leaving it out of the docs? It adds inconsistency in what the definition line 
> means IMO based on how we have usually chosen to try and express things in 
> that 'def' line in the docs as succinctly as possible to communicate the 
> semantics of calling that function.

--

By the way, PR 13743 doesn't modify every single function of the documentation. 
Only a few files are modified, simply because only few functions accept 
positional-only parameters. My expectation is more that nobody will notice :-)

--
keywords:  -easy
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue37134] Use PEP570 syntax in the documentation

[Julien Palard]

Julien Palard  added the comment:

FWIW here's my feedback (as a Python teacher and doc guy):

I find that newcomers are good to ignore what they don't understand, so a 
newcomer exposed to "foo(a, b, /)" will no run away nor cry, he will just 
ignore the slash and understand that "foo takes two parameters, a and b" and be 
happy with it.

Then I think that for more advanced people it's nice to have it:

- It's a way to discover it's a valid syntax
- It's a usefull information to use
- It does not take a lot of space
- It's the truth (I mean, displaying "foo(a, b)" for "foo(a, b, /)" is a kind 
of a lie, I don't like it)

So I'm +1 for using PEP570 syntax in the documentation.

--
nosy: +mdk

___
Python tracker 

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

[RELEASE] Python 3.8.0b1 is now available for testing

[Łukasz Langa]

The time has come for Python 3.8.0b1:
https://www.python.org/downloads/release/python-380b1/ 

This release is the first of four planned beta release previews. Beta release 
previews are intended to give the wider community the opportunity to test new 
features and bug fixes and to prepare their projects to support the new feature 
release. The next pre-release of Python 3.8 will be 3.8.0b2, currently 
scheduled for 2019-07-01.


Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.8 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and 
no code changes after 3.8.0rc1, the release candidate. To achieve that, it will 
be extremely important to get as much exposure for 3.8 as possible during the 
beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.


A new challenger has appeared!

With the release of Python 3.8.0b1, development started on Python 3.9. The 
“master” branch in the cpython repository now tracks development of 3.9 while 
Python 3.8 received its own branch, called simply “3.8”.


Acknowledgments

As you might expect, creating new branches triggers a lot of changes in 
configuration for all sorts of tooling that we’re using. Additionally, the 
inevitable deadline for new features caused a flurry of activity that tested 
the buildbots to the max. The revert hammer got  used more than once.

I would not be able to make this release available alone. Many thanks to the 
fearless duo of Pablo Galindo Salgado and Victor Stinner for spending tens of 
hours during the past week working on getting the buildbots green for release. 
Seriously, that took a lot of effort. We are all so lucky to have you both.

Thanks to Andrew Svetlov for his swift fixes to asyncio and to Yury Selivanov 
for code reviews, even when jetlagged. Thanks to Julien Palard for untangling 
the documentation configs. Thank you to Zachary Ware for help with buildbot and 
CI configuration. Thanks to Mariatta for helping with the bots. Thank you to 
Steve Dower for delivering the Windows installers.

Most importantly though, huge thanks to Ned Deily who not only helped me 
understand the scope of this special release but also did some of the grunt 
work involved.

Last but not least, thanks to you for making this release more meaty than I 
expected. There’s plenty of super exciting changes in there. Just take a look 
at “What’s New ”!


One more thing

Hey, fellow Core Developer, Beta 2 is in four weeks. If your important new 
feature got reverted last minute, or you decided not to merge due to inadequate 
time, I have a one time offer for you (restrictions apply). If you:

find a second core developer champion for your change; and
in tandem you finish your change complete with tests and documentation before 
Beta 2
then I will let it in. I’m asking for a champion because it’s too late now for 
changes with hasty design or code review. And as I said, restrictions apply. 
For instance, at this point changes to existing APIs are unlikely to be 
accepted. Don’t start new work with 3.8 in mind. 3.9 is going to come sooner 
than you think!



- Ł


signature.asc
Description: Message signed with OpenPGP
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> FWIW, there is precedent.  We have type annotations in the language but don't 
> use them throughout the docs.

Although there is some distance between both cases, I think this is an 
extremely good point to take into account that I have not thought about.

> P.S. I hope you don't come to personally identify with this patch. I'm a big 
> admirer of your work and am already promoting the feature to my 50,000+ 
> twitter follows.  In this tracker issue, I hope for us a have a 
> dispassionate, honest evaluation of what makes for the best documentation of 
> the language.

Not at all :). I will be happy whatever solution we end agreeing to, knowing 
that we are going through a very thorough discussion. But thank you very much 
for stopping the discussion to check. I actually apologize if any of my 
responses have been more passionate than it should have been. I (really!) 
appreciate your words here and the fact that even if you disagree with this 
change and the cost of the feature regarding the advantages, you are making a 
lot of effort to explain the feature to users. Thank you very much for caring 
about the language, users and having a healthy and productive discussion.

--
keywords: +easy
title: Use PEP570 syntax in the documentation -> [EASY] Use PEP570 syntax in 
the documentation

___
Python tracker 

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

[issue37134] Use PEP570 syntax in the documentation

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
title: [EASY] Use PEP570 syntax in the documentation -> Use PEP570 syntax in 
the documentation

___
Python tracker 

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

[issue37134] Use PEP570 syntax in the documentation

[STINNER Victor]

Change by STINNER Victor :


--
keywords:  -easy
title: [EASY] Use PEP570 syntax in the documentation -> Use PEP570 syntax in 
the documentation

___
Python tracker 

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

[issue15474] Differentiate decorator and decorator factory in docs

[Andrés Delfino]

Andrés Delfino  added the comment:

Great! I'll definitely give it a look.

I prefer not to make a PR until everything is in its place. You can check the 
status though:

https://github.com/andresdelfino/cpython/tree/decorators-howto

Fred was very helpful with his insight :)

--

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Language features don't have rights.  People do.  :-)

FWIW, there is precedent.  We have type annotations in the language but don't 
use them throughout the docs.

In the end, all that matters is usability. If a notion fails a usability test, 
then we should adapt accordingly.

When it comes to documentation, we also try to minimize how much a person needs 
to know in order a mentally parse a piece in isolation.  That is a core 
principle of documentation (the MS Excel docs are an excellent example; a 
counter-example is Wikipedia's use of the IPA pronunciation notation which is 
technically superior but is only readable/usable by very few of the readers.).  

P.S. I hope you don't come to personally identify with this patch. I'm a big 
admirer of your work and am already promoting the feature to my 50,000+ twitter 
follows.  In this tracker issue, I hope for us a have a dispassionate, honest 
evaluation of what makes for the best documentation of the language.

--

___
Python tracker 

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

[issue37157] shutil: add reflink=False to file copy functions to control clone/CoW copies (use copy_file_range)

[STINNER Victor]

STINNER Victor  added the comment:

Random notes.

Extract of Linux manual page of "cp":

   --reflink[=WHEN]
  control clone/CoW copies. See below


   When --reflink[=always] is specified, perform a lightweight copy, where
   the data blocks are copied only when modified.  If this is not possible
   the copy fails, or if --reflink=auto is specified, fall back to a stan‐
   dard copy.  Use --reflink=never to ensure a standard copy is performed.

--

"Why is cp --reflink=auto not the default behaviour?":
https://unix.stackexchange.com/questions/80351/why-is-cp-reflink-auto-not-the-default-behaviour

--

reflinks are supported by BTRFS and OCFS2.

XFS seems to have an experimental support for reflink, 2 years old article:
https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/

Linux version of ZFS doesn't support reflink yet:
https://github.com/zfsonlinux/zfs/issues/405

--

Python binding using cffi to get reflink:
https://gitlab.com/rubdos/pyreflink
"Btrfs, XFS, OCFS2 reflink support. Btrfs is tested the most.
Apple macOS APFS clonefile support. Little testing, be careful. It might eat 
data."

--

"reflink for Windows":
https://github.com/0xbadfca11/reflink
"Windows Server 2016 introduce Block Cloning feature."
=> https://docs.microsoft.com/en-us/windows-server/storage/refs/block-cloning


"ReFS v2 is only available in Windows Server 2016 and Windows 10 version 1703 
(build 15063) or later.
Windows 10 version 1607 (build 14393) and earlier Windows only can use ReFS v1."

--

Linux has 2 ioctl:

   #include 
   #include 

   int ioctl(int dest_fd, FICLONERANGE, struct file_clone_range *arg);
   int ioctl(int dest_fd, FICLONE, int src_fd);

http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html

--

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>  If that premise turns out to be false, we should think seriously about 
> whether this makes the docs less approachable for everyday users.

We have not done such a thing for any other feature of the language. I think 
that since this is now a part of the language, it has all the right to be part 
of the documentation (possibly in some phased process). The contrary will be 
extremely unfair to the feature and to the PEP process: not a single other case 
had to fight separately to be included in the language and the documentation. 

And we even have an analogous case: keyword-only argument.

--

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[STINNER Victor]

STINNER Victor  added the comment:

I created bpo-37157: "shutil: add reflink=False to file copy functions to 
control clone/CoW copies (use copy_file_range)".

--

The new os.copy_file_range() should be documented at:
https://docs.python.org/dev/whatsnew/3.8.html#os

--

___
Python tracker 

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

[issue37157] shutil: add reflink=False to file copy functions to control clone/CoW copies (use copy_file_range)

[STINNER Victor]

New submission from STINNER Victor :

bpo-26826 added a new os.copy_file_range() function:
https://docs.python.org/dev/library/os.html#os.copy_file_range

As os.sendfile(), this new Linux syscall avoids memory copies between kernel 
space and user space. It matters for performance, especially since Meltdown 
vulnerability required Windows, Linux, FreeBSD, etc. to use a different address 
space for the kernel (like Linux Kernel page-table isolation, KPTI).

shutil has been modified in Python 3.8 to use os.sendfile() on Linux:
https://docs.python.org/dev/whatsnew/3.8.html#optimizations

But according to Pablo Galindo Salgado, copy_file_range() goes further:
"But copy_file_rane can leverage more filesystem features like deduplication 
and copy offload stuff."

https://bugs.python.org/issue26826#msg344582

Giampaolo Rodola' added:

"I think data deduplication / CoW / reflink copy is better implemented via 
FICLONE. "cp --reflink" uses it, I presume because it's older than 
copy_file_range(). I have a working patch adding CoW copy support for Linux and 
OSX (but not Windows). I think that should be exposed as a separate 
shutil.reflink() though, and copyfile() should just do a standard copy."

"Actually "man copy_file_range" claims it can do server-side copy, meaning no 
network traffic between client and server if *src* and *dst* live on the same 
network fs. So I agree copy_file_range() should be preferred over sendfile() 
after all. =)
I have a wrapper for copy_file_range() similar to what I did in shutil in 
issue33671 which I can easily integrate, but I wanted to land this one first:
https://bugs.python.org/issue37096
Also, I suppose we cannot land this in time for 3.8?"

https://bugs.python.org/issue26826#msg344586

--

There was already a discussion about switching shutil to copy-on-write:
https://bugs.python.org/issue33671#msg317989

One problem is that modifying the "copied" file can suddenly become slower if 
it was copied using "cp --reflink".

It seems like adding a new reflink=False parameter to file copy functions to 
control clone/CoW copies is required to prevent bad surprises.

--
components: Library (Lib)
messages: 344648
nosy: giampaolo.rodola, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: shutil: add reflink=False to file copy functions to control clone/CoW 
copies (use copy_file_range)
type: performance
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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Pablo, Sure thing. I believe that a Sphinx extension (possibly existing 
> sphinx-tabs as suggested by @bskinn in the Steering Council issue or one we 
> develop/find) could give us both a "technically accurate" view and 
> "simplified" view. I wasn't sure if this could/would be ready by 3.8. But I 
> think that it is feasible for 3.9. If we can do it for 3.8, fantastic.

Thanks for the quick response and for clarifying that. This looks like a very 
interesting approach. Would the "simplify" view remove keyword-only argument 
markers as well? What other features should be hidden in this simplified view?

--

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I don't think inclusion in 3.9 should be automatic.  

The purpose of the deferment is to evaluate the premise, "the only reason 
people have found this notation confusing was that it wasn't yet valid syntax 
available for use in their own code."  If that premise turns out to be false, 
we should think seriously about whether this makes the docs less approachable 
for everyday users.

This extensive edit of the docs will change the appearance and texture of 
language from day 1 of a person's exposure to the language.  It warrants 
careful consideration of the costs and benefits.  Despite what we might wish to 
be true, the cost side of the equation is definitely not zero.

--

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[STINNER Victor]

STINNER Victor  added the comment:

Python has many parameter types: positional-only, positional-or-keyword, 
keyword only, etc. Even if we don't add "/", it would be nice to have hints 
when we put the mouse cursor on a function parameter.

Something like:

function: demo(arg1, *, arg2, arg3=None)

arg1 hint: *arg1* is the first mandatory parameter (kind: positional-or-keyword)
arg2 hint: *arg2* is the second mandatory parameter (kind: keyword-only)
arg3 hint: *arg3* is an optional parameter (default: ``None``, kind: 
keyword-only)

Maybe we can also add hints on '*':

* hint: Marker for keyword-only parameter

... I have no idea how complex it would be to implement such Sphinx extenstion, 
or maybe even implement it in Sphinx.

--

___
Python tracker 

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

[issue15474] Differentiate decorator and decorator factory in docs

[Ezio Melotti]

Ezio Melotti  added the comment:

If you want some early feedback I believe you can already create a PR and mark 
it as work-in-progress/don't-merge.

If you need some material you can find the slides of a talk about decorators 
that I did at
https://www.pycon.it/media/conference/slides/understanding-decorators.pdf
Feel free to take from it whatever you need :)

--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 
3.3, Python 3.4

___
Python tracker 

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[STINNER Victor]

STINNER Victor  added the comment:

Can this issue be closed now?

--
nosy: +vstinner

___
Python tracker 

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

[issue34282] Enum._convert shadows members named _convert

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 19a1e1eb86115db66c1faae5927f87e3a12692fc by Victor Stinner 
(Zachary Ware) in branch 'master':
bpo-34282: Remove deprecated enum _convert method (GH-13823)
https://github.com/python/cpython/commit/19a1e1eb86115db66c1faae5927f87e3a12692fc


--
nosy: +vstinner

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Carol Willing]

Carol Willing  added the comment:

> Could you extend your thoughts regarding this concern that I have with 
> respect of not including the trailing / in 3.8 but doing it in 3.9:

Pablo, Sure thing. I believe that a Sphinx extension (possibly existing 
sphinx-tabs as suggested by @bskinn in the Steering Council issue or one we 
develop/find) could give us both a "technically accurate" view and "simplified" 
view. I wasn't sure if this could/would be ready by 3.8. But I think that it is 
feasible for 3.9. If we can do it for 3.8, fantastic.

If we do the 3.8/3.9 phased approach, I definitely think the 3.8 docs need to 
be explicit in stating the what/why/when of the / (still searching for a cute 
name - right now the best I have is "twig" from another name, virgule, for 
slash and its Latin derivation). Ultimately, 3.9 should either by Sphinx 
extension or edit contain the "technically accurate" version.

--

___
Python tracker 

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

[issue37130] pathlib.with_name() doesn't like unnamed files.

[N.P. Khelili]

N.P. Khelili  added the comment:

in the definition of the name property 
https://github.com/python/cpython/blob/9ab2fb1c68a75115da92d51b8c40b74f60f88561/Lib/pathlib.py#L792
 :

if len(parts) == (1 if (self._drv or self._root) else 0):
return ''

could also become

if self.parent == self
return ''   # why not None btw...

As I said, I'm new to python and I'll make a few tries once I build the test 
suite

--

___
Python tracker 

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

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Josh Rosenberg]

Josh Rosenberg  added the comment:

The docs specify what argparse.FileType() does via the default parameters: 
https://docs.python.org/3/library/argparse.html#argparse.FileType

If you mean what does it do when you fail to call it at all (passing 
type=argparse.FileType), the answer is the same as any other class: It tries to 
construct a FileType using the user provided argument as the sole positional 
argument. So if the user passes a valid mode string, it works, and returns a 
FileType object with that mode string, otherwise it barfs and dumps an error 
message for passing an invalid argument for FileType.

--
nosy: +josh.r

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Brian Skinn]

Change by Brian Skinn :


--
nosy: +bskinn

___
Python tracker 

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

[issue34282] Enum._convert shadows members named _convert

[Zachary Ware]

Change by Zachary Ware :


--
pull_requests: +13708
pull_request: https://github.com/python/cpython/pull/13823

___
Python tracker 

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

[issue37156] Fix libssl DLL tag in Tools/msi project

[Steve Dower]

New submission from Steve Dower :

Mostly a note to self to fix the tag. Right now the x64 build gets an extra 
suffix, which is incorrect and causes installer builds to fail.

--
assignee: steve.dower
components: Windows
messages: 344638
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix libssl DLL tag in Tools/msi project
type: compile error
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

[issue37152] Add AF_LOCAL alias for AF_UNIX

[Christian Heimes]

Christian Heimes  added the comment:

The socket type is known as AF_UNIX, AF_LOCAL, Unix domain socket, and IPC 
(inter process communication) socket. The man page unix(7) 
http://man7.org/linux/man-pages/man7/unix.7.html uses three of those four terms 
to explain the socket type:

The AF_UNIX (also known as AF_LOCAL) socket family is used to
communicate between processes on the same machine efficiently.
Traditionally, UNIX domain sockets can be [...]

The strace command also uses the name AF_UNIX and not AF_LOCAL. HTTP over 
AF_UNIX often uses http+unix:// or unix:// to refer to a socket file.

I'm -1 to add the alias. It just adds to the confusion. It's also against the 
Zen of Python: "There should be one-- and preferably only one --obvious way to 
do it."

--
nosy: +christian.heimes
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue35047] Better error messages in unittest.mock

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 001d63cefaa9d84d6d59aa9db8bac66040c8f0ee by Victor Stinner 
(Petter Strandmark) in branch 'master':
bpo-35047: Update whatsnew/3.8 for better mock error message (GH-13746)
https://github.com/python/cpython/commit/001d63cefaa9d84d6d59aa9db8bac66040c8f0ee


--

___
Python tracker 

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

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[Michele Angrisano]

Michele Angrisano  added the comment:

Reading the examples in the doc, it's clear the behavior when FileType takes an 
argument. What's the behavior of FileType when is called without any argument?

--
nosy: +mangrisano

___
Python tracker 

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

[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping

[Geoffrey Sneddon]

Geoffrey Sneddon  added the comment:

Like, where in the documentation can I learn that MappingView's initializer 
takes an argument "mapping"?

--

___
Python tracker 

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

[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping

[Geoffrey Sneddon]

Geoffrey Sneddon  added the comment:

You've missed my point: the arguments that MappingView.__init__ takes are 
undocumented. Nowhere mentions class MappingView(mapping), as I would expect 
from how initializers are documented elsewhere.

--

___
Python tracker 

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

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Marco Sulla]

Marco Sulla  added the comment:

Furthermore, if you destroy an old virtual env and recreate it with the new 
method, it continues to work as before, since VIRTUAL_ENV points to the same 
folder. We don't force to change the code if they continues to use the virtual 
environments as now.

--

___
Python tracker 

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

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

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

[issue37089] `import Lib.os` works on windows (but shouldn't)

[Guido van Rossum]

Guido van Rossum  added the comment:

I doubt it's meant as a feature. I don't recall anything about it. I suspect 
it's got to do with limitations of the Windows installer (at the time). Maybe 
there are other things that are siblings of "Lib" that must be importable, e.g. 
DLLs?

I recommend taking this up with Steve Dower, who owns the Windows installers 
these days.

--

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[STINNER Victor]

STINNER Victor  added the comment:

Please open a new issue to discuss how it can used in shutil ;-)

--

___
Python tracker 

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

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Marco Sulla]

Marco Sulla  added the comment:

The previous post was for Laurie Opperman

"upset people with requiring everyone to update their code"

I don't know why they have to be upset. Until now they can't move the folder. 
They want to move the folder? They have to change their code. Now they have no 
possibility at all to move it, so I don't know why they should be upset. 

And yes, I consider a code that depends from the path of the folder it resides 
a bad code.

--

___
Python tracker 

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

[issue37153] test_venv: test_multiprocessing() hangs randomly on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor  added the comment:

I hope that my change will prevent the random failure.

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

[issue37153] test_venv: test_multiprocessing() hangs randomly on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 5f8443eec9d54e1f74b69aa547e6810da6afa90b by Victor Stinner (Miss 
Islington (bot)) in branch '3.7':
bpo-37153: test_venv.test_mutiprocessing() calls pool.terminate() (GH-13816) 
(GH-13819)
https://github.com/python/cpython/commit/5f8443eec9d54e1f74b69aa547e6810da6afa90b


--

___
Python tracker 

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

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Marco Sulla]

Marco Sulla  added the comment:

Well, I repeat, not with 

#!/usr/bin/env python3

--

___
Python tracker 

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

[issue37140] ctypes change made clang fail to build

[Paul Monson]

Paul Monson  added the comment:

I added a unittest to the PR that illustrates the problem.  It doesn't pass yet.

--

___
Python tracker 

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

[issue36964] `python3 -m venv NAME`: virtualenv is not portable

[Brett Cannon]

Brett Cannon  added the comment:

"if you coded bad and it doesn't work, it's your fault."

I disagree. Your request changes what VIRTUAL_ENV gets set to, correct? 
Changing it suddenly for users doesn't mean their code was bad, it means we 
changed something on them. Now we can do that with a good justification, but 
simply to make it easier to have "unofficial unsupported bonus" is not a good 
enough reason to upset people with requiring everyone to update their code.

--

___
Python tracker 

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

[issue36742] urlsplit doesn't accept a NFKD hostname with a port number

[Ned Deily]

Ned Deily  added the comment:


New changeset fd1771dbdd28709716bd531580c40ae5ed814468 by Ned Deily (Miss 
Islington (bot)) in branch '3.6':
bpo-36742: Corrects fix to handle decomposition in usernames (GH-13812) 
(GH-13814)
https://github.com/python/cpython/commit/fd1771dbdd28709716bd531580c40ae5ed814468


--

___
Python tracker 

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

[issue36839] Support the buffer protocol in code objects

[Brett Cannon]

Brett Cannon  added the comment:

Let's please keep this respectful. Saying people are basing things "on fantasy" 
or that "people need to develop reading skills" is not helpful.

--

___
Python tracker 

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

[issue37149] link to official documentation tkinter failed !!!

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +gpolo, serhiy.storchaka

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Thank you Carol for your comment! Regarding your proposal, I find it it 
attractive as a compromise in order to make more gentle the introduction of the 
feature to users. I really appreciate the effort to balance all the different 
aspects and concerns.

Ccould you extend your thoughts regarding this concern that I have with respect 
of not including the trailing / in 3.8 but doing it in 3.9:

>I think documenting the trailing "/" is especially important because now users 
>will find very confusing the fact that functions
only document the "/" in some places. They may start to believe that a trailing 
"/" is illegal syntax or that the "/" at the end
is optional. This will lead to even more confusion IMHO.

Another minor concern that I have is the fear that we will have a similar 
discussion in the future when the PR adding the trailing / to 3.9 would be 
added.

--

___
Python tracker 

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

[issue30835] AttributeError when parsing multipart email with invalid non-decodable Content-Transfer-Encoding

[miss-islington]

Change by miss-islington :


--
pull_requests: +13706
pull_request: https://github.com/python/cpython/pull/13820

___
Python tracker 

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

[issue30835] AttributeError when parsing multipart email with invalid non-decodable Content-Transfer-Encoding

[miss-islington]

Change by miss-islington :


--
pull_requests: +13707
pull_request: https://github.com/python/cpython/pull/13821

___
Python tracker 

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

[issue30835] AttributeError when parsing multipart email with invalid non-decodable Content-Transfer-Encoding

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:


New changeset aa79707262f893428665ef45b5e879129abca4aa by Barry Warsaw 
(Abhilash Raj) in branch 'master':
bpo-30835: email: Fix AttributeError when parsing invalid CTE (GH-13598)
https://github.com/python/cpython/commit/aa79707262f893428665ef45b5e879129abca4aa


--

___
Python tracker 

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

[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Hit  too early.

In Python, the norm is that the class name is documented.  When you call the 
class, the __init__() method gets called automatically (as documented in the 
language reference and in the tutorial).

For example:

>>> class A:
def __init__(self, seq):
self._seq = seq
def __len__(self):
return len(self._seq)
  
>>> a = A('apple')
>>> len(a)
5

In this example, we document that class "A" can be called with a sequence and 
that len() can be called on instances of A.  The "dunder" methods are public, 
but are called and documented indirectly.  The "_seq" attribute is marked as 
private and would not be documented, since it is an implementation detail and 
not intended to be accessed directly.

--

___
Python tracker 

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

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Carol Willing]

Carol Willing  added the comment:

I echo Pablo's comment about thoughtful discourse as this is discussed.

For library maintainers that are writing APIs that involve workflows across 
multiple projects maintained by different people, better information and 
documentation is very important.

We are balancing the needs of different user groups. An all or nothing approach 
to documenting / and positional only arguments will not serve the different 
groups well. What will serve them is coming up with an approach that will work 
(though not perfectly) for each group. In essence, balancing and compromising 
are critical.

I suggested an approach earlier which I would appreciate folks give a closer 
look to its merit.

--

___
Python tracker 

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

[issue37153] test_venv: test_multiprocessing() hangs randomly on x86 Windows7 3.x

[miss-islington]

Change by miss-islington :


--
pull_requests: +13705
pull_request: https://github.com/python/cpython/pull/13819

___
Python tracker 

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

[issue37145] collections.abc.MappingView mixins rely on undocumented _mapping

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Then I guess what I consider a bug is "__init__ is undocumented".

No, this just how Python works.

--

___
Python tracker 

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

[issue37144] tarfile.open: improper handling of path-like object

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This was documented in c45cd167d403d7d98078d5fc4a37b16195dc7a35 but it seems a 
test for opening gzip file with 'w|gz' mode as in the original report was 
missing.

--
nosy: +lars.gustaebel, serhiy.storchaka, xtreak
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

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:


New changeset 46d88a113142b26c01c95c93846a89318ba87ffc by Barry Warsaw 
(Abhilash Raj) in branch 'master':
bpo-35805: Add parser for Message-ID email header. (GH-13397)
https://github.com/python/cpython/commit/46d88a113142b26c01c95c93846a89318ba87ffc


--

___
Python tracker 

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

[issue37150] Do not allow to pass FileType class object instead of instance in add_argument

[paul j3]

paul j3  added the comment:

I don't see an easy way around this.  FileType is a class, and thus is a 
callable.  add_argument checks that the 'type' parameter is a callable (or a 
string in the registry).  Otherwise it gives the programmer a lot of freedom 
regarding this parameter.

--

___
Python tracker 

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

[issue36402] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

In the same build:
https://buildbot.python.org/all/#builders/168/builds/1154

0:28:57 load avg: 12.93 [208/423/1] test_threading crashed (Exit code 1) -- 
running: test_lib2to3 (7 min 9 sec), test_multiprocessing_spawn (1 min 36 sec)
Timeout (0:25:00)!
Thread 0x000800ac3000 (most recent call first):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/threading.py", 
line 1015 in _wait_for_tstate_lock
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/threading.py", 
line 999 in join
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_threading.py",
 line 1287 in test_interrupt_main_subthread
  (...)

--

___
Python tracker 

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

[issue37155] test_asyncio: test_stdin_broken_pipe() failed on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

New submission from STINNER Victor :

See also bpo-33531 and bpo-30382.

AMD64 FreeBSD CURRENT Shared 3.x:
https://buildbot.python.org/all/#/builders/168/builds/1154

==
FAIL: test_stdin_broken_pipe 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests)
--
Traceback (most recent call last):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_asyncio/test_subprocess.py",
 line 243, in test_stdin_broken_pipe
self.assertRaises((BrokenPipeError, ConnectionResetError),
AssertionError: (, ) not 
raised by run_until_complete

--
components: Tests
messages: 344612
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_stdin_broken_pipe() failed on AMD64 FreeBSD CURRENT 
Shared 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

[issue36402] test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD CURRENT Shared 3.x

[STINNER Victor]

STINNER Victor  added the comment:

New failure:

AMD64 FreeBSD CURRENT Shared 3.x:
https://buildbot.python.org/all/#/builders/168/builds/1154

...
test_thread_leak (test.test_threading.PyRLockTests) ... ok
test_timeout (test.test_threading.PyRLockTests) ... ok
test_try_acquire (test.test_threading.PyRLockTests) ... ok
test_try_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_weakref_deleted (test.test_threading.PyRLockTests) ... ok
test_weakref_exists (test.test_threading.PyRLockTests) ... ok
test_with (test.test_threading.PyRLockTests) ... ok
test_acquire (test.test_threading.SemaphoreTests) ... ok
test_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.SemaphoreTests) ... ok
test_acquire_timeout (test.test_threading.SemaphoreTests) ... ok
test_constructor (test.test_threading.SemaphoreTests) ... ok
test_default_value (test.test_threading.SemaphoreTests) ... ok
test_release_unacquired (test.test_threading.SemaphoreTests) ... ok
test_try_acquire (test.test_threading.SemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_with (test.test_threading.SemaphoreTests) ... ok
test_daemon_threads_fatal_error (test.test_threading.SubinterpThreadingTests) 
... ok
test_threads_join (test.test_threading.SubinterpThreadingTests) ... ok
Fatal Python error: Py_EndInterpreter: not the last thread

Current thread 0x000800ac3000 (most recent call first):
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/__init__.py",
 line 2794 in run_in_subinterp
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_threading.py",
 line 923 in test_threads_join_2
test_threads_join_2 (test.test_threading.SubinterpThreadingTests) ... *** 
Signal 6

Stop.
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd-current/build
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/case.py",
 line 628 in _callTestMethod
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/case.py",
 line 671 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/case.py",
 line 731 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/runner.py",
 line 176 in run
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/__init__.py",
 line 1984 in _run_suite
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/__init__.py",
 line 2080 in run_unittest
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/runtest.py",
 line 203 in _test_module
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/runtest.py",
 line 228 in _runtest_inner2
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/runtest.py",
 line 264 in _runtest_inner
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/runtest.py",
 line 148 in _runtest
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/runtest.py",
 line 187 in runtest
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/main.py",
 line 291 in rerun_failed_tests
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/main.py",
 line 646 in _main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/main.py",
 line 588 in main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/libregrtest/main.py",
 line 663 in main
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/__main__.py",
 line 2 in 
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/runpy.py", line 
85 in _run_code
  File 
"/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/runpy.py", line 
192 in _run_module_as_main
program finished with exit code 1
elapsedTime=3523.834729

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 

[issue37134] [EASY] Use PEP570 syntax in the documentation

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Thank you, everyone, for expressing clearly your different opinions and 
concerns. Without disregarding any of the
arguments so far I want to make some further clarifications on some points and 
why I still think this is important.

> FWIW, I would rather not see the docs littered with "/".

Although I assume there is not the intention, there is absolutely no reason to 
be disrespectful to the people that
think otherwise. You can express the same idea without implying that the 
feature is "litter". The same thing applies
to "unfortunate implementation" in another of the sentences that was used.

> This is another step toward making what I see as an unfortunate 
> implementation detail into formal semantics.

The feature has as much formal semantics as it is possible already: is an 
official part of the language.

One of the things the PEP makes a lot of emphasis is the current status of the 
feature and how users see the syntax
is precisely caused because of a lack of documentation, exposition and 
ultimately (and very important) because it was
not valid Python syntax. The fact that many people were thinking that is a typo 
in the documentation or "noise" is precisely
because of this and I think having it in the docs is crucial for discovery.

Regarding the usefulness of having the syntax for users: is exactly as useful 
as knowing that some arguments are keyword-only
and those are documented and we did not have any discussion about this. One can 
disagree and argue that the usefulness of the
feature, when some users consider implementing functions that use both 
syntaxes, is much different between positional-only and
keyword-only and that one solve more common problems that the other, but that 
is irrelevant for people reading the documentation:
the relevant thing is that they tell you the restrictions when calling an 
existing function. And at that point, it does not matter
how common something is or how common is fall into the error condition. Also, 
take into account that there is a serious difference
between teaching someone how to react to the syntax (you cannot use keyword 
parameters for these arguments), which is done almost
immediately, and teaching someone when they want to use the syntax themselves 
on their function. And I want to make clear that I
acknowledge that there is a cognitive burden because there are more cases to 
remember.

I think documenting the trailing "/" is especially important because now users 
will find very confusing the fact that functions
only document the "/" in some places. They may start to believe that a trailing 
"/" is illegal syntax or that the "/" at the end
is optional. This will lead to even more confusion IMHO. This will also 
perpetuate another thing that the PEP put a lot of focus
on solving, which is removing the dissonance between the signature that appears 
in the documentation, the one in the help() and docstrings
and the one that inspect.signature will return. Precisely failing to document 
all cases will make this even more confusing and will severely
alter and bias any feedback that users could provide about any related aspect.

It is possible that some users were thinking that the bare "*" for keyword-only 
arguments was a typo when it was introduced and maybe
they were thinking that the author meant "*args", but we can all agree that 
that was not a problem. I don't see why this syntax needs
to have special treatment regarding that. Another sentence of the ZEN of Python 
reads "Special cases aren't special enough to break the rules"
and the rules at to this point is that there were absolutely no restrictions 
regarding using new syntax or terminology in the documentation.

I understand the concerns and I take them into account, but for these reasons 
together with what other core devs are exposing, I think this
syntax should be included into the documentation (including trailing "/") as 
this was one core motivation for the PEP.

--

___
Python tracker 

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

[issue36894] test_multiprocessing_spawn regression on Windows

[Łukasz Langa]

Łukasz Langa  added the comment:

Can this be closed?

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue33725] Python crashes on macOS after fork with no exec

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Jun 4, 2019, at 08:11, STINNER Victor  wrote:
> Ned Deily:
>> No, it has *always* been unsafe. What's new as of 10.13/14 is that macOS 
>> tries much harder at runtime to detect such cases and more predictably cause 
>> an error rather than letter than let the process run on and possibly fail 
>> nondeterministically.
> 
> Hum, in the doc, I wrote:
> 
> .. versionchanged:: 3.8
> 
>   On macOS, *spawn* start method is now the default: *fork* start method is no
>   longer reliable on macOS, see :issue:`33725`.
> 
> Should we change this text? Any proposition?

Thanks Victor.  I don’t think “reliable” is strong enough, since this will 
definitely lead to core dumps under certain conditions.  What about:

   On macOS, the *spawn* start method is now the default.  The *fork* start 
method should
   be considered unsafe as it can lead to crashes of the subprocess.  See 
:issue:`33725`.

--

___
Python tracker 

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

[issue37154] test_utf8_mode: test_env_var() fails on AMD64 Fedora Rawhide Clang Installed 3.7

[STINNER Victor]

STINNER Victor  added the comment:

Related failure on "AMD64 Fedora Rawhide Clang Installed 2.7":
https://buildbot.python.org/all/#/builders/186/builds/23

ERROR: test_setlocale_unicode (test.test_locale.TestMiscellaneous)
--
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/2.7.cstratak-fedora.installed/build/target/lib/python2.7/test/test_locale.py",
 line 500, in test_setlocale_unicode
user_locale = locale.setlocale(locale.LC_CTYPE, '')
  File 
"/home/buildbot/buildarea/2.7.cstratak-fedora.installed/build/target/lib/python2.7/locale.py",
 line 581, in setlocale
return _setlocale(category, locale)
Error: unsupported locale setting

--

___
Python tracker 

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

[issue37153] test_venv: test_multiprocessing() hangs randomly on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor  added the comment:


New changeset bc6469f79ca13217b784fb47da7ec83484a3debe by Victor Stinner in 
branch 'master':
bpo-37153: test_venv.test_mutiprocessing() calls pool.terminate() (GH-13816)
https://github.com/python/cpython/commit/bc6469f79ca13217b784fb47da7ec83484a3debe


--

___
Python tracker 

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

[issue37154] test_utf8_mode: test_env_var() fails on AMD64 Fedora Rawhide Clang Installed 3.7

[STINNER Victor]

STINNER Victor  added the comment:

glibc-all-langpacks was already installed, but glibc-langpack-en was not 
installed. I installed glibc-langpack-en: it worked around the issue.

--

___
Python tracker 

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

[issue37154] test_utf8_mode: test_env_var() fails on AMD64 Fedora Rawhide Clang Installed 3.7

[STINNER Victor]

STINNER Victor  added the comment:

It seems like this buildbot has no locale, maybe they have been removed:

vstinner@python-builder-rawhide$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
C.utf8
POSIX

--
nosy: +cstratak

___
Python tracker 

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

[issue37154] test_utf8_mode: test_env_var() fails on AMD64 Fedora Rawhide Clang Installed 3.7

[STINNER Victor]

New submission from STINNER Victor :

AMD64 Fedora Rawhide Clang Installed 3.7:
https://buildbot.python.org/all/#/builders/195/builds/104


FAIL: test_env_var (test.test_utf8_mode.UTF8ModeTests)
--
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora.installed/build/target/lib/python3.7/test/test_utf8_mode.py",
 line 93, in test_env_var
self.assertEqual(out, '0')
AssertionError: '1' != '0'
- 1
+ 0


On the buildbot:

vstinner@python-builder-rawhide$ env|grep -E 'LC_|LANG'
LANG=en_US.UTF-8

vstinner@python-builder-rawhide$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
(...)
LC_ALL=


Extract of the test:

# Cannot test with the POSIX locale, since the POSIX locale enables
# the UTF-8 mode
if not self.posix_locale():
# PYTHONUTF8 should be ignored if -E is used
out = self.get_output('-E', '-c', code, PYTHONUTF8='1')
self.assertEqual(out, '0')

The problem seems to be posix_locale() which fails if the C locale has been 
coerced by PEP 538:

POSIX_LOCALES = ('C', 'POSIX')

def posix_locale(self):
loc = locale.setlocale(locale.LC_CTYPE, None)
return (loc in POSIX_LOCALES)

This code doesn't work if LC_CTYPE is already coerced.

--
components: Tests
messages: 344603
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_utf8_mode: test_env_var() fails on AMD64 Fedora Rawhide Clang 
Installed 3.7
versions: Python 3.7

___
Python tracker 

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

[issue37144] tarfile.open: improper handling of path-like object

[Demid]

Change by Demid :


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

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Actually "man copy_file_range" claims it can do server-side copy, meaning no 
network traffic between client and server if *src* and *dst* live on the same 
network fs. So I agree copy_file_range() should be preferred over sendfile() 
after all. =)
I have a wrapper for copy_file_range() similar to what I did in shutil in 
issue33671 which I can easily integrate, but I wanted to land this one first:
https://bugs.python.org/issue37096
Also, I suppose we cannot land this in time for 3.8?

--

___
Python tracker 

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

[issue36742] urlsplit doesn't accept a NFKD hostname with a port number

[Steve Dower]

Steve Dower  added the comment:


New changeset f61599b050c621386a3fc6bc480359e2d3bb93de by Steve Dower in branch 
'2.7':
bpo-36742: Corrects fix to handle decomposition in usernames (GH-13812)
https://github.com/python/cpython/commit/f61599b050c621386a3fc6bc480359e2d3bb93de


--

___
Python tracker 

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

[issue37144] tarfile.open: improper handling of path-like object

[Demid]

Change by Demid :


--
nosy: +dm

___
Python tracker 

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

[issue37144] tarfile.open: improper handling of path-like object

[Demid]

Change by Demid :


--
nosy: +zygocephalus -dm

___
Python tracker 

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

[issue37153] test_venv: test_multiprocessing() hangs randomly on x86 Windows7 3.x

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue37153] test_venv: test_multiprocessing() hangs randomly on x86 Windows7 3.x

[STINNER Victor]

New submission from STINNER Victor :

x86 Windows7 3.x:
https://buildbot.python.org/all/#/builders/58/builds/2573

0:42:21 load avg: 4.40 [283/423/1] test_venv crashed (Exit code 1)
Timeout (0:35:00)!
Thread 0x00c0 (most recent call first):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", 
line 1332 in _readerthread
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
865 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
923 in _bootstrap_inner
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
885 in _bootstrap

Thread 0x0c6c (most recent call first):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", 
line 1332 in _readerthread
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
865 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
923 in _bootstrap_inner
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
885 in _bootstrap

Thread 0x0350 (most recent call first):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
1015 in _wait_for_tstate_lock
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 
999 in join
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", 
line 1361 in _communicate
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", 
line 999 in communicate
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_venv.py", 
line 40 in check_output
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_venv.py", 
line 327 in test_multiprocessing
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", 
line 628 in _callTestMethod
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", 
line 671 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", 
line 731 in __call__
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", 
line 122 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", 
line 84 in __call__
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", 
line 122 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", 
line 84 in __call__
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", 
line 122 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", 
line 84 in __call__
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py",
 line 176 in run
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py",
 line 1984 in _run_suite
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py",
 line 2080 in run_unittest
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py",
 line 203 in _test_module
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py",
 line 228 in _runtest_inner2
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py",
 line 264 in _runtest_inner
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py",
 line 135 in _runtest
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py",
 line 187 in runtest
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py",
 line 66 in run_tests_worker
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py",
 line 611 in _main
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py",
 line 588 in main
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py",
 line 663 in main
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", 
line 46 in _main
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", 
line 50 in 
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", 
line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", 
line 192 in _run_module_as_main

(...)

Re-running failed tests in verbose mode
Re-running test_venv in verbose mode
test_defaults (test.test_venv.BasicTest) ... ok
test_executable (test.test_venv.BasicTest) ... ok
test_executable_symlinks (test.test_venv.BasicTest) ... skipped 'Needs symlinks'
test_isolation 

[issue33762] temp file isn't IOBase

[Greg Lindahl]

Greg Lindahl  added the comment:

This is breaking aiohttp client file multipart uploads from temporary files. 
I'd be willing to bet that a lot of libraries do isinstance(foo, io.IOBase) 
deep in their guts.

--
nosy: +wumpus

___
Python tracker 

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

[issue36421] A possible double decref in _ctypes.c's PyCArrayType_new()

[STINNER Victor]

STINNER Victor  added the comment:

> just one question, how did you detect this bug?

I bet that Zackery Spytz used Svace static analyzer: 
http://www.ispras.ru/en/technologies/svace/

See also: 
https://python-security.readthedocs.io/security.html#static-analysers-of-cpython-code-base

--
nosy: +vstinner

___
Python tracker 

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