[issue2771] Test issue

[Berker Peksag]

Change by Berker Peksag :


--
nosy: +berker.peksag, brett.cannon
nosy_count: 8.0 -> 10.0
pull_requests: +17979
pull_request: https://github.com/python/cpython/pull/18614

___
Python tracker 

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

[issue2771] Test issue

[Berker Peksag]

Change by Berker Peksag :


--
nosy:  -brett.cannon

___
Python tracker 

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

[issue38035] shared_semaphores cannot be shared across unrelated processes

[Tal Einat]

Tal Einat  added the comment:

I'm not convinced there is enough real need for this to justify implementing 
and supporting it.

Using shared memory wouldn't be possible with built-in Python objects; one 
would have to use a special-purpose library for this, or perhaps use something 
like ctypes. It seems to me that in any case, once someone is doing those, they 
might as well use those same tools to also create and manage shared resources 
such as shared memory.

Therefore, even if we allow creating such shared resources, it doesn't seem to 
me that they will be very usable without a lot of extra supporting features.

In other words, I'd like to see at least one convincing use-case for this 
before considering any implementation.

--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[hai shi]

Change by hai shi :


--
pull_requests: +17978
pull_request: https://github.com/python/cpython/pull/18613

___
Python tracker 

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

[issue39725] unrelated `from None` exceptions lose prior exception information

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

For reference: PEP 3134 (and superseded PEP 344), PEP 409, PEP 415.

--

___
Python tracker 

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

[issue39727] cgi.parse() fatally attempts str.decode when handling multipart/form-data

[James Edington]

James Edington  added the comment:

Here is a file to try it out in an instant.

(lines 11–28 are not necessary; they are just "luxuries" allowing easier 
testing of the issue in a web browser)

--
Added file: https://bugs.python.org/file48903/demo.py

___
Python tracker 

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

[issue39727] cgi.parse() fatally attempts str.decode when handling multipart/form-data

[James Edington]

New submission from James Edington :

It appears that cgi.parse() in Python 3.7.6 [GCC 9.2.1 20190827 (Red Hat 
9.2.1-1)] fatally chokes on POST requests with multipart/form-data due to some 
internal processing still relying on assumptions from when str and bytes were 
the same object.

I'll attach as the first comment the "try-it-at-home" file to demonstrate this 
error.

--
components: Library (Lib)
files: curlLogs.txt
messages: 362490
nosy: James Edington
priority: normal
severity: normal
status: open
title: cgi.parse() fatally attempts str.decode when handling multipart/form-data
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48902/curlLogs.txt

___
Python tracker 

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

[issue39726] ctypes on pypi has fallen behind

[Ammar Askar]

Ammar Askar  added the comment:

The ctypes on pypi is no longer maintained as it was merged by the original 
author Thomas Heller into python itself. 

This article goes over the history of it a little: 
https://blog.python.org/2011/04/thomas-heller-steps-down-as-ctypes.html

Why do you need the pypi version to be updated? You should just be able to 
import ctypes in your venv and have it use the one included in the standard 
library.

--
nosy: +ammar2

___
Python tracker 

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

[issue33840] connection limit on listening socket in asyncio

[Fantix King]

Change by Fantix King :


--
nosy: +fantix

___
Python tracker 

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

[issue39726] ctypes on pypi has fallen behind

[David Harding]

New submission from David Harding :

I wasn't sure where to report this.

ctypes currently bundled with Ubuntu 16.04 and 18.04 is version 1.1.0.

ctypes available through pypi is 1.0.2.

https://pypi.org/project/ctypes/

This makes maintaining a reproducible environment with venv kind of tricky. It 
would be desirable to catch the pypi version up to 1.1.0.

I don't really know who to bother about this, so I'm starting here.

Thanks!

--
components: ctypes
messages: 362488
nosy: David Harding
priority: normal
severity: normal
status: open
title: ctypes on pypi has fallen behind
type: enhancement
versions: Python 3.5, Python 3.7

___
Python tracker 

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

