[issue32591] Deprecate sys.set_coroutine_wrapper and replace it with more focused API(s)

[Nathaniel Smith]

New submission from Nathaniel Smith :

sys.set_coroutine_wrapper is a problematic API. It was added to solve a 
specific problem: asyncio debug mode wanting to track where coroutine objects 
are created, so that when unawaited coroutines are GC'ed, the warning they 
print can include a traceback. But to do this, it adds a *very* generic hook 
that lets you hook into the coroutine creation code to replace all instances of 
a built-in type with an arbitrary new type, which is highly unusual. It's hard 
to use correctly (see bpo-30578, and bpo-24342 before it). It's hard to use 
without creating performance problems, since anything you do here tends to add 
overhead to every async function call, and in many cases also every async 
function frame suspend/resume cycle.

Fortunately, it's explicitly documented as provisional. (I think Yury 
intentionally excluded it from the stabilization of the rest of asyncio and 
async/await, because of the reasons above.) And the things we *actually* want 
to do here are very simple. The only known use cases are the one mentioned 
above (see asyncio.coroutines.CoroWrapper), and the one in bpo-30491. So after 
discussions with Yury, I'm proposing to migrate those both into the interpreter 
as directly usable, fast, built-in features that can be used individually or 
together, and deprecate sys.set_coroutine_wrapper.

See bpo-30491 for details on that use case; here I'll discuss my plan for 
replacing the "coroutine origin tracking" that asyncio debug mode does.

We add a new function sys.set_coroutine_origin_tracking(depth), and I guess 
sys.get_coroutine_origin_tracking() because why not. The depth is thread-local, 
and defaults to 0, which means that newly created coroutines don't capture any 
origin info.

When a coroutine is created, it will check the current origin_tracking depth, 
and capture that many frames of traceback information. Like the current asyncio 
debug code and unlike real tracebacks, we won't capture actual frame objects -- 
we'll just capture (filename, lineno, function) information, to avoid pinning 
objects in memory. This is a debug helper, so it should avoid changing 
semantics whenever possible.

Later, we can retrieve the captured information by accessing the new attribute 
coro.origin.

In addition, the code in CoroutineType.__del__ that currently emits a warning 
for unawaited coroutines, will be modified to check for whether 'self' has 
origin information, and print it if so, similar to the current asyncio debug 
wrapper.

Some particular points where I'd appreciate feedback:

Should we add an envvar to configure coroutine source tracking? What about an 
-X switch?

Should it be coro.origin or coro.cr_origin? On the one hand the cr_ prefixing 
is super annoying and I think we should probably get rid of it; on the other 
maybe we should keep it here so things stay consistent and then have a separate 
the debate about removing it in general.

Most important: what format should we use for storing the origin information? I 
can see three plausible approaches:

1. Call traceback.StackSummary.extract. This means re-entering the Python 
interpreter from inside the coroutine setup code, which makes me a little 
nervous. I guess there can't be any real re-entrancy issues here because if 
there were, set_coroutine_wrapper would already be hitting them. Can it cause 
problems during shutdown when the traceback module might have disappeared? (Not 
that anyone's likely to be instantiating coroutines at that point.) It also 
might be a bit slower than the other options below, but this isn't clear. OTOH, 
it has the benefit that coro.origin could be a full-fledged StackSummary with 
all its features, like traceback printing. Which honestly feels a little weird 
to me, because I know coroutine objects are built-in and StackSummary objects 
aren't, but it would certainly be convenient.

2. Capture (filename, lineno, function) directly in a packed struct, similar to 
how tracemalloc works. Then coro.origin can unpack this into a list of tuples 
or whatever. This is definitely very fast, and avoids re-entering Python. In 
practice we'd probably still end up needing to re-enter Python and using the 
traceback module when it came time to print a warning, though, because 
traceback printing is complicated and we don't want to reimplement it. Also, if 
the origin comes from a custom importer like zipimport, then we may not be able 
to look up the line information later, because that requires access to 
frame.f_globals["__loader__"].

3. Like (2), but insert a call to linecache.lazycache for each origin frame we 
capture. This would fix option (2)'s issue with printing source lines, but it 
means re-entering Python as well, so at this point maybe it'd just be simpler 
to go with option (1).

Given this analysis I guess I'm leaning towards just calling 
StackSummary.extract, but I don't feel like I fully understand the consequences 
of calling into a 

[issue32590] Proposal: add an "ensure(arg)" builtin for parameter validation

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Oh I can just imagine the bike-shedding on this one :-)

I'm not really convinced this is needed, but for what it's worth I think that 
given the intended use-case (checking function parameters) ValueError would be 
a more appropriate default exception type. The given argument has the wrong 
value, hence ValueError.

On the other hand, it is more common (at least for me) to check arguments with 
isinstance, so maybe the default should be TypeError.

Definitely needs a PEP.

--
nosy: +steven.daprano
stage: needs patch -> 

___
Python tracker 

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

[issue31087] asyncio.create_subprocess_* do not honor `encoding`

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Python's codecs already support partial decode, exactly to handle this kind of 
case. See codecs.getincremental{en,de}coder and

https://docs.python.org/3/library/codecs.html#incremental-encoding-and-decoding

--
nosy: +njs

___
Python tracker 

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

[issue31087] asyncio.create_subprocess_* do not honor `encoding`

[Dima Tisnek]

Dima Tisnek  added the comment:

I'd love to see universal_newlines=True in asyncio.subprocess.

--
nosy: +Dima.Tisnek

___
Python tracker 

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

[issue32589] Statistics as a result from timeit

[Matthias Gilch]

Matthias Gilch  added the comment:

Population seemed appropriate to me. 

I'd define the list of times as a whole "population" that stands for its own. 

I should probably add both, the sample and population, values.

--

___
Python tracker 

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

[issue32589] Statistics as a result from timeit

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> What sort of statistics...?

I answered my own question... I see that in your PR, you return a dict with the 
mean, median, *population* variance and standard deviation, and total.

Why the population variance/stdev rather than the sample? That seems 
inappropriate to me.

--

___
Python tracker 

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

[issue32589] Statistics as a result from timeit

