[issue39085] Improve docs for await expression

[Kyle Stanley]

Kyle Stanley  added the comment:

> Sorry, my English is bad; I cannot help with docs too much.

No problem. Your feedback is still incredibly helpful and very much appreciated 
either way. (: 

> Anyway, technically an awaited coroutine *can* be suspended but the 
> suspension is not always necessary. The most deep awaited function decides.

Ah, I see. It took a bit of experimentation for me to understand how this 
works, but I think that I get it now. Specifically, the suspension occurs when 
the deepest coroutine function awaits an awaitable object and a `yield` is 
reached (usually through a defined __await__ method that returns an iterator). 
When that awaitable object is completed and returns, the coroutine function 
with the `await` (and everything else that directly awaited it) is resumed. A 
good example of this is `asyncio.sleep(0)`, as it just awaits `__sleep0()`, 
which is just a generator-based coroutine with a bare `yield`.

```
import asyncio
import inspect

tracked_coro = None

async def main():
  # loop isn't entirely needed, just used to track event loop time
  loop = asyncio.get_running_loop()
  global tracked_coro
  tracked_coro = coro(loop)
  await asyncio.gather(tracked_coro, other_coro(loop))


# This is the coroutine being tracked
async def coro(loop):
  print(loop.time())
  print("Start of coro():",
   inspect.getcoroutinestate(tracked_coro))
  await nested_coro(loop)


async def nested_coro(loop):
  print(loop.time())
  # coro() is not suspended yet, because we did not reach a `yield`
  print("Start of nested_coro():",
   inspect.getcoroutinestate(tracked_coro))
  # This will call await `__sleep0()`, reaching a `yield` which suspends 
`coro()` and `nested_coro()`
  await asyncio.sleep(0)
  print(loop.time())
  print("After the await, coro() is resumed:",
   inspect.getcoroutinestate(tracked_coro))


async def other_coro(loop):
  print(loop.time())
  print("Start of other_coro():",
   inspect.getcoroutinestate(tracked_coro))

asyncio.run(main())
```

Output:

```
8687.907528533
Start of coro(): CORO_RUNNING
8687.907800424
Start of nested_coro(): CORO_RUNNING
8687.912218812
Start of other_coro(): CORO_SUSPENDED
8687.912291694
After the await, coro() is resumed: CORO_RUNNING
```

> For example, if you want to read 16 bytes from a stream and these bytes are 
> already fetched there is no suspension at this point  (at least libraries are 
> designed in this way)

After realizing that the suspend only occurs when `yield` is reached, I think I 
understand how this works for `StreamReader.read()`. 

In sum, a `yield` is reached when `read()` is called with an empty buffer, 
resulting in `await self._wait_for_data('read')`. Specifically within 
`_wait_for_data()`, the `yield` is reached within `await self._waiter` (because 
_waiter is a Future, which defines an __await__ method with a `yield`). 
However, if `read()` is called after the bytes were fetched and are contained 
in the buffer, the bytes are read from the buffer and returned directly without 
ever reaching a `yield`; thus there is no suspension that occurs.

Is my interpretation mostly correct? I want to make sure that I have a good 
understanding of how await really works, as that will both help with improving 
the documentation of the await expression and improve my understanding of 
asyncio.

> Also, technical speaking about awaits is hard without telling that a 
> coroutine is a specialized version of generator object with (partially) 
> overlapped methods and properties, e.g. send() and throw().

Good point. If I understand correctly, send() and throw() were specifically 
added to the generator API in PEP 342 for the purpose of implementing 
coroutines in the first place, so it makes sense to explain how they relate to 
await. 

> To run a coroutine you need a framework which calls these methods depending 
> on the framework rules, the rules for asyncio are different from trio.

That's mainly why I added Nathaniel to the nosy list. I wanted to make sure 
that we describe the await expression in a way that's as accurate and 
informative as possible for both, as well as any other async library that uses 
await.

> Not sure how long should be the section but looking on `yield expressions` 
> https://docs.python.org/3/reference/expressions.html#yield-expressions above 
> I expect that awaits can take two-three times longer.

That would be a great goal to move towards, but I think that might have to be 
completed in multiple steps over a longer period of time rather than in a 
single change. Even if it ends up being not quite as long as 2-3 times the 
length of the reference for the yield expression, I think we can still make a 
substantial improvement to the existing version.

--

___
Python tracker 

___
___
Python-bugs-list mailing 

[issue39094] Add a default to statistics.mean and related functions

[Tal Einat]

Tal Einat  added the comment:

It seems to me that this would follow the same argument as in issue #18111: The 
real issue is that there's no good way to check if an arbitrary iterable is 
empty, unlike with sequences. Currently, callers need to wrap with try/except 
to handle empty iterators properly, or do non-trivial iterator "magic" to check 
whether the iterator is empty before passing it in.

I've tried think of other solutions, such as a generic wrapper for such 
functions or a helper to check whether an iterable is empty, and they all turn 
out to be very clunky to use and un-Pythonic.

Since we provide first-class support for iterators, and many builtins return 
iterators, giving the tools to handle the case where they are empty elegantly 
and simply seems prudent.

--

___
Python tracker 

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

[issue39094] Add a default to statistics.mean and related functions

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I vote -1.  We don't have defaults for stdev() or median() or mode().  And it 
isn't clear what one would use for a meaningful default value in most cases.  
Also, I'm not seeing anything like this in Pandas, Excel, etc.  So, I recommend 
keeping the current simple and clean APIs.

--

___
Python tracker 

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

[issue39093] tkinter objects garbage collected from non-tkinter thread cause panic and core dump

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


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

[issue39095] Negative Array Index not Yielding "Index Out Of Bounds"

[NNN]

NNN  added the comment:

Ahh, thanks.

--

___
Python tracker 

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

[issue37218] Default hmac.new() digestmod has not been removed from documentation

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue39091] CPython Segfault in 5 lines of code