[issue39529] Deprecate get_event_loop()

[Kyle Stanley]

Kyle Stanley  added the comment:

FWIW, I agree with get_event_loop() being problematic with its error messages, 
and having a bit too much functionality in a single function from an API design 
perspective. It commonly comes up as an issue among asyncio users in 
communities that I'm active in. 

Typically, I advise them to use get_running_loop() where possible, as it can be 
directly substituted within a coroutine func. For __init__ methods, I recommend 
setting their internal loop attribute to None and then setting it to 
get_running_loop() in either a coro start() method or coro factory method. 
Outside of directly managing the event loop, this works for many use cases. 
When it's needed to actually create one, I advise them to use new_event_loop(), 
but mention that it's already handled if they're using asyncio.run().

Andrew Svetlov wrote:
> The asyncio.get_event_loop() function will stay in Python for a while in 
> deprecated status. I don't know the exact period but it should be 3 releases 
> at least I guess, with possibly extending to 5 releases if needed.

With how many libraries that rely on it, I suspect it will likely be a very 
slow transition from deprecation to removal. 4 versions seems like a reasonable 
period to me, but I think that 3 may be too short (assuming we retain the newer 
annual release cycle).

Yury Selivanov wrote:
> I think we still use get_event_loop() in asyncio code, no?

Indeed, we currently use it in several places throughout asyncio. From a brief 
glace using git grep "get_event_loop()":

Lib/asyncio/futures.py:76:self._loop = events.get_event_loop()
Lib/asyncio/futures.py:390:loop = events.get_event_loop()
Lib/asyncio/locks.py:81:self._loop = events.get_event_loop()
Lib/asyncio/locks.py:177:self._loop = events.get_event_loop()
Lib/asyncio/locks.py:244:self._loop = events.get_event_loop()
Lib/asyncio/locks.py:375:self._loop = events.get_event_loop()
Lib/asyncio/queues.py:35:self._loop = events.get_event_loop()
Lib/asyncio/streams.py:45:loop = events.get_event_loop()
Lib/asyncio/streams.py:82:loop = events.get_event_loop()
Lib/asyncio/streams.py:104:loop = events.get_event_loop()
Lib/asyncio/streams.py:120:loop = events.get_event_loop()
Lib/asyncio/streams.py:147:self._loop = events.get_event_loop()
Lib/asyncio/streams.py:403:self._loop = events.get_event_loop()
Lib/asyncio/subprocess.py:206:loop = events.get_event_loop()
Lib/asyncio/subprocess.py:227:loop = events.get_event_loop()
Lib/asyncio/tasks.py:69:loop = events.get_event_loop()
Lib/asyncio/tasks.py:129:loop = events.get_event_loop()
Lib/asyncio/tasks.py:590:loop = events.get_event_loop()
Lib/asyncio/tasks.py:669:loop = events.get_event_loop()
Lib/asyncio/tasks.py:751:loop = events.get_event_loop()

For brevity, I omitted the docs, tests, and the function definition for 
get_event_loop().

Based on Serhiy's idea (of making get_event_loop() an alias for 
get_running_loop() without warning inside of a coro func, but warning for using 
it outside of one), many of the above could remain as is to reduce some code 
churn. We just have to make sure the documentation is updated to reflect 
get_event_loop() becoming an alias for get_running_loop(), at the same time as 
the deprecation warning is added for using it outside of a coro func. 
Otherwise, I suspect it could lead to significant confusion from users that 
have warnings enabled.