[Steven D'Aprano]

Steven D'Aprano  added the comment:

What sort of statistics, and why do you think they are going to be meaningful?

Measurement errors in the timings aren't two-sided, they are only one-sided, 
which means calculating the mean and standard deviation isn't appropriate. This 
is documented in the Timer.repeat() method:

Note: it's tempting to calculate mean and standard deviation
from the result vector and report these.  However, this is not
very useful.  In a typical case, the lowest value gives a lower
bound for how fast your machine can run the given code snippet;
higher values in the result vector are typically not caused by
variability in Python's speed, but by other processes interfering
with your timing accuracy.  So the min() of the result is
probably the only number you should be interested in.


The purpose of the mean is to estimate the actual time taken by the 
computation, less any random errors ("noise") in the measurement values.

If random noise is centred around zero, then the positive errors and the 
negative errors tend to cancel, and the mean is the best estimate of the actual 
computation time. But the noise isn't centred on zero, there are no negative 
noise, and the mean estimates the computation time plus the average measurement 
error, not the computation time.

In other words, given a bunch of measurements:

timer = Timer(code, setup)
values = timer.repeat()

the closest estimate to the true computation time is min(values), not 
mean(values).

If you still insist on generating statistics, they're not difficult to collect 
using the statistics module:

statistics.mean(values)
statistics.stdev(values)

If there are additional statistics you would like to see, they should be added 
to the statistics module, not timeit.

--
nosy: +steven.daprano, tim.peters

___
Python tracker 

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

[issue32590] Proposal: add an "ensure(arg)" builtin for parameter validation

[Nick Coghlan]

New submission from Nick Coghlan :

This proposal is an outcome of repeated requests on python-ideas that assert 
statements be made unconditional, so they can be legitimately used for 
parameter validation, rather than solely as a form of inline self-test.

Rather than changing the assert statement, an alternative option would be to 
provide a new builtin (suggested name: "ensure") that raises ValidationError (a 
new subclass of AssertionError) if the first argument is false.

As a function, the new builtin could accept parameters for:

- the message to be reported on failure
- the exception type to be raised on failure

And since it would only be a new builtin rather than a new keyword, existing 
uses of the name "ensure" would be unaffected (except to the extent that 
linters may start warning about shadowing a builtin).

(Since it's a suggestion for a new builtin, actually doing this would require a 
PEP, which I'm not planning to write, I just wanted to get the suggestion 
explicitly on the record rather than leaving it buried in mailing list archives)

--
messages: 310219
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Proposal: add an "ensure(arg)" builtin for parameter validation
type: enhancement

___
Python tracker 

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

[issue32589] Statistics as a result from timeit

[Matthias Gilch]

Change by Matthias Gilch :


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

___
Python tracker 

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

[issue32589] Statistics as a result from timeit

[Matthias Gilch]

New submission from Matthias Gilch :

I propose to add a function parameter for timeit to get some statistics back 
from it. I think it's inconvenient to write those stubs every time when we have 
a method for this in the standard library that could be easily used with a few 
changes in it.

--
components: Library (Lib)
messages: 310218
nosy: MGilch
priority: normal
severity: normal
status: open
title: Statistics as a result from timeit
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

[issue32588] Move _findvs into its own extension module

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +5075

___
Python tracker 

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

[issue32588] Move _findvs into its own extension module

[Steve Dower]

Change by Steve Dower :


--
keywords: +patch
pull_requests: +5074
stage: needs patch -> patch review

___
Python tracker 

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

[issue29911] Uninstall command line in Windows registry does not uninstall

[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

[issue32588] Move _findvs into its own extension module

[Steve Dower]

Change by Steve Dower :


--
assignee:  -> steve.dower

___
Python tracker 

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

[issue14127] add st_*time_ns fields to os.stat(), add ns keyword to os.*utime*(), os.*utimens*() expects a number of nanoseconds

[Jesús Cea Avión]

Change by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Steve Dower]

Steve Dower  added the comment:

I don't think it's too late (and I don't think this counts as a feature either, 
so the b1 deadline doesn't apply), but the patch would need to include an 
update to What's New as well as the usual stuff.

--

___
Python tracker 

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

[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers

[Angie G]

Change by Angie G :


--
components: +Build, SSL
type: resource usage -> performance

___
Python tracker 

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

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Eryk Sun]

Eryk Sun  added the comment:

PyWin32's win32api.RegQueryValueEx and win32api.RegEnumValue also use the same 
documented interpretation of REG_MULTI_SZ [1] (i.e. a "sequence of 
null-terminated strings, terminated by an empty string").

[1]: https://msdn.microsoft.com/en-us/library/ms724884

However, in practice Windows doesn't follow this literal interpretation. For 
example, the Session Manager (smss.exe) reads the "PendingFileRenameOperations" 
REG_MULTI_SZ value using the documented runtime library function 
RtlQueryRegistryValues [2]. By default, this function calls the specified 
QueryRoutine for each null-terminated string when reading a REG_MULTI_SZ value. 

[2]: https://msdn.microsoft.com/en-us/library/ff562046

I've verified that RtlQueryRegistryValues does not terminate the read on the 
first empty string, but instead continues to iterate through the entire value. 
See the attached test script, rtlqueryreg.py. The following output was obtained 
after two calls to MoveFileEx with the flag MOVEFILE_DELAY_UNTIL_REBOOT that 
pended operations to delete "foo" and rename "meep" to "bar":

PendingFileRenameOperations, REG_SZ, \??\C:\Temp\foo
PendingFileRenameOperations, REG_SZ, 
PendingFileRenameOperations, REG_SZ, \??\C:\Temp\meep
PendingFileRenameOperations, REG_SZ, \??\C:\Temp\bar

Currently, winreg terminates reading this value at the first empty string. For 
example:

>>> hkey = winreg.OpenKey(winreg.HKEY_LOCAL_MACHINE,
... r'SYSTEM\CurrentControlSet\Control\Session Manager')
>>> winreg.QueryValueEx(hkey, 'PendingFileRenameOperations')
(['\\??\\C:\\Temp\\foo'], 7)

This behavior is inconsistent with Windows, which I think presents a strong 
case for the suggested change. As always, there's an issue with introducing 
breaking changes. It may be too late in the development cycle to introduce this 
change in 3.7.

--
nosy: +eryksun
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47394/rtlqueryreg.py

___
Python tracker 

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

[issue32566] Not able to open Python IDLE

[Steve Dower]

Steve Dower  added the comment:

Looks like you have a prerelease version of the CRT on your machine. Try 
finding and installing the latest Visual C++ 2017 Redistributables from 
Microsoft.

A newer version would have been installed by Python but since it wasn't I 
assume you have some other program on your PATH that has included a (not quite) 
private copy of ucrtbase.dll. If you can find and update or uninstall that 
program, and then reinstall Python it should resolve it.

--

___
Python tracker 

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

[issue3177] Add shutil.open

[Daniel Plakhotich]

Daniel Plakhotich  added the comment:

> tl;dr: shutil.whatever should call startfile(..., 'edit') or xdg-open; other 
> actions implemented by startfile are not cross-platform.

xdg-open is just a shell script that calls desktop-specific launchers. The 
behavior of these launchers is very different when it comes to executables. 
There is no guarantee that calling xdg-open for a script will open it for 
editing.

For example, there are 3 launchers on my XFCE machine: exo-open (native for 
XFCE), gvfs-open (GNOME), and kde-open. When called with a .py script with 
shebang line and executable bit set, exo-open and kde-open open text editor, 
but gvfs-open launches the script. When called for a real exe, exo-open and 
gvfs-open launch it, but kde-open brings a message box saying that the exe will 
not be started for safety reasons.

***

The patch raises NoAssociatedApplicationError when xdg-open returns 3, but this 
error code actually means that a launcher was not found.

--
nosy: +plakhotich

___
Python tracker 

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

[issue9033] cmd module tab misbehavior

[Daniel]

Daniel  added the comment:

I can confirm this behaviour for python 3.6.0 on Mac OS X 10.12.6

--
nosy: +boompig
versions: +Python 3.6 -Python 2.7, 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

[issue32588] Move _findvs into its own extension module

[Steve Dower]

Steve Dower  added the comment:

Actually, I'd prefer not dropping it into the Lib directory, so probably 
DLLs/_distutils_findvs.pyd is the way to go.

--

___
Python tracker 

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

[issue21009] Potential deadlock in concurrent futures when garbage collection occurs during Queue.get

[Antoine Pitrou]

Antoine Pitrou  added the comment:

There's a proposed fix in https://github.com/python/cpython/pull/5216
It would be nice if someone able to reproduce this issue could test it (the 
reproducer script here wouldn't work with the new SimpleQueue implementation).

--

___
Python tracker 

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

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the heads up Mark.  Unfortunately the reproducer script 
https://bugs.python.org/issue21009 needs to hack into Queue.get(), which isn't 
possible for the C-implemented SimpleQueue.

--

___
Python tracker 

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

[issue32588] Move _findvs into its own extension module

[Steve Dower]

New submission from Steve Dower :

The _findvs module I added for distutils has added load-time dependencies on 
the ole32 and oleaut32 DLLs.

To reduce startup time, we should move _findvs into its own .pyd (unless I hear 
a better suggestion, I like "distutils._findvs.pyd").

--
components: Distutils, Windows
messages: 310209
nosy: dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Move _findvs into its own extension module
type: performance
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue32226] Implement PEP 560: Core support for typing module and generic types

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e860089fd93728824cf586fa4d91f08eff3bab73 by Victor Stinner in 
branch 'master':
bpo-32226: Fix memory leak in generic_alias_dealloc() (#5212)
https://github.com/python/cpython/commit/e860089fd93728824cf586fa4d91f08eff3bab73


--

___
Python tracker 

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

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

[Gregory P. Smith]

Change by Gregory P. Smith :


--
title: concurrent.futures.thread potential deadlock due to Queue in weakref 
callback -> concurrent.futures.thread deadlock due to Queue in weakref callback

___
Python tracker 

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

[issue21009] Potential deadlock in concurrent futures when garbage collection occurs during Queue.get

[Gregory P. Smith]

Gregory P. Smith  added the comment:

there's a PR on the other issue i opened for this without noticing this one so 
i'm marking this as the dup.

--
nosy: +gregory.p.smith
resolution:  -> duplicate
stage:  -> patch review
status: open -> closed
superseder: queue.Queue() is not reentrant, so signals and GC can cause 
deadlocks -> concurrent.futures.thread potential deadlock due to Queue in 
weakref callback

___
Python tracker 

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

[issue32580] Fallback to dev_urandom doesn't work when py_getrandom returns -1

[Jernej Simončič]

Jernej Simončič  added the comment:

Qnap is a NAS, and while I'm running Gentoo inside LXC, EFAULT is returned by 
getrandom syscall even in the host OS. The model I'm doing this on is TS-228, 
uname -a of the host OS reports:

Linux qnap 3.10.20-al-2.5.3 #67 SMP PREEMPT Sat Dec 30 04:29:34 CST 2017 armv7l 
unknown

This is with the latest firmware installed as of this writing - 4.3.4.0435 
(30.12.2017).

--

___
Python tracker 

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

[issue30693] tarfile add uses random order

[Ned Deily]

Ned Deily  added the comment:

This doesn't seem appropriate to me for backporting to existing releases (3.6. 
and 2.7).  AFAIK, the current file-system-order behavior has never been 
identified as a bug.  Unless there is a stronger case for changing the existing 
3.6.x behavior, I am -1 on backporting.

--
nosy: +ned.deily

___
Python tracker 

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

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Ned Deily]

Change by Ned Deily :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue32571] Speed up and clean up getting optional attributes in C code

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Well, mostly I just want to draw your attention to that use case to encourage 
you to make it public when it's ready :-)

--

___
Python tracker 

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

[issue32576] concurrent.futures.thread potential deadlock due to Queue in weakref callback

[Mark Dickinson]

Mark Dickinson  added the comment:

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

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations

[Seppo Yli-Olli]

New submission from Seppo Yli-Olli :

MSDN documents that REG_MULTI_SZ is not supposed to have \0\0 anywhere else 
than in the end. The comment in  
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/PC/winreg.c#L504
clearly shows that Python has the assumption that this specification is 
actually correct. However, Microsoft is violating it eg in 
https://technet.microsoft.com/en-us/library/cc960241.aspx which prevents you 
from reading that registry key in Python at all. This is a list which is 
treated as pairs:
"""
foo

meep
bar
"""
so you can have empty items which in Windows semantics means "remove this 
file". This results in a string like "foo\0\0meep\0\bar\0\0". I'm proposing 
relaxing Python registry handling semantics because it's clearly Microsoft 
isn't following this either

--
messages: 310202
nosy: nanonyme
priority: normal
severity: normal
status: open
title: Make REG_MULTI_SZ support PendingFileRenameOperations

___
Python tracker 

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

[issue32529] Call readinto in shutil.copyfileobj

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> rejected

___
Python tracker 

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

[issue32529] Call readinto in shutil.copyfileobj

[YoSTEALTH]

Change by YoSTEALTH :


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

[issue32586] urllib2 HOWTO URLError example minor error

[Tim Morris]

New submission from Tim Morris :

In the HOWTO for urllib2 for Python 2, in the Handling Exceptions section, it 
discusses the URLError exception being raised by urlopen() 
(https://docs.python.org/2/howto/urllib2.html#urlerror). The code snippet 
example for this has (I think) a minor error:
the 3rd line reads:
"except URLError as e:"
which I think should be:
"except urllib2.URLError as e:"

The code as given only works if urllib2 had been imported via:
"from urllib2 import *"
The snippet doesn't list the import statements but all the other examples just 
use "import urllib2" (and obviously "from x import *" is bad practice anyway 
and wouldn't be encouraged or expected).

I am relatively new to Python, so it's possible it *is* correct and I just 
implemented it incorrectly. But if not, it would be helpful to correct it (even 
though it's a very minor error) so that other newbies like me don't come 
unstuck when using the tutorial.

--
assignee: docs@python
components: Documentation
messages: 310201
nosy: MarmiteFox, docs@python
priority: normal
severity: normal
status: open
title: urllib2 HOWTO URLError example minor error
versions: Python 2.7

___
Python tracker 

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

[issue32571] Speed up and clean up getting optional attributes in C code

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Because this API is experimental. It was changed in recent 24 hours and may be 
changed more before merging or even after releasing 3.7.

--

___
Python tracker 

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

[issue32571] Speed up and clean up getting optional attributes in C code

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

PR 5222 provides functions _PyObject_LookupAttr() and _PyObject_LookupAttrId() 
with alternate interface. Some code becomes even more simpler.

The possible drawback of this approach is that the compiler should allocate the 
variable for the result on the stack instead of passing the result in a 
register (unless compilers are smart enough for optimizing out this case).

--

___
Python tracker 

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

[issue32571] Speed up and clean up getting optional attributes in C code

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +5073

___
Python tracker 

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

[issue32585] Add ttk::spinbox to tkinter.ttk

[Roundup Robot]

Change by Roundup Robot :


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

___
Python tracker 

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

[issue32585] Add ttk::spinbox to tkinter.ttk

[Alan Moore]

New submission from Alan Moore :

Ttk has a spinbox widget, which is a themed version of Tkinter spinbox, but 
this is missing from Python's ttk implementation.

--
components: Tkinter
messages: 310198
nosy: Alan Moore
priority: normal
severity: normal
status: open
title: Add ttk::spinbox to tkinter.ttk
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue32580] Fallback to dev_urandom doesn't work when py_getrandom returns -1

[STINNER Victor]

STINNER Victor  added the comment:

OK, looks like Qnap is doing something weird there - calls to getrandom result 
in EFAULT

Aha, first time that I see this error on getrandom().

Is it a kernel change? A libc change? Is Qnap a kind of sandbox?

--

___
Python tracker 

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

[issue32580] Fallback to dev_urandom doesn't work when py_getrandom returns -1

[Jernej Simončič]

Jernej Simončič  added the comment:

OK, looks like Qnap is doing something weird there - calls to getrandom result 
in EFAULT, which results in . PHP had the same problem: 
https://bugs.php.net/bug.php?id=75409

Changing "if (errno == ENOSYS || errno == EPERM) {" to "if (errno == ENOSYS || 
errno == EPERM || errno == EFAULT) {" also works.

--

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[Jeethu Rao]

Jeethu Rao  added the comment:

It's also interesting that in 
https://gist.github.com/pitrou/29eb7592fa1eae2be390f3bfa3db0a3a :

| django_template | 307 ms| 312 ms   | 1.02x slower 
| Not significant|

It seems to be slower and the benchmarks before it (2to3, chameleon, chaos, 
crypto_pyaes, deltablue) which we now know barely use list.insert are slightly 
faster :)

¯\_(ツ)_/¯

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[David CARLIER]

David CARLIER  added the comment:

Gives same outcome but maybe someone else can confir,

--

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[STINNER Victor]

STINNER Victor  added the comment:

In https://gist.github.com/jeethu/dc0811d415dd6d1a1621761e43842f88 I read:

| django_template | 160 ms | 129 ms | 1.24x faster | Significant (t=15.05) |

So on this benchmark, the optimization seems significant. But in the same 
paste, I see other benchmarks 1.2x faster whereas they don't abuse 
list.insert(), and maybe don't use list.insert() at all.

Maybe Django template engine should be fixed to use deque instead ;-)

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[David CARLIER]

David CARLIER  added the comment:

uuid_create only I think.

--

___
Python tracker 

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

[issue32584] Uninitialized free_extra in code_dealloc

[Jeethu Rao]

New submission from Jeethu Rao :

In one of patches I'm building, (yet another attempt at caching 
LOAD_GLOBALS)[1], I'm using the private APIs from PEP 523 to store an array 
with every code object. I'm calling _PyEval_RequestCodeExtraIndex with 
PyMem_Free for the freefunc argument. While running  the cpython testsuite, I 
found that test_embed case crashes with a segfault. The gdb backtrace[2] seems 
to indicate that PyInterpreterState::co_extra_freefuncs is uninitialized, while 
it should be a pointer to the PyMem_Free function. 