[Noah]

Change by Noah :


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

___
Python tracker 

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

[issue39095] Negative Array Index not Yielding "Index Out Of Bounds"

[Zachary Ware]

Zachary Ware  added the comment:

`-1` is not out of bounds unless the array is empty; negative indices count 
from the other end:

>>> a = list("some array")
>>> a
['s', 'o', 'm', 'e', ' ', 'a', 'r', 'r', 'a', 'y']
>>> a[-1]
'y'
>>> b = []
>>> b[-1]
Traceback (most recent call last):
  File "", line 1, in 
IndexError: list index out of range



See about halfway down this [1] section; look for "Indices may also be 
negative".

[1] 
https://docs.python.org/3/tutorial/introduction.html?highlight=Indices+negative+numbers#strings

--
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue39095] Negative Array Index not Yielding "Index Out Of Bounds"

[NNN]

New submission from NNN :

Created an 2D array:
bigFloorLayout = []   
bigFloorLayout=[[False for row in range(0,45] for col in range(0,70]


for y in range (offsetY, storageY + offsetY):
for x in range (offsetX, storageX + offsetX):
bigFloorLayout[x][y] = True

Offset is a negative number, and thus accessing bigFloorLayout[0][-1], which 
did not yield "Index out of Bounds" as it should.
This is in Blender 2.81, so I have no idea what version of python it is.

--
messages: 358655
nosy: NNN
priority: normal
severity: normal
status: open
title: Negative Array Index not Yielding "Index Out Of Bounds"
type: behavior

___
Python tracker 

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

[issue39093] tkinter objects garbage collected from non-tkinter thread cause panic and core dump

[obserience]

obserience  added the comment:

A quick google search for "Tcl_AsyncDelete: async handler deleted by the wrong 
thread" yields plenty of users complaining about this error case. Usually 
they're trying add a gui to an existing application. They run it in a thread 
other than main and then leak a reference to a GUI widget into another thread. 
The GUI exits and then some time later, the last reference to a widget 
dissapears but this is triggered by the leaked reference and occurs in another 
thread context. The TK library panics and the application crashes.

https://github.com/matplotlib/matplotlib/issues/12085
https://github.com/gboeing/osmnx/issues/75
https://stackoverflow.com/questions/27073762/tcl-asyncdelete-error-multithreading-python
(and so on)

The response time and time again is just "you can't run tkinter in any thread 
but main". Hopefully if this fix is implemented, that becomes less true.

--

___
Python tracker 

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

[issue39094] Add a default to statistics.mean and related functions

[Yoni Lavi]

Change by Yoni Lavi :


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

___
Python tracker 

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

[issue39094] Add a default to statistics.mean and related functions

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +rhettinger, steven.daprano, taleinat

___
Python tracker 

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

[issue39094] Add a default to statistics.mean and related functions

[Yoni Lavi]

New submission from Yoni Lavi :

I would like to put forward an argument in favour of a `default` parameter in 
the statistics.mean function and the related function. 

What motivated me to open this is that my code would more often than not 
include a check (or try-except) whenever I calculate a mean and add a 
default/sentinel value, and I felt that there should be a better way.

Please also note that we have a precedent for this in a similar parameter added 
to min & max in 3.4 (https://bugs.python.org/issue18111)

--
components: Library (Lib)
messages: 358653
nosy: Yoni Lavi
priority: normal
severity: normal
status: open
title: Add a default to statistics.mean and related functions
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue39093] tkinter objects garbage collected from non-tkinter thread cause panic and core dump

[obserience]

New submission from obserience :

All tkinter objects have a reference to the TCL interpreter object "self.tk". 
The current cleanup code does not remove these when a widget is destroyed.

Garbage collection of the TCL interpreter object occurs only after all gui 
objects are garbage collected. This may  be triggered from another thread 
causing TCL to panic and trigger a core dump.

Error message:
>Tcl_AsyncDelete: async handler deleted by the wrong thread
>Aborted (core dumped)

Adding:
"self.tk = None"
to the end of Misc.destroy() (tkinter/__init__.py line:439) should fix this by 
removing these reference when widgets are destroyed. (Note:destroy is recursive 
on the widget tree and called on the root object when a Tkinter GUI exits)

I can't see any problem with removing the interpreter object from a widget when 
it is destroyed. There doesn't seem to be any way to reassign a widget to a new 
parent so this shouldn't affect anything.

Doing this makes it safe(r) to use tkinter from a non-main thread since if the 
GUI cleans up properly no "landmines" are left to cause a crash when garbage 
collected in the wrong thread.

--
components: Tkinter
files: error_case.py
messages: 358652
nosy: obserience
priority: normal
severity: normal
status: open
title: tkinter objects garbage collected from non-tkinter thread cause panic 
and core dump
type: crash
Added file: https://bugs.python.org/file48789/error_case.py

___
Python tracker 

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

[issue38295] test_relative_path of test_py_compile fails on macOS 10.15 Catalina

[Ned Deily]

Ned Deily  added the comment:


New changeset 13ee023c03caf85101778b9323cdffbad695a4e0 by Ned Deily (Miss 
Islington (bot)) in branch '3.7':
bpo-38295: prevent test_relative_path of test_py_compile failure on macOS 
Catalina (GH-17636)
https://github.com/python/cpython/commit/13ee023c03caf85101778b9323cdffbad695a4e0


--

___
Python tracker 

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

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

[Ned Deily]

Ned Deily  added the comment:


New changeset 9af497419540cdb4659927e66c67d861c5ea48c2 by Ned Deily (Inada 
Naoki) in branch '3.7':
bpo-39035: travis: Don't use beta group (GH-17604)
https://github.com/python/cpython/commit/9af497419540cdb4659927e66c67d861c5ea48c2


--

___
Python tracker 

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

[issue1298835] Add a vendor-packages directory for system-supplied modules

[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

[issue1116520] Prefix search is filesystem-centric

[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

[issue39091] CPython Segfault in 5 lines of code

[Noah]

Noah  added the comment:

I'm not sure if this will actually appear as a message (I just registered for 
the bug tracker and I'm not sure how it works), but I wrote the gist and I can 
definitely make a PR.

--
nosy: +coolreader18

___
Python tracker 

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

[issue39070] Uninstalling 3.8.0 fails but it says it succeeds..

[tuijatuulia]

tuijatuulia  added the comment:

alright have some, I'll just put them here, I guess nothing secret there. There 
are quite many of those - and also log files say it is uninstalling properly 
but no, it did not disappear from Windows / Programs or files did not go 
anywhere, also when I rebooted. Only when I added privileges to user I was able 
to uninstall properly. (and it did ask for privileges, so I did not suspect 
anything before noticing that hey it did not uninstall)

I have also other log files that have additional name JustForMe

--
Added file: https://bugs.python.org/file48788/Python 3.8.0 
(32-bit)_20191217003514.log

___
Python tracker 

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

[issue37193] Memory leak while running TCP/UDPServer with socketserver.ThreadingMixIn

[Martin Panter]

Martin Panter  added the comment:

FTR I have been trialling a patched Python 3.7 based on Maru's changes 
(revision 6ac217c) + review suggestions, and it has reduced the size of the 
leak (hit 1 GB over a couple days, vs only 60 MB increase over three days). The 
remaining leak could be explained by Issue 37788.

--

___
Python tracker 

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

[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

[Martin Panter]

Change by Martin Panter :


--
nosy: +martin.panter

___
Python tracker 

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

[issue900092] hotshot.stats.load fails with AssertionError

[SilentGhost]

Change by SilentGhost :


--
resolution:  -> out of date
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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[miss-islington]

miss-islington  added the comment:


New changeset b8bbdf049b0472b8edc4298bfa61e62e3a584e98 by Miss Islington (bot) 
in branch '3.7':
bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652) 
(GH-17655)
https://github.com/python/cpython/commit/b8bbdf049b0472b8edc4298bfa61e62e3a584e98


--
nosy: +miss-islington

___
Python tracker 

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

[issue39092] Csv sniffer doesn't attempt to determine and set escape character.

[Evan]

New submission from Evan :

I observed a false positive for the csv sniffer has_header method. (It thought 
there was a header when there was not.) This is due to the fact that in 
has_header, it determines the csv dialect by sniffing it, and failed to 
determine that the file I was using had an escape character of '\'. Since it 
doesn't set the escape character, it then incorrectly broke the first line of 
the file into columns, since it encountered an escaped quote within a quoted 
column, and treated that as the end of that column. (It correctly determined 
that the dialect wasn't doublequote, but apparently still needs to have the 
escape character set to handle an escaped quotechar.) 

I think one (or both) of these things should be done here to avoid this false 
positive:
1.) Allow a dialect to be passed to has_header, so that someone could specify 
the escape character of the dialect if it were known.
2.) Allow the sniff method of the Sniffer class to detect and set the 
escapechar.

--
components: Library (Lib)
messages: 358645
nosy: evan.whitfield
priority: normal
severity: normal
status: open
title: Csv sniffer doesn't attempt to determine and set escape character.
type: 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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

STINNER Victor  added the comment:


New changeset b0eb046cbd0dbb7b17f16aad6de20fac5305f387 by Victor Stinner in 
branch '3.8':
bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652) 
(GH-17655)
https://github.com/python/cpython/commit/b0eb046cbd0dbb7b17f16aad6de20fac5305f387


--

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[miss-islington]

Change by miss-islington :


--
pull_requests: +17123
pull_request: https://github.com/python/cpython/pull/17656

___
Python tracker 

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

[issue900092] hotshot.stats.load fails with AssertionError

[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

[issue39091] CPython Segfault in 5 lines of code

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Good catch! Since you already investigated the code, do you mind to create a PR 
which fixes a crash? I think that adding PyExceptionInstance_Check() in 
_PyErr_CreateException() could fix the issue.

--

___
Python tracker 

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

[issue39091] CPython Segfault in 5 lines of code

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29688] Add support for Path.absolute()

[Brett Cannon]

Brett Cannon  added the comment:

I have opened https://bugs.python.org/issue39090 to track updating the pathlib 
docs to have a section on getting the absolute path in various ways along with 
what the trade-offs are for each approach.

--

___
Python tracker 

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

[issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

[Adam]

Adam  added the comment:

I ran into this bug as well, and opened an issue for it (before I saw this 
issue): https://bugs.python.org/issue39074

Was there a conclusion on the best way to fix this? It seems like the previous 
__del__ implementation would correct the resource leakage by removing the 
_tstate_lock from _shutdown_locks.

--
nosy: +krypticus

___
Python tracker 

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

[issue39091] CPython Segfault in 5 lines of code

[Christian Heimes]

Christian Heimes  added the comment:

I can reproduce the issue on master:

>>> class E(BaseException):
... def __new__(cls, *args, **kwargs):
... return cls
... 
>>> def a(): yield
... 
>>> a().throw(E)

Program received signal SIGSEGV, Segmentation fault.
_Py_DECREF (op=, lineno=541, filename=0x61717f 
"./Include/object.h") at ./Include/object.h:470
470 if (--op->ob_refcnt != 0) {
(gdb) bt
#0  _Py_DECREF (op=, lineno=541, filename=0x61717f 
"./Include/object.h") at ./Include/object.h:470
#1  _Py_XDECREF (op=) at ./Include/object.h:541
#2  BaseException_set_tb (self=0x837290, tb=, _unused_ignored=_unused_ignored@entry=0x0) at 
Objects/exceptions.c:234
#3  0x004335bd in PyException_SetTraceback (self=, 
tb=) at Objects/exceptions.c:319
#4  0x0051b6df in _PyErr_PrintEx (tstate=0x78c7c0, 
set_sys_last_vars=set_sys_last_vars@entry=1) at Python/pythonrun.c:680
#5  0x0051bc1f in PyErr_PrintEx 
(set_sys_last_vars=set_sys_last_vars@entry=1) at Python/pythonrun.c:763
#6  0x0051bc32 in PyErr_Print () at Python/pythonrun.c:769
#7  0x0051ca1e in PyRun_InteractiveLoopFlags 
(fp=fp@entry=0x77de07e0 <_IO_2_1_stdin_>, 
filename_str=filename_str@entry=0x617126 "", 
flags=flags@entry=0x7fffd7f0) at Python/pythonrun.c:135
#8  0x0051d0d0 in PyRun_AnyFileExFlags (fp=0x77de07e0 
<_IO_2_1_stdin_>, filename=filename@entry=0x617126 "", 
closeit=closeit@entry=0, flags=flags@entry=0x7fffd7f0) at 
Python/pythonrun.c:80
#9  0x0041deda in pymain_run_stdin (config=config@entry=0x78b0e0, 
cf=cf@entry=0x7fffd7f0) at Modules/main.c:467
#10 0x0041ea37 in pymain_run_python 
(exitcode=exitcode@entry=0x7fffd82c) at Modules/main.c:556
#11 0x0041ea76 in Py_RunMain () at Modules/main.c:632
#12 0x0041eacb in pymain_main (args=args@entry=0x7fffd870) at 
Modules/main.c:662
#13 0x0041eb47 in Py_BytesMain (argc=, argv=) at Modules/main.c:686
#14 0x0041d6df in main (argc=, argv=) at 
./Programs/python.c:16

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