That being said, I think we should eventually remove asyncio.get_event_loop() 
entirely from the asyncio internals, including the ones that wouldn't raise 
deprecation warnings (if/when it's made an alias to get_running_loop()) for 
improved clarity. Personally, I find that even the name get_event_loop() is 
rather vague; get_running_loop() is much more obvious as to its purpose and 
what it does from a readability perspective.

Yury Selivanov wrote:
> If we do, we should start by raising deprecation warnings in those call 
> sites, e.g. if a Future or Lock is created outside of a coroutine and no 
> explicit event loop is passed.

For asyncio.Lock (plus other synchronization primitives) and asyncio.Queue, 
this would be added in https://github.com/python/cpython/pull/18195. Currently 
waiting on emanu (author of the PR) to finish up some changes, but it's mostly 
complete. Could I work on adding it to asyncio.Future and other classes in the 
meantime?

One point to be clarified though: you mention "created outside of a coroutine 
and no explicit event loop is passed". However, there are already several 
deprecations in place for passing an explicit event loop for most (if not all) 
of the __init__ methods for objects across asyncio's high-level API. In those 
cases, should the deprecation for creating the object outside of a coroutine 
function care about whether or not an 

[issue38691] importlib: PYTHONCASEOK should be ignored when using python3 -E

[Ido Michael]

Change by Ido Michael :


--
pull_requests: +17977
pull_request: https://github.com/python/cpython/pull/18612

___
Python tracker 

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

[issue38035] shared_semaphores cannot be shared across unrelated processes

[Ido Michael]

Ido Michael  added the comment:

@taleinat what do you think?

--
nosy: +taleinat

___
Python tracker 

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

[issue30097] Command-line option to suppress "from None" for debugging

[Ethan Furman]

Ethan Furman  added the comment:

The actual problem, I think, is that `from None` is suppressing more than it 
ought.  Martin's example would work just fine if the only omitted exception was 
the one captured during its own try/except.

Created issue39725.

--

___
Python tracker 

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

[issue39724] IDLE threading + stdout/stdin observed blocking behavior

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Summary: With IDLE running normally, with 2 processes, "input('prompt')" in the 
main thread blocks execution of "print('whatever')" in a separate thread.  
(Verified on Windows with 3.9 and macOS with 3.8.)  The user can respond to the 
prompt without being disrupted by continued output.

For standard single process python or IDLE (started with -n), the thread output 
continues and can be mixed in with both the input prompt and user response and 
in the example, scroll prompt and even initial response off the screen.

I presume the difference is related to IDLE routing user-code use of the std 
streams through a 3rd thread that manages the inter-process socket connection.  
But I did not see why after more than an hour of looking.

Overall, I think the experience with input() in IDLE is more useful and less 
confusing, especially to beginners.  (I am having trouble imagining when the 
intermixing and interference would be useful.)

Guido, do you have any recollection of whether the IDLE difference, when using 
an execution process, is intended?  Do you regard intermixing input prompts and 
responses and thread output as a required feature of Python, or as an 
(unfortunate, IMHO) side-effect of using a dumb text interface?

Note: in IDLE, '>>>' come from IDLE, not the usercode execution process.  Hence 
a) asynchonous outputs from the execution process can appear on the screen, and 
b) IDLE, unlike the standard REPL, can and does prevents such text from mixing 
into and spoiling user code input.  (It may appear after '>>>' but is put 
before the input area.  This is an intentional interface difference.

My *immediate* inclination is to regard the IDLE difference as overall being a 
positive feature and leave it alone.  But it should be documented in "Running 
user code", which is already mostly about stdio differences.  

I don't deny that blocking output while a user responds is a negative.  I just 
see mixing streams as worse.  To work towards not blocking while not mixing, I 
replaced the thread loop with
for i in range(10): sys.stdout.write(f'some text {i}\n')
and separated input(prompt) into sys.stdout.write(prompt) and 
sys.stdin.readline().

Observations:
1. .write is better as it is atomic, while print() prints '\n' separately, with 
sometimes undesirable results.
2. The block is from readline.
3. While output to Shell is blocked on readline, typing a continuation-invoking 
'.' or calltip-invoking '(' in either Shell or editor allows one line of 
output.  Both send a non-stdio message from Shell to the run process and back.  
This might be a clue as to how read/readline blocks.

In the longer term, after some changes to Shell, I could imagine replacing 
__builtins__.input with a function that would check if sys.stdin/out were 
IDLE's replacements and if so, send the prompt to Shell tagged as 'prompt' 
rather than as 'stdout', so that Shell could keep prompt and user response  
separate from regular output, similar to the way now done for code input.  If 
.readline cannot be made to not block output, it might work for Shell to send  
the response back tagged as 'response' rather than as 'stdin' and not use 
readline.

--
nosy: +gvanrossum, taleinat
stage:  -> needs patch
versions: +Python 3.8, Python 3.9

___
Python tracker 

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

[issue37373] Configuration of windows event loop for libraries

[Ben Darnell]

Ben Darnell  added the comment:

I have an implementation of the selector-in-another-thread solution in 
https://github.com/tornadoweb/tornado/pull/2815. Is something like this worth 
considering for Python 3.9, or was Tornado the only project experiencing this 
pain and a tornado-specific solution is enough?

--

___
Python tracker 

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

[issue36000] __debug__ is a keyword but not a keyword

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Serhiy wrote in msg336099 that __debug__ isn't a keyword and the error message 
was changed in 3.8.  Due to that, I'm going to close this as not a bug.

--
nosy: +cheryl.sabella
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

[issue39725] unrelated `from None` exceptions lose prior exception information

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Interesting problem.

Example which does not depend on os.environ:

import traceback
try:
try:
raise TypeError
except:
try:
raise ValueError
except:
raise KeyError from None
except BaseException as exc:
e = exc

print([e, e.__cause__, e.__context__, e.__suppress_context__])
traceback.print_exception(type(e), e, e.__traceback__)


"from None" sets __suppress_context__ to True. Currently, if 
__suppress_context__ is true, the output of __context__ will be suppressed in 
the traceback. But what if we suppress only a part __context__ and output the 
"original" exception. The problem is what is the "original" exception. Is it 
__context__.__context__? Or __context__.__cause__ if it is not None? Should we 
take __context__.__suppress_context__ into account? Maybe go down recursively?

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue17422] language reference should specify restrictions on class namespace