One way to work around this is to set the array as a member on the PyCodeObject 
struct and use it directly. And I've verified that it works. Am I using the PEP 
523 private api correctly? Also, on Linux, this consistently crashes while on 
OSX, it occasionally doesn't crash which makes me wonder if it's some kind of a 
race condition involving Sub-interpreters. The attached gist[2] has steps for 
repro.

[1]: 
https://github.com/python/cpython/compare/master...jeethu:py3.7_load_global_cache
[2]: https://gist.github.com/jeethu/6d92185ca97dd692e7fadcd105e0ef70

--
components: Interpreter Core
messages: 310191
nosy: jeethu
priority: normal
severity: normal
status: open
title: Uninitialized free_extra in code_dealloc
type: crash
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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

typo here:

So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_create() function is wrong 
(if that is what it is using - was it/can it also use the uuid_generate* 
routines?

i.e., does AMD FreeBSD use uuid_create() or uuid_generate() - or can it use 
both?

Could someone with AMD try:
Modules/_uuidmodule.c

 +12  static PyObject *
   +13  py_uuid_generate_time_safe(void)
   +14  {
   +15  uuid_t uuid;
   +16  #ifdef HAVE_UUID_GENERATE_TIME_SAFE
   +17  int res;
   +18
   +19  res = uuid_generate_time_safe(uuid);
   +20  return Py_BuildValue("y#i", (const char *) uuid, sizeof(uuid), res);
   +21  #elif HAVE_UUID_GENERATE_TIME
   +22  uuid_generate_time(uuid);
   +23  return Py_BuildValue("y#O", (const char *) uuid, sizeof(uuid), 
Py_None);
   +24  #elif HAVE_UUID_CREATE
   +25  uint32_t status;
   +26  uuid_create(, );
   +27  return Py_BuildValue("y#i", (const char *) , sizeof(uuid), 
(int) status);
   +28  #else
   +29  #error "no uuid library function available"
   +30  #endif
   +31  }

--

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[Jeethu Rao]

Jeethu Rao  added the comment:

> What is 54640?

That's the pid of the process.

> I'm interested to know which benchmarks call list.insert() 40k times.

The django_template benchmark.

--

___
Python tracker 

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

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[Antony Lee]

Change by Antony Lee :


--
nosy:  -Antony.Lee

___
Python tracker 

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

[issue32583] Crash during decoding using UTF-16/32 and custom error handler

[Alexander Sibiryakov]

New submission from Alexander Sibiryakov :

The CPython interpreter gets SIGSEGV or SIGABRT during the run. The script 
attempts to decode binary file using UTF-16-LE encoding and custom error 
handler. The error handler is poorly built, and doesn't respect the unicode 
standard with wrong calculation of the new position for decoder to continue. 
This somehow interfere with internal C code doing memory allocation. The result 
is invalid writes outside of allocated block.

Here is how it looks like with Python 3.7.0a4+ (heads/master:44a70e9, Jan 17 
2018, 12:18:45) run under Valgrind 3.11.0. Please see the full Valgrind output 
in attached valgrind.log.

==24836== Invalid write of size 4
==24836==at 0x4C6B17: ucs4lib_utf16_decode (codecs.h:540)
==24836==by 0x4C6B17: PyUnicode_DecodeUTF16Stateful (unicodeobject.c:5600)
==24836==by 0x55AAD3: _codecs_utf_16_le_decode_impl (_codecsmodule.c:363)
==24836==by 0x55AB6C: _codecs_utf_16_le_decode (_codecsmodule.c.h:371)
==24836==by 0x4315D6: _PyMethodDef_RawFastCallKeywords (call.c:651)
==24836==by 0x431840: _PyCFunction_FastCallKeywords (call.c:730)
==24836==by 0x4ED159: call_function (ceval.c:4580)
==24836==by 0x4ED159: _PyEval_EvalFrameDefault (ceval.c:3134)
==24836==by 0x4E302D: PyEval_EvalFrameEx (ceval.c:545)
==24836==by 0x4E3A42: _PyEval_EvalCodeWithName (ceval.c:3971)
==24836==by 0x430EDD: _PyFunction_FastCallDict (call.c:376)
==24836==by 0x4336B0: PyObject_Call (call.c:226)
==24836==by 0x433839: PyEval_CallObjectWithKeywords (call.c:826)
==24836==by 0x4FEAA6: _PyCodec_DecodeInternal (codecs.c:471)
==24836==  Address 0x6cf4bf8 is 0 bytes after a block of size 339,112 alloc'd
==24836==at 0x4C2DB8F: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24836==by 0x467635: _PyMem_RawMalloc (obmalloc.c:75)
==24836==by 0x467B7D: _PyMem_DebugRawAlloc (obmalloc.c:2033)
==24836==by 0x467C1F: _PyMem_DebugRawMalloc (obmalloc.c:2062)
==24836==by 0x467C40: _PyMem_DebugMalloc (obmalloc.c:2202)
==24836==by 0x468BFF: PyObject_Malloc (obmalloc.c:616)
==24836==by 0x493902: PyUnicode_New (unicodeobject.c:1293)
==24836==by 0x4BEA4F: _PyUnicodeWriter_PrepareInternal 
(unicodeobject.c:13456)
==24836==by 0x4C6D39: _PyUnicodeWriter_WriteCharInline 
(unicodeobject.c:13494)
==24836==by 0x4C6D39: PyUnicode_DecodeUTF16Stateful (unicodeobject.c:5637)
==24836==by 0x55AAD3: _codecs_utf_16_le_decode_impl (_codecsmodule.c:363)
==24836==by 0x55AB6C: _codecs_utf_16_le_decode (_codecsmodule.c.h:371)
==24836==by 0x4315D6: _PyMethodDef_RawFastCallKeywords (call.c:651)

--
Added file: https://bugs.python.org/file47393/valgrind.log

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[STINNER Victor]

STINNER Victor  added the comment:

> Sure! https://gist.github.com/jeethu/000a2d3ecd9033c0ef51331f062ac294

I don't understand how to read this output.

"54640 ins1 called 40050 times"

What is 54640?

I'm interested to know which benchmarks call list.insert() 40k times.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

Actually, the libc/libuuid function called should be setting the 
version/variant values as well.

So, I think the AMD64 FreeBSD 10.x Shared 3.x uuid_generate() function is wrong 
(if that is what it is using - was it/can it also use the uuid_generate* 
routines?

FYI:

I notice the AIX include file does not actually define the bits for RFC_4122, 
etc.., but the include file comments does show that the implementation is 
taking them into account.

/** The strlen() of a UUID string (does not include terminating null) */
#define UUID_STRLEN 36
/**
 * Constant value indicating an as-yet undetermined UUID for a thing.  Spells \c
 * "\0\0UUID\x10_\x80UNKNOWN" in ASCII.  Zeroes at the top make it very unlikely
 * to collide with a uuid_create()d value, which puts a timestamp in that spot.
 * The \c "\x10" and \c "\x80" are reserved/version/mask bits that make this
 * conform to the format expected by the uuid.h API.
 */
#define UUID_UNKNOWN (uuid_t){0x, 0x4944, 0x105F, 0x80, 0x55, {0x4E, 
0x4B, 0x4E, 0x4F, 0x57, 0x4E}}
#define UUID_UNKNOWN_STR   "-4944-105f-8055-4e4b4e4f574e"