___
Python tracker 

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

[issue39091] CPython Segfault in 5 lines of code

[Sebastian Krause]

New submission from Sebastian Krause :

The following lines trigger a segmentation fault:

class E(BaseException):
def __new__(cls, *args, **kwargs):
return cls
def a(): yield
a().throw(E)

Source with a bit more explanation: 
https://gist.github.com/coolreader18/6dbe0be2ae2192e90e1a809f1624c694 (I'm not 
the author of that gist, just reporting it here).

--
components: Interpreter Core
messages: 358639
nosy: skrause
priority: normal
severity: normal
status: open
title: CPython Segfault in 5 lines of code
type: crash
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue39090] Document various options for getting the absolute path from pathlib.Path objects

[Brett Cannon]

New submission from Brett Cannon :

The question on how best to get an absolute path from a pathlib.Path object 
keeps coming up (see https://bugs.python.org/issue29688, 
https://discuss.python.org/t/add-absolute-name-to-pathlib-path/2882/, and 
https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573 as examples).

As pointed out across those posts, getting the absolute path is surprisingly 
subtle and varied depending on your needs. As such we should probably add a 
section somewhere in the pathlib docs explaining the various ways and why you 
would choose one over the other.

--
assignee: docs@python
components: Documentation
messages: 358638
nosy: brett.cannon, docs@python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document various options for getting the absolute path from pathlib.Path 
objects
type: enhancement