[miss-islington]

miss-islington  added the comment:


New changeset 36a120d343c1cb69b8d02913569c153e8bb969c8 by Miss Islington (bot) 
in branch '3.7':
bpo-17422: Language reference should specify restrictions on class namespace 
(GH-18559)
https://github.com/python/cpython/commit/36a120d343c1cb69b8d02913569c153e8bb969c8


--

___
Python tracker 

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

[issue17422] language reference should specify restrictions on class namespace

[miss-islington]

miss-islington  added the comment:


New changeset 91ba44623e5cb8f4a7b0d3fc1fab8ff8d8a849c2 by Miss Islington (bot) 
in branch '3.8':
bpo-17422: Language reference should specify restrictions on class namespace 
(GH-18559)
https://github.com/python/cpython/commit/91ba44623e5cb8f4a7b0d3fc1fab8ff8d8a849c2


--
nosy: +miss-islington

___
Python tracker 

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

[issue39725] unrelated `from None` exceptions lose prior exception information

[Ethan Furman]

New submission from Ethan Furman :

Using the example from https://bugs.python.org/msg293185:

---
--> import os
--> try:
... os.environ["NEW_VARIABLE"] = bug  # bug is not a str
... finally:
... del os.environ["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  ...
KeyError: 'NEW_VARIABLE'
---

We lost the original exception, `TypeError: str expected, not object`, because 
in os.py we have:

def __delitem__(self, key):
encodedkey = self.encodekey(key)
unsetenv(encodedkey)
try:
del self._data[encodedkey]
except KeyError:
# raise KeyError with the original key value
raise KeyError(key) from None


If we remove the `from None` the result of the above code is:

---
Traceback (most recent call last):
TypeError: str expected, not type

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
KeyError: b'NEW_VARIABLE'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
KeyError: 'NEW_VARIABLE'
---


There are various tricks we can do to fix this isolated issue (and others like 
it), but the real problem is that one exception handler's work was destroyed by 
an unrelated exception handler.

The intent of `from None` is to get rid of any exception details in the 
try/except block it is contained within, not to lose details from exceptions 
that were already in play when its try/except block was entered.

Any ideas on how to correct this?

--
messages: 362478
nosy: ethan.furman, ncoghlan, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: unrelated  `from None` exceptions lose prior exception information
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

[issue39710] "will be returned as unicode" reminiscent from Python 2

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +newcomer friendly
stage:  -> needs patch
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

[issue39639] Remove Suite node from AST

[Jeff Allen]

Jeff Allen  added the comment:

Jython uses the reference grammar and ASDL as a way to ensure it is Python we 
approximate, not some subtly different language. The presence of Suite here 
gives rise to a class 
(https://github.com/jythontools/jython/blob/v2.7.2b3/src/org/python/antlr/ast/Suite.java)
 and we actually use instances of it in the compiler 
(https://github.com/jythontools/jython/blob/v2.7.2b3/src/org/python/compiler/CodeCompiler.java#L2389).

It is a bit of a wart, to have a Jython-specific type here: somewhat defeating 
the object of using the same source. I expect there was a good reason: perhaps 
there was no better way to express the commonality between Interactive and 
Module. It was all before my involvement.

I would try to avoid needing it in Jython 3, and if we can't, it doesn't look 
hard to manage the variation our copy. It's not like we copy these files 
mechanically from from CPython during a build.

+1 on removing it.

--
nosy: +jeff.allen

___
Python tracker 

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

[issue30097] Command-line option to suppress "from None" for debugging

[Ethan Furman]

Ethan Furman  added the comment:

+1 for the idea.

Instead of '-C' we could add it as one of the '-X' options -- it is, after all, 
a development issue.

--
nosy: +ethan.furman

___
Python tracker 

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

[issue39180] Missing getlines func documentation from linecache module

[Khalid Mammadov]

Change by Khalid Mammadov :


--
resolution:  -> duplicate

___
Python tracker 

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

[issue39139] Reference to depricated collections.abc class in collections is unnecessary and confusing

[Khalid Mammadov]

Khalid Mammadov  added the comment:

Looks like this is covered in greater detail in the other PRs. So, closing the 
PR and the issue

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

[issue39139] Reference to depricated collections.abc class in collections is unnecessary and confusing

[Khalid Mammadov]

Change by Khalid Mammadov :


--
resolution:  -> duplicate

___
Python tracker 

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

[issue39180] Missing getlines func documentation from linecache module

[Khalid Mammadov]

Khalid Mammadov  added the comment:

Looks like it's not meant to be made public as the module is meant to be 
working on a single line. So closing the issue and PR

--
nosy:  -ammar2
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

[issue39180] Missing getlines func documentation from linecache module

[Ammar Askar]

Ammar Askar  added the comment:

A good place to start is looking at the blame to find the commit that 
introduced it. Which was:

https://github.com/python/cpython/commit/17ab123cf1f0597e7e257c1ce83a6e87b85ffd7b#diff-71666751dc5821f7fc30e9c8138019c9

and if we browse to the state of the file before that commit we see:

https://github.com/python/cpython/blob/bbd89b66b1b3c44836f560b60c7a176a6172f148/Lib/linecache.py#L32-L39

which indicates that it used to be exposed but was maybe overlooked when 
__all__ was added.

--
nosy: +ammar2

___
Python tracker 

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

[issue39180] Missing getlines func documentation from linecache module

[Khalid Mammadov]

Khalid Mammadov  added the comment:

How to find if it was intentional or over-site?

--

___
Python tracker 

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

[issue39130] Dict is reversable from v3.8 and should say that in the doc

[Khalid Mammadov]

Change by Khalid Mammadov :


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

[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)

[Pedro Algarvio]

Pedro Algarvio  added the comment:

What I'm able to copy from the console(though I doubt I'm getting all of
the traceback):

Traceback (most recent call last):

  File "", line 1, in 

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\spawn.py",
line 106, in spawn_main

exitcode = _main(fd)

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\spawn.py",
line 116, in _main

self = pickle.load(from_parent)

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\connection.py",
line 942, in rebuild_pipe_connection

handle = dh.detach()

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\reduction.py",
line 128, in detach

self._access, False, _winapi.DUPLICATE_CLOSE_SOURCE)

PermissionError: [WinError 5] Access is denied

Pedro Algarvio @ Phone

A sábado, 22/02/2020, 13:44, Eryk Sun  escreveu:

>
> Eryk Sun  added the comment:
>
> > I seem to be consistingly hitting this issue.
>
> It will help with test development if you can provide a minimal example
> that reliably reproduces the problem.
>
> In msg353064 I see DuplicateHandle calls failing with ERROR_ACCESS_DENIED
> (5). Assuming the process handles have the required PROCESS_DUP_HANDLE
> access, it's most likely the case that the underlying NtDuplicateObject
> system call is failing with STATUS_PROCESS_IS_TERMINATING (0xC10A). For
> example:
>
> import ctypes
> ntdll = ctypes.WinDLL('ntdll')
> from subprocess import Popen, PIPE
> from _winapi import GetCurrentProcess, TerminateProcess
> from _winapi import DuplicateHandle, DUPLICATE_SAME_ACCESS
>
> p = Popen('cmd.exe', stdin=PIPE, stdout=PIPE, stderr=PIPE)
> TerminateProcess(p._handle, 0)
>
> Try to duplicate the process handle into the terminated process:
>
> >>> source = GetCurrentProcess()
> >>> target = handle = p._handle
> >>> try:
> ... DuplicateHandle(source, handle, target,
> ... 0, False, DUPLICATE_SAME_ACCESS)
> ... except:
> ... status = ntdll.RtlGetLastNtStatus()
> ... print(f'NTSTATUS: {status & (2**32-1):#010x}')
> ... raise
> ...
> NTSTATUS: 0xc10a
> Traceback (most recent call last):
>   File "", line 2, in 
> PermissionError: [WinError 5] Access is denied
>
> --
> nosy: +eryksun
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue17422] language reference should specify restrictions on class namespace