I wrote a simple program to examine uuid for myself.

Maybe - if you ran a loop (looking at uuid1().variant and uuid1().version you 
could see if there is an incorrect version showing up. Rather than python - 
that would seem to be a library function error.

My very simple program:

cat -n ../x4.py
 1  import _uuid
 2  import uuid
 3  _generate_time_safe = _uuid.generate_time_safe
 4  _has_uuid_generate_time_safe = _uuid.has_uuid_generate_time_safe
 5  uuid_time, _ = _generate_time_safe()
 6
 7  uu1a = uuid.UUID(bytes=uuid_time)
 8  uu1b = uuid.uuid1()
 9  uu4 = uuid.uuid4()
10
11  print("a)uuid1 = %x" % uu1a.int)
12  print("b)uuid1 = %x" % uu1b.int)
13  print("")
14  print("a uuid1 = ",uu1a.fields, uu1a.version, uu1a.variant)
15  print("b uuid1 = ",uu1b.fields, uu1b.version, uu1b.variant)
16  uu1c = uuid.uuid1()
17  print("c uuid1 = ",uu1c.fields, uu1c.version, uu1c.variant)
18  print("")
19  print("  uuid4 = %x" % uu4.int)
20  print("  uuid4 = ",uu4.fields, uu4.version, uu4.variant)
21  print("")
22  uu4 = uuid.uuid4()
23  print("  uuid4 = %x" % uu4.int)
24  print("  uuid4 = ",uu4.fields, uu4.version, uu4.variant)

--

___
Python tracker 

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

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[Tzu-ping Chung]

Tzu-ping Chung  added the comment:

Would it be possible for venv to do this automatically? Instead of using 
sys.executable, use

import sysconfig
dirname, exename = sysconfig.get_config_vars('BINDIR', 'BUILDPYTHON')

to populate values in the context?

--
nosy: +uranusjr

___
Python tracker 

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

[issue32583] Crash during decoding using UTF-16/32 and custom error handler

[Alexander Sibiryakov]

Change by Alexander Sibiryakov :


Added file: https://bugs.python.org/file47392/test_string.bin

___
Python tracker 

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

[issue32583] Crash during decoding using UTF-16/32 and custom error handler

[Alexander Sibiryakov]

Change by Alexander Sibiryakov :


--
files: decode_crash.py
nosy: sibiryakov
priority: normal
severity: normal
status: open
title: Crash during decoding using UTF-16/32 and custom error handler
type: crash
versions: Python 3.5, Python 3.7
Added file: https://bugs.python.org/file47391/decode_crash.py

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[Jeethu Rao]

Jeethu Rao  added the comment:

> > I still think those numbers are misleading or downright bogus.  There is no 
> > existing proof that list.insert() is a critical path in those benchmarks.

> Can someone check if these bencmarks really use list.insert() in hot code? If 
> yes, why? :-) The cost of list.insert() is known, no?