___
Python tracker 

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

[issue39081] pathlib '/' operator does not resolve Enums with str mixin as expected

[Ethan Furman]

Ethan Furman  added the comment:

The other option is to continue to inherit from `str`, but override the 
`__str__` method:

class MyEnum(str, enum.Enum):
#
def __str__(self):
return self.value

--

___
Python tracker 

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

[issue39089] Update IDLE's credits

[Tal Einat]

New submission from Tal Einat :

The "Credits" document in the "About" dialog could use some updating. It fails 
to mention Saimadhav Heblikar's important work during GSoC 2014 as well as 
Terry J. Reedy's tireless work over the past few years which has helped keep 
IDLE in working order and the codebase in reasonable shape given its age.

--
assignee: terry.reedy
components: IDLE
messages: 358636
nosy: taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: Update IDLE's credits
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

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

[issue39014] test_concurrent_futures: test_crash() timed out on AMD64 Fedora Rawhide Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Another timeout on AMD64 Fedora Rawhide LTO + PGO 3.7:
https://buildbot.python.org/all/#/builders/63/builds/21

test_all_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 
0.14s ok
Timeout (0:15:00)!
Thread 0x7f4983fff700 (most recent call first):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 296 in wait
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/multiprocessing/queues.py",
 line 224 in _feed
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 870 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 926 in _bootstrap_inner
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 890 in _bootstrap