[miss-islington]

Change by miss-islington :


--
pull_requests: +17976
pull_request: https://github.com/python/cpython/pull/18611

___
Python tracker 

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

[issue17422] language reference should specify restrictions on class namespace

[miss-islington]

Change by miss-islington :


--
pull_requests: +17975
pull_request: https://github.com/python/cpython/pull/18610

___
Python tracker 

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

[issue17422] language reference should specify restrictions on class namespace

[Guido van Rossum]

Change by Guido van Rossum :


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

[issue17422] language reference should specify restrictions on class namespace

[Guido van Rossum]

Guido van Rossum  added the comment:


New changeset fbe2e0bb8a7ee75d0f9d57682436dac7d69e202e by ananthan-123 in 
branch 'master':
bpo-17422: Language reference should specify restrictions on class namespace 
(#18559)
https://github.com/python/cpython/commit/fbe2e0bb8a7ee75d0f9d57682436dac7d69e202e


--
nosy: +gvanrossum

___
Python tracker 

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

[issue39724] IDLE threading + stdout/stdin observed blocking behavior

[John Smith]

John Smith  added the comment:

P.S. here (other computer but with same observed behavior) I have a 3.6 32bit 
as one can see from the output.

--

___
Python tracker 

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

[issue39724] IDLE threading + stdout/stdin observed blocking behavior

[John Smith]

Change by John Smith :


Added file: 
https://bugs.python.org/file48901/IDLE_threading_issue_min_example1.py

___
Python tracker 

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

[issue39724] IDLE threading + stdout/stdin observed blocking behavior

[John Smith]

John Smith  added the comment:

py -m idlelib -n path output:

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
 No Subprocess 

WARNING: Running IDLE without a Subprocess is deprecated
and will be removed in a later version. See Help/IDLE Help
for details.

>>> 
waiting for inputalive
alive
alive
alive
alive
alive

 -> so its working as intended

--

___
Python tracker 

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

[issue39724] IDLE threading + stdout/stdin observed blocking behavior

[Terry J. Reedy]

Terry J. Reedy  added the comment:

If I understand, input() in one thread blocks print() in another thread. 
This sound like a new issue for this tracker, and possibly a bug in IDLE's 
implementation of std streams through a socket, but I need to see your code.  
Please try attaching it again.

Also, try running >py -m idlelib -n path

--

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[hai shi]

Change by hai shi :


--
pull_requests: +17974
pull_request: https://github.com/python/cpython/pull/18608

___
Python tracker 

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

[issue39382] abstract_issubclass() doesn't take bases tuple item ref

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)