Sure! https://gist.github.com/jeethu/000a2d3ecd9033c0ef51331f062ac294

--

___
Python tracker 

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

[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv

[Tzu-ping Chung]

Tzu-ping Chung  added the comment:

Yup, seems so. Closing as duplicate then.

--
resolution:  -> duplicate
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

[issue32566] Not able to open Python IDLE

[Kiran]

Kiran  added the comment:

Hi,

Can someone help me to resolve the issue or let me know the cause of this error.

Thanks in advance.

--

___
Python tracker 

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

[issue32581] A bug of the write funtion of ConfigParser.py

[jiangjinhu]

jiangjinhu  added the comment:

But accidentally,with the "password = "" " in the configure files ,which are 
called by my services, the service will start successfully,and with "password = 
  ",the services can not.On the other hand ,I just set the option "addr = 
"127.0.0.1"",why the option "password = "" " will change.
Just add this.

--

___
Python tracker 

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

[issue32582] chr raises OverflowError

[STINNER Victor]

STINNER Victor  added the comment:

It's more an implementation issue.

I proposed PR 5218 to also raise a ValueError on overflow.

I propose to only change Python 3.7, and only Python 2.7 and 3.6 unchanged.

--
nosy: +vstinner
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue32582] chr raises OverflowError

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue32581] A bug of the write funtion of ConfigParser.py

[R. David Murray]

R. David Murray  added the comment:

I'll defer to Lukasz, but I don't believe this is a bug.  An empty value and a 
value of "" are equivalent in config.ini syntax, as far as I know.

--
nosy: +lukasz.langa

___
Python tracker 

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

[issue32582] chr raises OverflowError

[Uwe Kleine-König]

New submission from Uwe Kleine-König :

Hello,