Thread 0x7f49a337e700 (most recent call first):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/selectors.py",
 line 415 in select
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/multiprocessing/connection.py",
 line 920 in wait
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/concurrent/futures/process.py",
 line 361 in _queue_management_worker
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 870 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 926 in _bootstrap_inner
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 890 in _bootstrap

Thread 0x7f49b192f740 (most recent call first):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py",
 line 296 in wait
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/concurrent/futures/_base.py",
 line 430 in result
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_concurrent_futures.py",
 line 147 in _prime_executor
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_concurrent_futures.py",
 line 125 in setUp
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/case.py",
 line 624 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/case.py",
 line 676 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/runner.py",
 line 176 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/support/__init__.py",
 line 1919 in _run_suite
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/support/__init__.py",
 line 2015 in run_unittest
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_concurrent_futures.py",
 line 1245 in test_main
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/support/__init__.py",
 line 2147 in decorator
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py",
 line 234 in _runtest_inner2
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py",
 line 270 in _runtest_inner
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py",
 line 154 in _runtest
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py",
 line 193 in runtest
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/main.py",
 line 313 in rerun_failed_tests
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/main.py",
 line 685 in _main
  File 

[issue39088] test_concurrent_futures crashed with python.core core dump on AMD64 FreeBSD Shared 3.x

[STINNER Victor]

New submission from STINNER Victor :

Yesterday and today, I pushed two test_concurrent_futures fixes in bpo-38546:

* commit 673c39331f844a80c465efd7cff88ac55c432bfb
* commit 9707e8e22d80ca97bf7a9812816701cecde6d226

Maybe it fixed this crash, maybe not.

https://buildbot.python.org/all/#/builders/152/builds/70