[Eryk Sun]

Eryk Sun  added the comment:

> I seem to be consistingly hitting this issue.

It will help with test development if you can provide a minimal example that 
reliably reproduces the problem. 

In msg353064 I see DuplicateHandle calls failing with ERROR_ACCESS_DENIED (5). 
Assuming the process handles have the required PROCESS_DUP_HANDLE access, it's 
most likely the case that the underlying NtDuplicateObject system call is 
failing with STATUS_PROCESS_IS_TERMINATING (0xC10A). For example:

import ctypes
ntdll = ctypes.WinDLL('ntdll')
from subprocess import Popen, PIPE
from _winapi import GetCurrentProcess, TerminateProcess
from _winapi import DuplicateHandle, DUPLICATE_SAME_ACCESS

p = Popen('cmd.exe', stdin=PIPE, stdout=PIPE, stderr=PIPE)
TerminateProcess(p._handle, 0)

Try to duplicate the process handle into the terminated process:

>>> source = GetCurrentProcess()
>>> target = handle = p._handle
>>> try:
... DuplicateHandle(source, handle, target,
... 0, False, DUPLICATE_SAME_ACCESS)
... except:
... status = ntdll.RtlGetLastNtStatus() 
... print(f'NTSTATUS: {status & (2**32-1):#010x}')
... raise
...
NTSTATUS: 0xc10a
Traceback (most recent call last):
  File "", line 2, in 