the description for chr (from 
https://docs.python.org/3/library/functions.html#chr) reads as:

Return the string representing a character whose Unicode code
point is the integer i. [...] The valid range for the argument
is from 0 through 1,114,111 (0x10 in base 16). ValueError
will be raised if i is outside that range.

If however a value > 0x7fff (or < -0x8000) is provided, the function 
raises an Overflow error:

$ python3 -c 'print(chr(0x8000))'
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: signed integer is greater than maximum

This is either a documentation problem or (more like) an implementation issue. 
I attached a patch that fixes the issue for me. (I'm not sure however if I 
should call PyErr_Clear() before raising ValueError.)

--
components: Interpreter Core
files: chr-OverflowError.patch
keywords: patch
messages: 310178
nosy: ukl
priority: normal
severity: normal
status: open
title: chr raises OverflowError
versions: Python 3.6
Added file: https://bugs.python.org/file47390/chr-OverflowError.patch

___
Python tracker 

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

[issue29240] PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor  added the comment:

test_readline pass again on all buildbots, especially on FreeBSD 3.6 and 3.x 
buildbots.

There are no more known issues, the implementation of the PEP 540 (UTF-8 Mode) 
is now complete!

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

[issue32581] A bug of the write funtion of ConfigParser.py

[jiangjinhu]

jiangjinhu  added the comment:

The configure file "test.ini":

[section_a]
addr = "127.0.0.1"
password = ""

Change the value of addr by the "test.py":

import ConfigParser

tmpfile = "test.ini"
conf = ConfigParser.ConfigParser()
conf.read(tmpfile)
conf.set("section_a", "addr", "\"127.0.0.2\"")
cfgfile = open(tmpfile, 'w')
conf.write(cfgfile) 

After change the value of addr to 127.0.0.2,the test.ini will be:

[section_a]
addr = "127.0.0.2"
password = 

The "" of the password lost!

And one method which will fix this bug of the write function of the 
ConfigParder.py:

def write(self, fp):
"""Write an .ini-format representation of the configuration state."""
if self._defaults:
fp.write("[%s]\n" % DEFAULTSECT)
for (key, value) in self._defaults.items():
fp.write("%s = %s\n" % (key, str(value).replace('\n', '\n\t')))
fp.write("\n")
for section in self._sections:
fp.write("[%s]\n" % section)
for (key, value) in self._sections[section].items():
if key == "__name__":
continue
if (value is not None) or (self._optcre == self.OPTCRE):
if value == "":#
value = "\"\""  #
key = " = ".join((key, str(value).replace('\n', 
'\n\t')))#
else: #
key = " = ".join((key, str(value).replace('\n', 
'\n\t')))


fp.write("%s\n" % (key))
fp.write("\n") 


Please check it.
Thanks!

--

___
Python tracker 

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

[issue32581] A bug of the write funtion of ConfigParser.py

[jiangjinhu]

jiangjinhu  added the comment:

def write(self, fp):
"""Write an .ini-format representation of the configuration state."""
if self._defaults:
fp.write("[%s]\n" % DEFAULTSECT)
for (key, value) in self._defaults.items():
fp.write("%s = %s\n" % (key, str(value).replace('\n', '\n\t')))
fp.write("\n")
for section in self._sections:
fp.write("[%s]\n" % section)
for (key, value) in self._sections[section].items():
if key == "__name__":
continue
if (value is not None) or (self._optcre == self.OPTCRE):
if value == "":#
value = "\"\""  #
key = " = ".join((key, str(value).replace('\n', 
'\n\t')))#
else: #
key = " = ".join((key, str(value).replace('\n', 
'\n\t')))

  #  key = " = ".join((key, str(value).replace('\n', '\n\t')))

fp.write("%s\n" % (key))
fp.write("\n")

--

___
Python tracker 

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

[issue32248] Port importlib_resources (module and ABC) to Python 3.7

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 3a0cf931796b9ad1b4833ab89c79d284b4253c91 by Victor Stinner in 
branch 'master':
bpo-32248: Fix test_importlib.test_open() (#5213)
https://github.com/python/cpython/commit/3a0cf931796b9ad1b4833ab89c79d284b4253c91


--

___
Python tracker 

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

[issue30693] tarfile add uses random order

[Christian Heimes]

Christian Heimes  added the comment:

The patch changes behavior. It's fine for 3.7 but not for 3.6/2.7. Somebody may 
depend on filesystem order.

--
versions:  -Python 3.5

___
Python tracker 

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

[issue32581] A bug of the write funtion of ConfigParser.py

[R. David Murray]

R. David Murray  added the comment:

Please provide a way to reproduce the problem you are observing.  There is 
insufficient information here so far to understand the problem.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue30693] tarfile add uses random order

[STINNER Victor]

STINNER Victor  added the comment:

The only warranty in that TarFile.getmembers(), TarFile.getnames() and 
ZipFile.infolist() returns members/names "in the same order as the members in 
the archive".

Currently, there is no warranty when packing, only on unpack.

--
nosy: +vstinner

___
Python tracker 

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

[issue30693] tarfile add uses random order

[R. David Murray]

R. David Murray  added the comment:

Ah, I was just going to ask about that.  I guess I'm -0 on the backport as 
well.  The other reproducible build stuff is only going to land in 3.7. 
However, this is in a more general category than the pyc stuff, so I can see 
the argument for backporting it.

--
nosy:  -vstinner
versions: +Python 3.5

___
Python tracker 

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

[issue30693] tarfile add uses random order

[STINNER Victor]

STINNER Victor  added the comment:

Since we currently don't warranty *anything* about ordering, I like the idea of 
*fixing* Python 2.7 and 3.6 as well. +1 for fix it in 2.7, 3.6 and master.

--
nosy: +vstinner

___
Python tracker 

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

[issue32581] A bug of the write funtion of ConfigParser.py

[jiangjinhu]

New submission from jiangjinhu :

By the write funtion of ConfigParser.py,the partial content of the configue 
will change.

--
components: Library (Lib)
messages: 310168
nosy: jiangjinhu666
priority: normal
severity: normal
status: open
title: A bug of the write funtion of ConfigParser.py
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue30693] tarfile add uses random order

[Christian Heimes]

Christian Heimes  added the comment:

PS: I'm -0 to backport the change to 3.6 and 2.7. 3.5 is in security fix mode 
and therefore completely out of scope.

--
versions:  -Python 3.5

___
Python tracker 

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

[issue30693] tarfile add uses random order

[Christian Heimes]

Christian Heimes  added the comment:

+1 from me

In my opinion it's both a good idea to not sort the result of glob.glob() and 
make the order of tar and zip module content ordered. The glob module is low 
level and it makes sense to expose the file system sort order.

On the other hand tar and zip modules are on a higher level. Without sorting 
it's impossible to create reproducible archives. The performance impact is 
irrelevant. I/O and compression dominant performance.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue11192] test_socket error on AIX

[Michael Felt]

Michael Felt  added the comment:

I have tried jumping into the pdp using

but do not come much further in understanding how the expectations expressed in 
these comments are satisfied:

 +2153  # Tests for the sendmsg()/recvmsg() interface.  Where possible, the
 +2154  # same test code is used with different families and types of socket
 +2155  # (e.g. stream, datagram), and tests using recvmsg() are repeated
 +2156  # using recvmsg_into().
 +2157  #
 +2158  # The generic test classes such as SendmsgTests and
 +2159  # RecvmsgGenericTests inherit from SendrecvmsgBase and expect to be
 +2160  # supplied with sockets cli_sock and serv_sock representing the
 +2161  # client's and the server's end of the connection respectively, and
 +2162  # attributes cli_addr and serv_addr holding their (numeric where
 +2163  # appropriate) addresses.
 +2164  #