0:19:28 load avg: 4.96 [242/420/1] test_concurrent_futures failed (env changed) 
(5 min 4 sec) -- running: test_io (2 min 1 sec), test_largefile (31.3 sec)
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_already_successful 
(test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises_already_succeeded 
(test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_multiple_set_exception (test.test_concurrent_futures.FutureTests) ... ok
test_multiple_set_result (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_correct_timeout_exception_msg 
(test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.35s ok
test_duplicate_futures 
(test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 2.40s ok
test_free_reference_yielded_future 
(test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.37s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) 
... 0.24s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) 
... 2.40s ok
test_crash (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) 
... 1.12s ok
test_shutdown_deadlock 
(test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 0.57s ok
test_initializer 
(test.test_concurrent_futures.ProcessPoolForkFailingInitializerTest) ... 0.19s 
ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkInitializerTest) 
... 0.26s ok
test_free_reference 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.50s 
ok
test_killed_child 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.25s 
ok
test_map (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) 
... 0.37s ok
test_map_chunksize 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.40s 
ok
test_map_exception 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.58s 
ok
test_map_timeout 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 6.42s 
ok
test_max_workers_negative 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.32s 
ok
test_max_workers_too_large 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 
skipped 'Windows-only process limit'
test_no_stale_references 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.31s 
ok
test_ressources_gced_in_workers 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.86s 
ok
test_shutdown_race_issue12456 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.69s 
ok
test_submit 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.51s 
ok
test_submit_keyword 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s 
ok
test_traceback 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.18s 
ok
test_context_manager_shutdown 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.06s 
ok
test_del_shutdown 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.07s 
ok
test_hang_issue12364 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 1.22s 
ok
test_interpreter_shutdown 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 2.13s 
ok
test_processes_terminate 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.05s 
ok
test_run_after_shutdown 

[issue39081] pathlib '/' operator does not resolve Enums with str mixin as expected

[Brett Cannon]

Brett Cannon  added the comment:

Karthikeyan is right and this is working as expected. If you want the semantics 
you're after you can either implement __fspath__ as was suggested or get the 
'value' attribute of the enum when constructing your path.

--
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue39014] test_concurrent_futures: test_crash() timed out on AMD64 Fedora Rawhide Refleaks 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Another issue on AMD64 Fedora Rawhide Refleaks 3.7 where test_map_chunksize() 
hangs.

https://buildbot.python.org/all/#/builders/133/builds/18

(...)
test_initializer (test.test_concurrent_futures.ProcessPoolForkInitializerTest) 
... 0.13s ok
test_free_reference 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.17s 
ok
test_killed_child 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.15s 
ok
test_map (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) 
... 0.17s ok
.Timeout (3:15:00)!
Thread 0x7f095aa00700 (most recent call first):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 296 in wait
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/queues.py",
 line 224 in _feed
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 870 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 926 in _bootstrap_inner
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 890 in _bootstrap

Thread 0x7f095a1ff700 (most recent call first):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/selectors.py",
 line 415 in select
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/connection.py",
 line 920 in wait
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py",
 line 361 in _queue_management_worker
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 870 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 926 in _bootstrap_inner
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 890 in _bootstrap

Thread 0x7f096a552740 (most recent call first):
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py",
 line 296 in wait
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/_base.py",
 line 430 in result
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/_base.py",
 line 598 in result_iterator
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py",
 line 483 in _chain_from_iterable_of_lists
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py",
 line 782 in test_map_chunksize
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py",
 line 628 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py",
 line 676 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py",
 line 122 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py",
 line 84 in __call__
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/runner.py",
 line 176 in run
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py",
 line 1919 in _run_suite
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py",
 line 2015 in run_unittest
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py",
 line 1245 in test_main
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py",
 line 2147 in decorator
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/refleak.py",
 line 87 in dash_R
  File 
"/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py",
 line 232 in _runtest_inner2
  File 

[issue39070] Uninstalling 3.8.0 fails but it says it succeeds..

[Steve Dower]

Steve Dower  added the comment:

It will be in your user TEMP directory: C:\Users\\AppData\Local\Temp (or 
just type "%TEMP%" into the File Explorer address bar and it will take you 
there)

They should all start with "Python" and end with ".log" (or be marked as text 
files if you don't see the extension).

--

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

Change by STINNER Victor :


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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

STINNER Victor  added the comment:

> bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652)

I tested manually on the RHEL8 worker and I confirm that this change prevents 
the reap_children() warning.

I close the issue. The change will be shortly backported to 3.7 and 3.8.

--

I'm not sure if PR 17640 is useful, let's discuss it on the PR directly.

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

[issue39077] Numeric formatting inconsistent between int, float and Decimal

[Michael Amrhein]

Michael Amrhein  added the comment:

Mark, Eric,
sometimes the pressure to be backwards compatible is more of a curse than a 
blessing. But I can live with your decision.
And, yes, I will create two separate issues regarding the docs.

--

___
Python tracker 

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

[issue39070] Uninstalling 3.8.0 fails but it says it succeeds..

[tuijatuulia]

tuijatuulia  added the comment:

Thank you for the suggestion - I did not find any python-related log files in 
Windows /Temp - is there some identification I could search for?

--

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +17122
pull_request: https://github.com/python/cpython/pull/17655

___
Python tracker 

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

[issue39087] [C API] No efficient C API to get UTF-8 string from unicode object.

[STINNER Victor]

Change by STINNER Victor :


--
title: No efficient API to get UTF-8 string from unicode object. -> [C API] No 
efficient C API to get UTF-8 string from unicode object.

___
Python tracker 

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

[issue39087] No efficient API to get UTF-8 string from unicode object.

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[miss-islington]

Change by miss-islington :


--
pull_requests: +17121
pull_request: https://github.com/python/cpython/pull/17654

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 673c39331f844a80c465efd7cff88ac55c432bfb by Victor Stinner in 
branch 'master':
bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652)
https://github.com/python/cpython/commit/673c39331f844a80c465efd7cff88ac55c432bfb


--

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[miss-islington]

Change by miss-islington :


--
pull_requests: +17120
pull_request: https://github.com/python/cpython/pull/17653

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +17119
pull_request: https://github.com/python/cpython/pull/17652

___
Python tracker 

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

[issue33961] Inconsistency in exceptions for dataclasses.dataclass documentation

[Fabio Sangiovanni]

Fabio Sangiovanni  added the comment:

Hi,

I was looking at the dataclasses docs and it seems to me that the PR associated 
to this issue has been merged into 3.7 only, but should be backported to 3.8 
and to master.

I will post a comment on the PR itself as well.

Thanks,

Fabio

--
nosy: +sanjioh

___
Python tracker 

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

[issue39086] Division "/" error on Long Integers

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Looking at your first example, you calculate:

   >>> 63945173192649609/13
   4918859476357662.0


which is correct when using floats (64-bit C doubles). 64 bits are not enough 
to be any more precise, and you would get the same result in C or any other 
language using the same precision.

Using Decimal with the default precision, you could get:

>>> decimal.Decimal(63945173192649609)/13
Decimal('4918859476357662.230769230769')

but the exact result is 4918859476357662.[230769] where the decimal part inside 
the square brackets [...] repeats forever.

So within the limitations of the C 64-bit double floating point format, the 
calculation is correct and there is no bug here.

Please see

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

for more information.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue39086] Division "/" error on Long Integers

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Please don't post unnecessary screen shots of text. They are impossible for us 
to copy your code, we have to re-type it from scratch, and retyping 17-digit 
numbers is prone to typos. Screenshots make it difficult or impossible for the 
blind and visually impaired, who may be using screen readers, to contribute. 
Please copy and paste the actual text of your code, the results and the 
expected values.

You say you tested the values with a calculator, but which calculator and how 
do you know it is accurate?

I can't work out the connection between the competition and your calculations. 
Clicking on the "Problem" link takes me to a problem about dice.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue39087] No efficient API to get UTF-8 string from unicode object.