PermissionError: [WinError 5] Access is denied

--
nosy: +eryksun

___
Python tracker 

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

[issue39382] abstract_issubclass() doesn't take bases tuple item ref

[miss-islington]

miss-islington  added the comment:


New changeset 0c1827e70c1c05ce1982a34380cea7d391904293 by Miss Islington (bot) 
in branch '3.8':
bpo-39382: Avoid dangling object use in abstract_issubclass() (GH-18530)
https://github.com/python/cpython/commit/0c1827e70c1c05ce1982a34380cea7d391904293


--

___
Python tracker 

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

[issue39382] abstract_issubclass() doesn't take bases tuple item ref

[miss-islington]

miss-islington  added the comment:


New changeset 43a0137c87b997c6ba8b23cc3281ce2de18f008a by Miss Islington (bot) 
in branch '3.7':
bpo-39382: Avoid dangling object use in abstract_issubclass() (GH-18530)
https://github.com/python/cpython/commit/43a0137c87b997c6ba8b23cc3281ce2de18f008a


--
nosy: +miss-islington

___
Python tracker 

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

[issue39382] abstract_issubclass() doesn't take bases tuple item ref

[miss-islington]

Change by miss-islington :


--
pull_requests: +17973
pull_request: https://github.com/python/cpython/pull/18607

___
Python tracker 

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

[issue39382] abstract_issubclass() doesn't take bases tuple item ref

[miss-islington]

Change by miss-islington :


--
pull_requests: +17972
pull_request: https://github.com/python/cpython/pull/18606

___
Python tracker 

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

[issue39382] abstract_issubclass() doesn't take bases tuple item ref

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 1c56f8ffad44478b4214a2bf8eb7cf51c28a347a by Yonatan Goldschmidt 
in branch 'master':
bpo-39382: Avoid dangling object use in abstract_issubclass() (GH-18530)
https://github.com/python/cpython/commit/1c56f8ffad44478b4214a2bf8eb7cf51c28a347a