++ Details ++
14 tests failed again:
test_asyncio test_cmath test_ctypes test_datetime test_distutils
test_httplib test_httpservers test_os test_posix test_socket
test_ssl test_subprocess test_time test_utf8_mode


()
-> super().setUp()
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2187)setUp()
-> def setUp(self):
(Pdb) l
2182
2183# Time in seconds to wait before considering a test failed, or
2184# None for no timeout.  Not all tests actually set a timeout.
2185fail_timeout = 3.0
2186
2187 -> def setUp(self):
2188self.misc_event = threading.Event()
2189super().setUp()
2190
2191def sendToServer(self, msg):
2192# Send msg to the server.
(Pdb) s
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2188)setUp()
-> self.misc_event = threading.Event()
(Pdb) self

(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(499)__init__()
-> def __init__(self):
(Pdb) self

(Pdb) dir(self)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', 
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__', '_reset_internal_locks', 'clear', 
'isSet', 'is_set', 'set', 'wait']
(Pdb) l
494
495 """
496
497 # After Tim Peters' event class (without is_posted())
498
499  -> def __init__(self):
500 self._cond = Condition(Lock())
501 self._flag = False
502
503 def _reset_internal_locks(self):
504 # private!  called by Thread._reset_internal_locks by 
_after_fork()
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(500)__init__()
-> self._cond = Condition(Lock())
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(501)__init__()
-> self._flag = False
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/threading.py(501)__init__()->None
-> self._flag = False
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2189)setUp()
-> super().setUp()
(Pdb) l
2184# None for no timeout.  Not all tests actually set a timeout.
2185fail_timeout = 3.0
2186
2187def setUp(self):
2188self.misc_event = threading.Event()
2189 -> super().setUp()
2190
2191def sendToServer(self, msg):
2192# Send msg to the server.
2193return self.cli_sock.send(msg)
2194
(Pdb) s
--Call--
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(453)setUp()
-> def setUp(self):
(Pdb) l
448 called after tearDown on test failure or success.
449
450 Cleanup items are called even if setUp fails (unlike 
tearDown)."""
451 self._cleanups.append((function, args, kwargs))
452
453  -> def setUp(self):
454 "Hook method for setting up the test fixture before exercising 
it."
455 pass
456
457 def tearDown(self):
458 "Hook method for deconstructing the test fixture after testing 
it."
(Pdb) n
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(455)setUp()
-> pass
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/unittest/case.py(455)setUp()->None
-> pass
(Pdb) n
--Return--
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2189)setUp()->None
-> super().setUp()
(Pdb) l
2184# None for no timeout.  Not all tests actually set a timeout.
2185fail_timeout = 3.0
2186
2187def setUp(self):
2188self.misc_event = threading.Event()
2189 -> super().setUp()
2190
2191def sendToServer(self, msg):
2192# Send msg to the server.
2193return self.cli_sock.send(msg)
2194
(Pdb) s
> /data/prj/python/git/x067-python3-3.7/Lib/test/test_socket.py(2375)setUp()
-> print('stop here') #@@@
(Pdb) l
2370
2371def setUp(self):
2372import pdb #@@@
2373

[issue30693] tarfile add uses random order

[R. David Murray]

R. David Murray  added the comment:

Given the reproducible builds angle, I'd say this was worth doing.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[STINNER Victor]

STINNER Victor  added the comment:

> I still think those numbers are misleading or downright bogus.  There is no 
> existing proof that list.insert() is a critical path in those benchmarks.

Can someone check if these bencmarks really use list.insert() in hot code? If 
yes, why? :-) The cost of list.insert() is known, no?

--

___
Python tracker 

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

[issue32580] Fallback to dev_urandom doesn't work when py_getrandom returns -1

[STINNER Victor]

STINNER Victor  added the comment:

> I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying 
> to compile Python 3.5.4, the build failed with "Fatal Python error: failed to 
> get random numbers to initialize Python" (full details at 
> https://forums.gentoo.org/viewtopic-p-8172124.html ).

I'm surprised. Python 3.5.4 does contain my latest fix: commit 
035ba5da3e53e45c712b39fe1f6fb743e697c032 (bpo-29157).

> Looking at random.c, pyurandom returns -1 instead of falling back to 
> dev_urandom when py_getrandom returns -1, so the attached fix is simple.

Ignoring failures is not a good idea.

What is the result of the getrandom() function?

> glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 
> (doesn't support getrandom).

I expect n < 0 with errno = ENOSYS: py_getrandom() should return 0 in this 
case, not -1.

--
nosy: +vstinner

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le 17/01/2018 à 14:36, Jeethu Rao a écrit :
> 
> On the other hand, on the pyperformance comparison I'd posted yesterday[1], 
> there seems to be an average improvement of 1.27x  on the first seven 
> benchmarks, and the slowest slowdown is only 1.03x.

I still think those numbers are misleading or downright bogus.  There is
no existing proof that list.insert() is a critical path in those benchmarks.

--

___
Python tracker 

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

[issue32534] Speed-up list.insert: use memmove()

[Jeethu Rao]

Jeethu Rao  added the comment:

> FWIW, we've encountered a number of situations in the past when something 
> that improved the timings on one compiler would make timings worse on another 
> compiler.  There was also variance between timings on 32-bit builds versus 
> 64-bit builds.

I've verified that both clang and gcc generate similar assembly (memcpy is not 
inlined and the loop is not vectorized) 32-bit mode. I'd wager that the 
improvement with vectorization (in memmove) would be even more pronounced on 
32-bit systems, given that pointers are half the size and cache lines are still 
64 bytes wide.

> It's 1.08x faster (-7.8%). It's small for a microbenchmark, usually an 
> optimization should make a *microbenchmark* at least 10% faster.

That's true if we assume lists to have 100 or lesser elements. On the other 
hand, on the pyperformance comparison I'd posted yesterday[1], there seems to 
be an average improvement of 1.27x  on the first seven benchmarks, and the 
slowest slowdown is only 1.03x. Albeit, the improvement cannot be better than 
by a constant factor with the vectorized loop in memmove.

> Using memmove() for large copy is a good idea. The main question is the "if 
> (n <= INS1_MEMMOVE_THRESHOLD)" test. Is it slower if we always call memmove()?

The overhead of calling memmove makes it slower for small lists. That's how I 
arrived at this patch in the first place. I tried replacing the loop with a 
memmove() and it was slower on pyperformance and it was faster with switching 
to memmove() after a threshold.

> Previously, Python had a Py_MEMCPY() macro which also had such threshold. 
> Basically, it's a workaround for compiler performance issues:

That's very interesting! I think it boils down to the pointer aliasing problem. 
The pointers in memcpy()'s signature have the `restrict` qualifier, which gives 
the compiler more leeway to optimize calls to memcpy, while the compiler has to 
be more conservative with memmove(). I wonder if it's worth trying out a 
Py_MEMMOVE() :)


[1]: https://gist.github.com/jeethu/d6e4045f7932136548a806380eddd030