[Inada Naoki]

New submission from Inada Naoki :

Assume you are writing an extension module that reads string.  For example, 
HTML escape or JSON encode.

There are two courses:

(a) Support three KINDs in the flexible unicode representation.
(b) Get UTF-8 data from the unicode.

(a) will be the fastest on CPython, but there are few drawbacks:

 * This is tightly coupled with CPython implementation.  It will be slow on 
PyPy.
 * CPython may change the internal representation to UTF-8 in the future, like 
PyPy.
 * You can not easily reuse algorithms written in C that handle `char*`.

So I believe (b) should be the preferred way.
But CPython doesn't provide an efficient way to get UTF-8 from the unicode 
object.

 * PyUnicode_AsUTF8AndSize(): When the unicode contains non-ASCII character, it 
will create a UTF-8 cache.  The cache will be remained for longer than 
required.  And there is additional malloc + memcpy to create the cache.

 * PyUnicode_DecodeUTF8(): It creates bytes object even when the unicode object 
is ASCII-only or there is a UTF-8 cache already.

For speed and efficiency, I propose a new API:

```
  /* Borrow the UTF-8 C string from the unicode.
   *
   * Store a pointer to the UTF-8 encoding of the unicode to *utf8* and its 
size to *size*.
   * The returned object is the owner of the *utf8*.  You need to Py_DECREF() 
it after
   * you finished to using the *utf8*.  The owner may be not the unicode.
   * Returns NULL when the error occurred while decoding the unicode.
   */
  PyObject* PyUnicode_BorrowUTF8(PyObject *unicode, const char **utf8, 
Py_ssize_t *len);
```

When the unicode object is ASCII or has UTF-8 cache, this API increment refcnt 
of the unicode and return it.
Otherwise, this API calls `_PyUnicode_AsUTF8String(unicode, NULL)` and return 
it.