--

___
Python tracker 

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

[issue39648] Expand math.gcd() and math.lcm() to accept multiple arguments

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If expand math.gcd() to accept multiple arguments, it is worth to do the same 
with math.lcm().

--
title: Update math.gcd() to accept "n" arguments. -> Expand math.gcd() and 
math.lcm() to accept multiple arguments

___
Python tracker 

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

[issue39648] Update math.gcd() to accept "n" arguments.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm always ready to help a beginner, but this is the first time that it takes 
so much effort. It would be easier if you started with the simple problems you 
could handle. Even in simple cases you would be able to get tips that you can 
understand and gradually improve your skills.

--

___
Python tracker 

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

[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)

[Pedro Algarvio]

Pedro Algarvio  added the comment:

Any possible workaround for this issue?
I seem to be consistingly hitting this issue.

--
nosy: +s0undt3ch

___
Python tracker 

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

[issue39648] Update math.gcd() to accept "n" arguments.

[Ananthakrishnan]

Ananthakrishnan  added the comment:

>>Sorry, Ananthakrishnan, but I think this problem is too difficult to you. 
>>Adding math.lcm() taken 2 weeks and produced 200 messages. It is simpler to 
>>implement this feature myself to me.


I'm a beginner.Not everyone is perfect at begenning.
I am starting this.So I took some problems myself as i saw the problems here 
are difficult.You should have given me a chance.

I think you should have at the same situations once,like the situations that 
I'm facing now.

--

___
Python tracker 

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

[issue39716] argparse.ArgumentParser does not raise on duplicated subparsers, even though it does on duplicated flags

[Antony Lee]

Antony Lee  added the comment:

Sure, https://github.com/python/cpython/pull/18605 it is.

--

___
Python tracker 

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

[issue39716] argparse.ArgumentParser does not raise on duplicated subparsers, even though it does on duplicated flags

[Antony Lee]

Change by Antony Lee :


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

___
Python tracker 

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

[issue39648] Update math.gcd() to accept "n" arguments.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +17970
pull_request: https://github.com/python/cpython/pull/18604

___
Python tracker 

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

[issue39648] Update math.gcd() to accept "n" arguments.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Sorry, Ananthakrishnan, but I think this problem is too difficult to you. 
Adding math.lcm() taken 2 weeks and produced 200 messages. It is simpler to 
implement this feature myself to me.

--

___
Python tracker 

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

[issue39724] IDLE threading + stdout/stdin observed blocking behavior

[John Smith]

New submission from John Smith :

preamble: I am aware that I am not the first to encounter this issue but 
neither I could identify a preexisting ticket which fully matches nor is the 
commonly recommended "solution" (stay away from IDLE) satisfying.

environment: win10, python 3.7 (tested with 32 and 64 bit version)

description: If the attached script is started from IDLE the "alive" only shows 
up once for every input, while the script output "alive" frequently if ran from 
the terminal with python. So there is a discrepancy between the behavior of 
IDLE and "plain" python, which can lead to serious "irritations". If the print 
is replaced with logging.info and the logging is setup to write into a file 
everything works as expected and equal in both environments.

thoughts: the input call seems to block access to stdout(?) in "IDLE mode". I 
noticed that there are several topics/post regarding IDLE's stdout/in behavior 
but I was unabled to find a (convinient) solution besides "just quit using 
IDLE". It feels strange that the editor bundled with python has such a 
reputation and features such a deviation in behavior from "plain" python.

--
assignee: terry.reedy
components: IDLE
messages: 362456
nosy: John Smith, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE threading + stdout/stdin observed blocking behavior
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

[issue39723] io.open_code should accept PathLike objects

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

This seems to be a duplicate of https://bugs.python.org/issue39691

--

___
Python tracker 

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

[issue39723] io.open_code should accept PathLike objects

[SilentGhost]

Change by SilentGhost :


--
nosy: +steve.dower
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