--

___
Python tracker 

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

[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv

[R. David Murray]

R. David Murray  added the comment:

This is sounds like a variation on issue 30811.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue32580] Fallback to dev_urandom doesn't work when py_getrandom returns -1

[Jernej Simončič]

New submission from Jernej Simončič :

I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying 
to compile Python 3.5.4, the build failed with "Fatal Python error: failed to 
get random numbers to initialize Python" (full details at 
https://forums.gentoo.org/viewtopic-p-8172124.html ).

glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 
(doesn't support getrandom).

Looking at random.c, pyurandom returns -1 instead of falling back to 
dev_urandom when py_getrandom returns -1, so the attached fix is simple.

--
components: Build
files: random_fallback.patch
keywords: patch
messages: 310158
nosy: jernejs
priority: normal
severity: normal
status: open
title: Fallback to dev_urandom doesn't work when py_getrandom returns -1
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47389/random_fallback.patch

___
Python tracker 

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

[issue19417] Bdb: add a unittest file (test.test_bdb)

[Xavier de Gaye]

Xavier de Gaye  added the comment:

PR 5217 adds the test.test_bdb module and provides a framework for adding more 
tests to the bdb module.

Added versions 3.6 and 2.7. This is consistent with what was done in issues 
#21916 and #25616 for example, but the main reason is that most bdb bug fixes 
need to be backported to the maintenance and 2.7 versions and should use the 
same test case whenever possible.

--
versions: +Python 2.7, Python 3.6

___
Python tracker 

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

[issue19417] Bdb: add a unittest file (test.test_bdb)

[Xavier de Gaye]

Change by Xavier de Gaye :


--
pull_requests: +5070

___
Python tracker 

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

[issue32576] concurrent.futures.thread potential deadlock due to Queue in weakref callback

[Antoine Pitrou]

Change by Antoine Pitrou :


--
keywords: +patch
pull_requests: +5069
stage: needs patch -> patch review

___
Python tracker 

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

[issue32576] concurrent.futures.thread potential deadlock due to Queue in weakref callback

[Antoine Pitrou]

Antoine Pitrou  added the comment:

We could also switch multiprocessing.Pool.  Unfortunately some code in 
multiprocessing.Pool relies on internal details of queue.Queue (!).

--

___
Python tracker 

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

[issue32536] ast and tokenize disagree about line number

[Nitish]

Nitish  added the comment:

What should happen ideally? The stray '\r' be treated like a whitespace?

--

___
Python tracker 

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

[issue32579] UUID module fix, uuid1 python module function

[David CARLIER]

New submission from David CARLIER :

Spotted to UUID unit tests https://bugs.python.org/issue32493

--
components: Library (Lib)
messages: 310154
nosy: David CARLIER2
priority: normal
pull_requests: 5068
severity: normal
status: open
title: UUID module fix, uuid1 python module function
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

[issue32571] Speed up and clean up getting optional attributes in C code

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Can I ask why this is a private API? It's extremely useful for extension 
modules too. For example, numpy has been carrying around a reimplementation of 
PyObject_GetAttr for years, exactly to avoid the cost of creating an 
AttributeError exception in common cases:

https://github.com/numpy/numpy/blob/master/numpy/core/src/private/get_attr_string.h

(To emphasize the similarity, note that the code above used to be called 
PyArray_GetAttrString_SuppressException, until a refactoring last year: 
https://github.com/numpy/numpy/commit/69a423b23492ecf8471efc4e59ab8a93b03d8454. 
It's always been specifically used for looking up numpy-specific special 
methods like __array__, __array_interface__, etc., though, which is why it can 
get away with those shortcuts -- we know they usually aren't defined.)

--
nosy: +njs

___
Python tracker 

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

[issue32248] Port importlib_resources (module and ABC) to Python 3.7

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +5067

___
Python tracker 

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

[issue32578] x86-64 Sierra 3.6: test_asyncio fails with timeout after 15 minutes

[STINNER Victor]

STINNER Victor  added the comment:

Maybe we should just give more time to this buildbot worker, extend the timeout 
to 30 minutes for example?

--
components: +Tests
nosy: +zach.ware
versions: +Python 3.6

___
Python tracker 

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

[issue32578] x86-64 Sierra 3.6: test_asyncio fails with timeout after 15 minutes

[STINNER Victor]

New submission from STINNER Victor :

test_asyncio started to fail at build 163:

http://buildbot.python.org/all/#/builders/20/builds/163
(...)
test_legacy_create_ssl_connection 
(test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_ssl_unix_connection 
(test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl 
(test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl_verified 
(test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl_verify_failed 
(test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_prompt_cancellation (test.test_asyncio.test_events.KqueueEventLoopTests) 
... ok
test_read_pipe (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
Timeout (0:15:00)!
Thread 0x7fffb5eee340 (most recent call first):
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/selectors.py", line 
577 in select
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py",
 line 1396 in _run_once
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py",
 line 422 in run_forever
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py",
 line 455 in run_until_complete
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py",
 line 1536 in test_read_pty_output
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py",
 line 555 in wrapper
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py",
 line 600 in wrapper
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py",
 line 2232 in test_read_pty_output
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py",
 line 600 in wrapper
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/case.py", 
line 605 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/case.py", 
line 653 in __call__
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 122 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", 
line 84 in __call__
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/runner.py",
 line 176 in run
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py",
 line 1887 in _run_suite
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py",
 line 1977 in run_unittest
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py",
 line 172 in test_runner
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py",
 line 173 in runtest_inner
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py",
 line 137 in runtest
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py",
 line 290 in rerun_failed_tests
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py",
 line 539 in _main
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py",
 line 509 in main
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py",
 line 584 in main
  File 
"/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/__main__.py", 
line 2 in 
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", 
line 85 in _run_code
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", 
line 193 in _run_module_as_main
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=2527.463349
test_read_pty_output (test.test_asyncio.test_events.KqueueEventLoopTests) ...

--
messages: 310151
nosy: vstinner
priority: 

[issue32226] Implement PEP 560: Core support for typing module and generic types

[STINNER Victor]

STINNER Victor  added the comment:

Oh ok, I think that I found the bug: PR 5212.

--

___
Python tracker 

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

[issue32226] Implement PEP 560: Core support for typing module and generic types

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +5066

___
Python tracker 

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

[issue32226] Implement PEP 560: Core support for typing module and generic types

[STINNER Victor]

STINNER Victor  added the comment:

Since the commit 45700fb757591a672e9d25b8252971c2a2caeaf2, test_genericclass 
leaks references:
---
vstinner@apu$ ./python -m test -R 3:3 test_genericclass -m 
test.test_genericclass.CAPITest.test_c_class
Run tests sequentially
0:00:00 load avg: 1.27 [1/1] test_genericclass
beginning 6 repetitions
123456
..
test_genericclass leaked [2, 3, 2] memory blocks, sum=7
test_genericclass failed

1 test failed:
test_genericclass

Total duration: 107 ms
Tests result: FAILURE
---

The leak comes from _testcapi.Generic[int]. Maybe from generic_alias_new() of 
Modules/_testcapi.c.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[David CARLIER]

David CARLIER  added the comment:

Might comes from uuid1 function itself ... e.g. line 704 not setting version 
"field".

--
nosy: +David CARLIER2

___
Python tracker 

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