--
components: C API
messages: 358623
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: No efficient API to get UTF-8 string from unicode object.
type: enhancement
versions: Python 3.9

___
Python tracker 

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

[issue39086] Division "/" error on Long Integers

[Mradul Tiwari]

New submission from Mradul Tiwari :

I'm a Competitive programmer and got Wrong Answer because of this division 
issue, which I figured out post Contest. Please See the attached screenshot.

The "/" operator gives float division but for long integers, it's giving 
integer answer. I've tested it on several values but the result doesn't matched 
with expected answers. I've also googled a lot about this but can't get the 
explanation.

Please go to link "https://codeforces.com/contest/1266/submission/67106918;
and see the actual arise of problem on SEVERAL VALUES, in detail section, in 
TestCase 3 which have very large integers.

In my code at that link, the error arises inside the function get(x) at line 
"c=(x-i)/14"

--
assignee: docs@python
components: Documentation
files: Tested values.png
messages: 358622
nosy: Mradul, docs@python
priority: normal
severity: normal
status: open
title: Division "/" error on Long Integers
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48787/Tested values.png

___
Python tracker 

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

[issue39085] Improve docs for await expression

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Thanks for raising the very interesting question!

Sorry, my English is bad; I cannot help with docs too much.

Anyway, technically an awaited coroutine *can* be suspended but the suspension 
is not always necessary. The most deep awaited function decides. 

For example, if you want to read 16 bytes from a stream and these bytes are 
already fetched there is no suspension at this point  (at least libraries are 
designed in this way usually).

Also, technical speaking about awaits is hard without telling that a coroutine 
is a specialized version of generator object with (partially) overlapped 
methods and properties, e.g. send() and throw().

To run a coroutine you need a framework which calls these methods depending on 
the framework rules, the rules for asyncio are different from trio.

Not sure how long should be the section but looking on `yield expressions` 
https://docs.python.org/3/reference/expressions.html#yield-expressions above I 
expect that awaits can take two-three times longer.

--

___
Python tracker 

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

[issue39077] Numeric formatting inconsistent between int, float and Decimal

[Eric V. Smith]

Eric V. Smith  added the comment:

I agree with your approach, Mark.

And Michael: thanks for your report on the C behavior. I just wish we'd thought 
to look at this 13 years ago when .format() was being discussed.

--

___
Python tracker 

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

[issue39077] Numeric formatting inconsistent between int, float and Decimal

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, Eric. I'm now convinced that we shouldn't weaken the Decimal behaviour, 
and I agree that it's risky to change the float and int behaviour. So it's 
sounding as though we're looking at a "won't fix" resolution here.

There are still the documentation issues: the trailing ".0" and the 6-digits 
after the point for "f" with no precision. Michael: would you be willing to 
open a separate bug report for those? (It's awkward to track two different 
issues, potentially needing different resolutions, in a single bugs.python.org 
issue.)

--

___
Python tracker 

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

[issue24416] Have date.isocalendar() return a structseq instance

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +17118
pull_request: https://github.com/python/cpython/pull/17651

___
Python tracker 

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

[issue39082] AsyncMock is unable to correctly patch static or class methods

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Found Raymond's answer on the difference between __dict__ and attribute lookup 
regarding descriptors to be useful here : https://stackoverflow.com/a/44600603

--

___
Python tracker 

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

[issue38546] test_concurrent_futures: reap_children() warnings on RHEL7 and RHEL8 buildbots

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 35acb3597208e10a101140474adec86859d57f61 by Victor Stinner in 
branch '3.8':
bpo-38546: multiprocessing tests stop the resource tracker (GH-17641) (GH-17647)
https://github.com/python/cpython/commit/35acb3597208e10a101140474adec86859d57f61


--

___
Python tracker 

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

[issue34480] _markupbase.py fails with UnboundLocalError on invalid keyword in marked section

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Attaching a test case for this issue since the self.error code path was not 
covered in the current test suite. A PR is open proposing match variable 
initialisation with None https://github.com/python/cpython/pull/17643 .

diff --git Lib/test/test_htmlparser.py Lib/test/test_htmlparser.py
index a2bfb39d16..a9aff11706 100644
--- Lib/test/test_htmlparser.py
+++ Lib/test/test_htmlparser.py
@@ -766,6 +766,18 @@ class AttributesTestCase(TestCaseBase):
   [("href", "http://www.example.org/\";>;")]),
  ("data", "spam"), ("endtag", "a")])
 
+def test_invalid_keyword_error_exception(self):
+class InvalidMarkupException(Exception):
+pass
+
+class MyHTMLParser(html.parser.HTMLParser):
+
+def error(self, message):
+raise InvalidMarkupException(message)
+
+parser = MyHTMLParser()
+with self.assertRaises(InvalidMarkupException):
+parser.feed('')
 
 if __name__ == "__main__":
 unittest.main()

--
nosy: +xtreak

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