[issue40411] frozen collection.Counter

[paul rubin]

paul rubin  added the comment:

Totally tangential: Veky, your ordinal example would work ok in Haskell and 
you'd have omega work the same way as epsilon0.  Take a look at Herman Ruge 
Jervell's book "Proof Theory" for a really nice tree-based ordinal notation 
that goes much higher than epsilon0.  It would be cool if your student 
implemented it.  Raymond, I agree that ordinals are a very esoteric use of 
multisets ;).

--

___
Python tracker 

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

[issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.

[BenTen Jan]

BenTen Jan  added the comment:

First and foremost thanks for replying,

1. I don't have any virus scanner installed.
2. I have tried running "python -m ensurepip" it shows me Following error 

C:\Python>Python get-pip.py
Traceback (most recent call last):
  File "get-pip.py", line 22711, in 
main()
  File "get-pip.py", line 198, in main
bootstrap(tmpdir=tmpdir)
  File "get-pip.py", line 82, in bootstrap
from pip._internal.cli.main import main as pip_entry_point
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\main.py",
 line 10, in 
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\autocompletion.py",
 line 9, in 
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\main_parser.py",
 line 7, in 
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\cli\cmdoptions.py",
 line 28, in 
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\models\target_python.py",
 line 4, in 
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_internal\utils\misc.py",
 line 20, in 
  File "", line 259, in load_module
  File 
"C:\Users\KNN\AppData\Local\Temp\tmpvrhu1rqz\pip.zip\pip\_vendor\pkg_resources\__init__.py",
 line 35, in 
  File "C:\Python\Python38-32\lib\plistlib.py", line 65, in 
from xml.parsers.expat import ParserCreate
  File "C:\Python\Python38-32\lib\xml\parsers\expat.py", line 4, in 
from pyexpat import *
ImportError: DLL load failed while importing pyexpat: The specified module 
could not be found.

3. Whole Scripts folder in python root is empty, i don't know if its ok with 
3.8.2 but Scripts folder was having files in 2.X versions...

Thanks & Appreciate The Handwork of yours towards PY.COMM..

Ben

--

___
Python tracker 

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

[issue40061] Possible refleak in _asynciomodule.c future_add_done_callback()

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +19069
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19748

___
Python tracker 

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

[issue40411] frozen collection.Counter

[paul rubin]

paul rubin  added the comment:

Yeah I think the basic answer to this ticket is "Python doesn't really have 
multisets and a proposal to add them should go somewhere else".  Fair enough-- 
consider the request withdrawn from here.

Regarding minimalism vs completeness, regarding some feature X (say X is 
multisets), it's reasonable per minimalism to decide not to have X.  But if on 
weighing the use cases you decide to have X after all, I think it's best to 
implement X properly and completely with all the edge cases handled, rather 
than implement a half-baked subset.  That was something Java was historically 
very good at and Python wasn't.  I guess that is one for the theorists though.  
Thanks everyone.

--

___
Python tracker 

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

[issue40411] frozen collection.Counter

[Raymond Hettinger]

Raymond Hettinger  added the comment:

If you're interested in pursuing this, please follow Kyle's suggestion and move 
this to Python ideas.  The two frozencounter use cases presented are pretty 
exotic, something encountered rarely in a lifetime.  That is well below the 
threshold for growing the standard library.  We cater to the commonplace. It is 
for PyPI to cater to everything else :-)

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

[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child

[hai shi]

hai shi  added the comment:

> "since we are going to delete the threading.Thread object with its 
> _tstate_lock object anyway" sentence is a description of the current 
> _PyThreadState_DeleteExcept() implementation.

Oh, got it. thanks for your explanation :)

--

___
Python tracker 

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

[issue40411] frozen collection.Counter

[Kyle Stanley]

Kyle Stanley  added the comment:

paul rubin wrote:
> In that case, it works for what it is made for, so it really then is a 
> separate question of whether implementing multisets properly is worthwhile.

Indeed, that seems to be the primary question to address. Personally, I don't 
have any strong opposition to including a multiset implementation in 
collections, I'm just not yet convinced they have enough widespread practical 
utility (that can't already be provided with Counter or a slightly modified 
version of it) to justify including them in collections.
 
> I dislike the concept of shovelling off basic functionality to 3rd party 
> libraries.  The rejection of that philosophy (Python's old motto "Batteries 
> included") is one of the things that attracted me to Python in the first 
> place.  Though that value is mostly historical now, I'm sad about the loss.  
> It's impossible to write a large Ruby or Javascript (npm) application with 
> 100s of third party modules, every one of which is an attack vector ("supply 
> chain attack" is the current buzzword), and  whose implementations vary 
> widely in quality and usability.

I can certainly sympathize with that sentiment of wanting to avoid excessive 
dependencies, and I think in general that we do still try to include more in 
the Python standard library compared to many other ecosystems. AFAIK, there's 
zero desire for the Python ecosystem to slowly turn into the "dependency hell" 
that NPM has become, with almost every library relying on a chain of minor 3rd 
party utilities.

However, rather than including everything that *might* be useful, the goal has 
been to include features that have substantial practical utility for a decent 
volume of users (and library maintainers), as long as they fit with the 
existing theme of a module (or are widely needed enough to justify a separate 
module) for a couple of primary reasons:

1) Making the stdlib modules as digestible as reasonably possible
2) Maximizing the ratio of practical benefit to implementation and long-term 
maintenance cost, which is especially important since development is 
voluntarily driven

Also, I would consider "batteries included" to still be a general goal, but 
it's practically impossible for the stdlib to fully cover what everyone would 
consider to be "basic functionality" while still maintaining its present 
quality. It's even more complicated by the fact that "basic functionality" will 
differ significantly depending upon who you ask, based upon what they 
personally use Python for and their unique experiences.

So, we tend to lean towards minimalism, focusing on implementing and improving 
features that have the most or strongest concrete use cases for a large volume 
of users. There are of course exceptions to this, such as features that are 
highly useful for a relatively small volume of users, but are difficult to 
implement a proper or optimized version. That has to be determined on a 
case-by-case basis though.

--
nosy:  -veky

___
Python tracker 

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

[issue40416] Calling TextIOWrapper.tell() in the middle of reading a gb2312-encoded file causes UnicodeDecodeError

[Rob Malouf]

New submission from Rob Malouf :

Calling TextIOWrapper.tell() while reading the attached gb2312-encoded file 
like this:

with open('udhr-gb2312.txt', encoding='GB2312') as f: 
while True: 
   line = f.readline() 
   t = f.tell()
   if not line: 
   break 

gives this result:

Traceback (most recent call last):
  File "test.py", line 4, in 
t = f.tell()
UnicodeDecodeError: 'gb2312' codec can't decode byte 0xb5 in position 0: 
illegal multibyte sequence

The file seems to be well-formed and can be read without any problem.  It's 
only the call to tell() that raises an issue.

--
components: IO, Unicode
files: udhr-gb2312.txt
messages: 367494
nosy: ezio.melotti, rmalouf, vstinner
priority: normal
severity: normal
status: open
title: Calling TextIOWrapper.tell() in the middle of reading a gb2312-encoded 
file causes UnicodeDecodeError
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file49096/udhr-gb2312.txt

___
Python tracker 

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

[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)

[Matthew Davis]

Matthew Davis  added the comment:

Ah, yes that workaround works. Thanks!

So what's the exact status of this policy? It's called the default policy, but 
it's not used by default?

If I download the latest version of python, will this be parsed correctly 
without explicitly setting the policy?

i.e. Is this still something that should be changed in the code?

(Yes, I already use message_from_bytes in my real application. I just used 
message_from_string in the MWE, because I could only attach one file in this 
web page, so I embedded the email body as a string in the script.)

--

___
Python tracker 

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

[issue40411] frozen collection.Counter

[Vedran Čačić]

Vedran Čačić  added the comment:

Just another usecase: one of my students is writing an implementation of 
ordinal arithmetic in Python as a graduate thesis. FrozenCounters whose keys 
are FrozenCounters and whose values are natural numbers are _exactly_ 
isomorphic (via Cantor's normal form) to countable ordinals below epsilon_0 
(and if a Counter can have itself as a key, we can go above epsilon_0 too).

Examples: zero = f{}
  one = f{zero: 1}
  seven = f{zero: 7}
  omega = f{one: 1}
  w^7*3+5 = f{seven: 3, zero: 5}
  w^w^w = f{f{omega: 1}: 1}
  epsilon0 = f{epsilon0: 1}
  and so on

I realize this is not something everybody does, but just to show that the need 
exists. We started with https://github.com/tamuhey/python-frozen-counter, 
afterwards we rolled our own implementation. But if it were in the stdlib, it 
would have saved us a lot of work.

--
nosy: +veky

___
Python tracker 

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

[issue40411] frozen collection.Counter

[paul rubin]

paul rubin  added the comment:

Oops I meant "*without* 100s of third party modules" in the case of ruby gems 
or npm.  There are just a few pip modules that I really use all the time, most 
notably bs4.  I continue to use urllib/urllib2 instead of requests because I'm 
used to them and because they eliminate an unnecessary dependency.

--

___
Python tracker 

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

[issue40358] pathlib's relative_to should behave like os.path.relpath

[Domenico Ragusa]

Domenico Ragusa  added the comment:

Yeah, you're right, there's no access to the filesystem and the result
is generated assuming the paths are already resolved.
`strict` seems to be an appropriate name for the option, thanks.

I've looked into the test suite, it helped a lot especially with
Windows paths, they were more complicated than I though.
I've duplicated the tests to verify that it still function as before
and I've added some tests for values that would raise an exception. It
works.
I'm not overly fond of the way I check for unrelated paths, but I
couldn't think of something more elegant.

Any input is appreciated.

--
Added file: https://bugs.python.org/file49095/relative_to.patch

___
Python tracker 

___diff --git a/Lib/pathlib.py b/Lib/pathlib.py
index f98d69e..eb25761 100644
--- a/Lib/pathlib.py
+++ b/Lib/pathlib.py
@@ -895,10 +895,10 @@ class PurePath(object):
 return self._from_parsed_parts(self._drv, self._root,
self._parts[:-1] + [name])
 
-def relative_to(self, *other):
+def relative_to(self, *other, strict=True):
 """Return the relative path to another path identified by the passed
 arguments.  If the operation is not possible (because this is not
-a subpath of the other path), raise ValueError.
+related to the other path), raise ValueError.
 """
 # For the purpose of this method, drive and root are considered
 # separate parts, i.e.:
@@ -918,14 +918,31 @@ class PurePath(object):
 to_abs_parts = [to_drv, to_root] + to_parts[1:]
 else:
 to_abs_parts = to_parts
+
 n = len(to_abs_parts)
 cf = self._flavour.casefold_parts
-if (root or drv) if n == 0 else cf(abs_parts[:n]) != cf(to_abs_parts):
+common = 0
+for p, tp in zip(cf(abs_parts), cf(to_abs_parts)):
+if p != tp:
+break
+common += 1
+
+if strict:
+failure = (root or drv) if n == 0 else common != n
+error_message = "{!r} does not start with {!r}"
+up_parts = []
+else:
+failure = root != to_root
+if drv or to_drv:
+failure = cf([drv]) != cf([to_drv]) or (failure and n > 1)
+error_message = "{!r} is not related to {!r}"
+up_parts = (n-common)*['..']
+
+if failure:
 formatted = self._format_parsed_parts(to_drv, to_root, to_parts)
-raise ValueError("{!r} does not start with {!r}"
- .format(str(self), str(formatted)))
-return self._from_parsed_parts('', root if n == 1 else '',
-   abs_parts[n:])
+raise ValueError(error_message.format(str(self), str(formatted)))
+return self._from_parsed_parts('', root if common == 1 else '',
+   up_parts+abs_parts[common:])
 
 def is_relative_to(self, *other):
 """Return True if the path is relative to another path or False.
diff --git a/Lib/test/test_pathlib.py b/Lib/test/test_pathlib.py
index 1589282..a6d8fe4 100644
--- a/Lib/test/test_pathlib.py
+++ b/Lib/test/test_pathlib.py
@@ -613,13 +613,30 @@ class _BasePurePathTest(object):
 self.assertEqual(p.relative_to('a/'), P('b'))
 self.assertEqual(p.relative_to(P('a/b')), P())
 self.assertEqual(p.relative_to('a/b'), P())
+self.assertEqual(p.relative_to(P(), strict=False), P('a/b'))
+self.assertEqual(p.relative_to('', strict=False), P('a/b'))
+self.assertEqual(p.relative_to(P('a'), strict=False), P('b'))
+self.assertEqual(p.relative_to('a', strict=False), P('b'))
+self.assertEqual(p.relative_to('a/', strict=False), P('b'))
+self.assertEqual(p.relative_to(P('a/b'), strict=False), P())
+self.assertEqual(p.relative_to('a/b', strict=False), P())
+self.assertEqual(p.relative_to(P('a/c'), strict=False), P('../b'))
+self.assertEqual(p.relative_to('a/c', strict=False), P('../b'))
+self.assertEqual(p.relative_to(P('a/b/c'), strict=False), P('..'))
+self.assertEqual(p.relative_to('a/b/c', strict=False), P('..'))
+self.assertEqual(p.relative_to(P('c'), strict=False), P('../a/b'))
+self.assertEqual(p.relative_to('c', strict=False), P('../a/b'))
 # With several args.
 self.assertEqual(p.relative_to('a', 'b'), P())
+self.assertEqual(p.relative_to('a', 'b', strict=False), P())
 # Unrelated paths.
 self.assertRaises(ValueError, p.relative_to, P('c'))
 self.assertRaises(ValueError, p.relative_to, P('a/b/c'))
 self.assertRaises(ValueError, p.relative_to, P('a/c'))
 self.assertRaises(ValueError, p.relative_to, P('/a'))
+

[issue40358] pathlib's relative_to should behave like os.path.relpath

[Domenico Ragusa]

Change by Domenico Ragusa :


Removed file: https://bugs.python.org/file49081/pathlib.diff

___
Python tracker 

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

[issue40411] frozen collection.Counter

[paul rubin]

paul rubin  added the comment:

Kyle, thanks, I saw your comment after posting my own, and I looked at 
Raymond's mailing list post that you linked.  I do think that "completing the 
grid" is a good thing in the cases where it's obvious how to do it (if there's 
one and one obvious way, then doing it that way should work), and having 
missing combinations in the grid is also a form of interface complexity (expect 
subset to work, find that it doesn't, and implement some hack).  Also it seems 
to me that sets, dicts, bags are basic data objects in many languages these 
days, without a lot of design space to move around in.  So we don't have to 
worry much about constraining future choices.  We could just look at Smalltalk 
or Ruby or whatever and just do what they did.  

However, that is philosophical.  I did learn from Raymond's message that 
Counter doesn't really attempt to be a multiset implementation.  In that case, 
it works for what it is made for, so it really then is a separate question of 
whether implementing multisets properly is worthwhile.  (That's as opposed to 
saying we already have a multiset implementation but some functionality is 
missing from it).

I dislike the concept of shovelling off basic functionality to 3rd party 
libraries.  The rejection of that philosophy (Python's old motto "Batteries 
included") is one of the things that attracted me to Python in the first place. 
 Though that value is mostly historical now, I'm sad about the loss.  It's 
impossible to write a large Ruby or Javascript (npm) application with 100s of 
third party modules, every one of which is an attack vector ("supply chain 
attack" is the current buzzword), and  whose implementations vary widely in 
quality and usability.  I looked at the docs for Ruby's multiset gem 
(https://maraigue.hhiro.net/multiset/) and they are partly in Japanese.  Python 
has until the past few years managed to keep away from that kind of thing.

--

___
Python tracker 

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

[issue40411] frozen collection.Counter

[paul rubin]

paul rubin  added the comment:

Yes, the idea was for them to be hashable, to be used as dict keys.  E.g. if 
you use frozensets to model graphs, you'd use frozen multisets for hypergraphs. 
 My immediate use case involved word puzzles, e.g. treating words as bags of 
scrabble tiles with letters on them, and finding out what other words you could 
form from the letters.  It is not a pressing need.  

I'm trying to remember what the other missing operation I ran into was, a few 
days ago.  It may have been subset.  I found a workaround but it seemed a bit 
ugly.  It would be nice if Counters could also be thought of as multisets which 
can do the same things sets can do with unneeded head scratching.  It seems 
like counters and multisets/bags really are different things conceptually.  
Their operations and implementations overlap, but they are different.  E.g. it 
can make sense for a counter to have a negative count of something, but not for 
a bag.

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[Kyle Stanley]

Kyle Stanley  added the comment:

After writing the above out and a bit of further consideration, I think it 
might make more sense to wait for the event after setting `self._closed = True` 
so that it prevents future wakeup() and clear() calls from reading/writing to 
the pipe, while still allowing ones that are currently ongoing to finish.

Thoughts?

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[Kyle Stanley]

Kyle Stanley  added the comment:

I can't be certain for the other failures, but I'm currently exploring a 
potential solution for addressing the `test_killed_child` failure. To me, it 
seems to be a race condition with attempting to call _ThreadWakeup.close() 
while there are still bytes being sent. IMO, we should wait until closing the 
pipe's reader and writer until it's finished sending or receiving bytes. Here's 
one way to implement that w/ threading.Event:

diff --git a/Lib/concurrent/futures/process.py 
b/Lib/concurrent/futures/process.py
index 8e9b69a8f0..9bf073fc34 100644
--- a/Lib/concurrent/futures/process.py
+++ b/Lib/concurrent/futures/process.py
@@ -68,21 +68,30 @@ class _ThreadWakeup:
 def __init__(self):
 self._closed = False
 self._reader, self._writer = mp.Pipe(duplex=False)
+# Used to ensure pipe is not closed while sending or receiving bytes
+self._not_running = threading.Event()
+# Initialize event as True
+self._not_running.set()
 
 def close(self):
 if not self._closed:
+self._not_running.wait()
 self._closed = True
 self._writer.close()
 self._reader.close()
 
 def wakeup(self):
 if not self._closed:
+self._not_running.clear()
 self._writer.send_bytes(b"")
+self._not_running.set()
 
 def clear(self):
 if not self._closed:
+self._not_running.clear()
 while self._reader.poll():
 self._reader.recv_bytes()
+self._not_running.set()


>From using Victor's method of replicating the failure with inserting a 
>`time.sleep(0.050)` in multiprocessing.Connection._send(), it appears to fix 
>the failure in test_killed_child. I believe it would also fix the other 
>failures since they appear to be caused by the same core issue, but I've been 
>unable to replicate them locally so I'm not 100% certain.

--
assignee:  -> aeros

___
Python tracker 

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

[issue40405] asyncio.as_completed documentation misleading

[Yury Selivanov]

Yury Selivanov  added the comment:

> @Yury what do you think?

Yeah, the documentation needs to be fixed.

> Maybe "Returns an iterator of awaitables"?

I'd suggest to change to: "Return an iterator of coroutines.  Each coroutine 
allows to wait for the earliest next result from the set of the remaining 
awaitables."

--

___
Python tracker 

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

[issue40415] _asyncio extensions crashes if initialized multiple times in same process

[Gregory Szorc]

Gregory Szorc  added the comment:

Oh, I just went to patch this and it is a dupe of 40294, which has already been 
fixed and backported.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue40415] _asyncio extensions crashes if initialized multiple times in same process

[Gregory Szorc]

Change by Gregory Szorc :


--
nosy: +vstinner

___
Python tracker 

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

[issue40415] _asyncio extensions crashes if initialized multiple times in same process

[Gregory Szorc]

New submission from Gregory Szorc :

Most of CPython's extensions can be initialized and freed multiple times in the 
same process. However, _asyncio crashes on at least CPython 3.8.2 when this is 
done.

STR:

1. Create a new Python interpreter
2. Have it import _asyncio
3. Finalize that interpreter.
4. Create a new Python interpreter
5. Have it import _asyncio

There are probably STR in pure Python by forcing _imp.create_dynamic() to run 
multiple times after the module is unloaded.

The crash occurs due to unchecked NULL access in `Py_INCREF(all_tasks);` in 
`PyInit__asyncio()`.

I think the underlying problem is module_init() is short-circuiting because 
`module_initialized` is set. And `module_initialized` is set on subsequent 
module loads because `module_free()` isn't clearing it.

--
components: asyncio
messages: 367483
nosy: asvetlov, indygreg, yselivanov
priority: normal
severity: normal
status: open
title: _asyncio extensions crashes if initialized multiple times in same process
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

[issue40411] frozen collection.Counter

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Do you want to freeze a counter to prevent future count changes or bto make it 
to be hashable?  Essentially the only reason we have frozenset is to use sets 
as dict keys to model graphs, but that wouldn't make much sense for counters.

What multiset methods do you need? We already have addition, subtraction, 
union, and intersection.  A symmetric_difference doesn't seem to make sense or 
have a use case.   AFAICT, all that is missing are subset/superset tests which 
were omitted because their semantics conflict with the existing dict equality 
semantics and because the use cases are rare.

--

___
Python tracker 

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

[issue40414] Incorrect mouse and keyboard mapping

[Jah-On]

New submission from Jah-On :

Hi all,
On Ubuntu Cinnamon Remix, with python3, and tkinter,

canvas.bind("<1>", callback)
canvas.bind("<2>", callback)
canvas.bind("<3>", callback)
canvas.bind("<4>", callback)
canvas.bind("<5>", callback)

are now mapped to mouse buttons, instead of keyboard number buttons.

--
components: Tkinter
messages: 367481
nosy: Jah-On
priority: normal
severity: normal
status: open
title: Incorrect mouse and keyboard mapping
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue40413] Py_RunMain() crashes on subsequence call

[Gregory Szorc]

Gregory Szorc  added the comment:

Actually, I can reproduce the crash without Py_RunMain(). So I don't think the 
crash is related to the additional cleanup that Py_RunMain() does in addition 
to Py_FinalizeEx().

But I'd like to keep this issue open to track the original question about 
expected behavior.

--

___
Python tracker 

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

[issue40413] Py_RunMain() crashes on subsequence call

[Gregory Szorc]

New submission from Gregory Szorc :

I'm attempting to perform the following actions multiple times in a single 
process with CPython 3.8.2:

1) Initialize an interpreter using the PEP-587 APIs.
2) Call Py_RunMain() (which finalizes the interpreter).

However, I've encountered at least 2 crashes due to use-after-free or unchecked 
NULL access (due to apparent state getting funky).

Are multiple interpreters / Py_RunMain() calls in a single process supported? 
Should I file bugs for all of the crashes I encounter?

--
components: C API
messages: 367479
nosy: indygreg, vstinner
priority: normal
severity: normal
status: open
title: Py_RunMain() crashes on subsequence call
type: crash
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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +pitrou

___
Python tracker 

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

[issue1726707] add itertools.ichain function and count.getvalue

[paul rubin]

paul rubin  added the comment:

Note, nowadays this is implement as itertools.chain.from_iterable .

--

___
Python tracker 

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

[issue40412] inittab_copy not set to NULL after free, can lead to crashes when running multiple interpreters in a single process

[Gregory Szorc]

Change by Gregory Szorc :


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

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +aeros

___
Python tracker 

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

[issue40412] inittab_copy not set to NULL after free, can lead to crashes when running multiple interpreters in a single process

[Gregory Szorc]

New submission from Gregory Szorc :

Filing a bug to placate the requirement that pull requests have issues.

--
components: C API
messages: 367477
nosy: indygreg
priority: normal
severity: normal
status: open
title: inittab_copy not set to NULL after free, can lead to crashes when 
running multiple interpreters in a single process
type: crash
versions: Python 3.5, Python 3.6, 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

[issue40411] frozen collection.Counter

[Kyle Stanley]

Kyle Stanley  added the comment:

Also, adding Raymond to the nosy list in case he has any specific comments 
about a frozen collections.Counter.

--
nosy: +rhettinger
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

[issue40411] frozen collection.Counter

[Kyle Stanley]

Kyle Stanley  added the comment:

Rather than starting this out as a bpo issue, I would highly recommend bringing 
forth a proposal for this in python-id...@python.org and explaining in as much 
detail as possible:

1) How a frozen variation of collection.Counter would benefit your specific use 
case
2) The current available workaround you mentioned, issues with it, and the 
comparative benefit your proposal would provide
3) Why it should be included in the standard library, compared to a 3rd party 
package on PyPI

The 3rd one can be a bit tricky, but it typically involves explaining how 
widespread the potential use case(s) would be and how tricky it would be for 
users to implement something like this on their own (from both a functionality 
and performance perspective).

>From a brief glance of the archives, it doesn't look like this specific idea 
>was proposed, other than part of a more generalized one to add frozen 
>equivalents for the entire collections module, which was rejected on the basis 
>of the use cases being too theoretical and overly broad.

Also, while not specific to your particular proposal, I would recommend reading 
over the following post from Raymond Hettinger in the python-ideas archive 
(from the previously mentioned thread): 
https://mail.python.org/archives/list/python-id...@python.org/message/QVBVJU4RNJ5MDKBJ5CNGINYG24WZDZX7/.
 It explains why the collections module tries to be minimalist, and 
specifically the requirement of new features providing a tangible, real-world 
benefit.

It's of course up to you how you decide to format the proposal, but by 
answering the above points and demonstrating clear value in specific use cases, 
it has a much better chance of eventually making into the standard library (or 
at the least, a constructive discussion about it).

--
nosy: +aeros

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[paul rubin]

Change by paul rubin :


--
nosy:  -phr

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 3d53d8756f0403eec6a4e12f183103d651bed6c5 by Lysandros Nikolaou in 
branch 'master':
bpo-40334: Don't skip test_parser:test_trigget_memory_error (GH-19744)
https://github.com/python/cpython/commit/3d53d8756f0403eec6a4e12f183103d651bed6c5


--

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset d55133f49fe678fbf047a647aa8bb8b520410e8d by Lysandros Nikolaou in 
branch 'master':
bpo-40334: Catch E_EOF error, when the tokenizer returns ERRORTOKEN (GH-19743)
https://github.com/python/cpython/commit/d55133f49fe678fbf047a647aa8bb8b520410e8d


--

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +19067
pull_request: https://github.com/python/cpython/pull/19745

___
Python tracker 

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

[issue40411] frozen collection.Counter

[paul rubin]

New submission from paul rubin :

It would be nice to have frozen Counters analogous to frozensets, so they are 
usable as dictionary keys.  One can of course create frozenset(counter.items()) 
but that means the set items are tuples rather than the original set elements, 
so it's no longer quick to check membership.  I can work around this in my 
immediate application but it seems like a shortcoming.  There are some other 
set operations that aren't supported by counters either, that would be nice if 
they are conceptually multisets.

--
components: Library (Lib)
messages: 367472
nosy: phr
priority: normal
severity: normal
status: open
title: frozen collection.Counter
type: enhancement

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Guido van Rossum]

Guido van Rossum  added the comment:

@phr: examples welcome! The bigger and nastier, the better. This *should* all 
be speedy but it wouldn't hurt to check.

--

___
Python tracker 

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

[issue2190] MozillaCookieJar ignore HttpOnly cookies

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This issue was closed as useless for Firefox in 2010 by the original poster, 
msg109958.  My participation here is only as tracker triager, as I only have a 
consumer knowledge of cookies.  Unfortunately, there is no core developer 
expert for http, let alone the http.cookiejar.  The person who once handled 
some cookie related patches is no longer active.

Adding a patch to a closed issue is somewhat useless.  In any case, a possible 
revised PR would be needed.  My suggestion is to ask on python-ideas whether 
this enhancement might be accepted now and whether better to reopen this issue 
or open a new one.

--

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[paul rubin]

paul rubin  added the comment:

I just saw this.  Interesting.  Sometimes I use ast.literal_eval to read big, 
deeply nested data objects.  I can probably convert to JSON if necessary but 
it's another thing to watch out for.  I might try to benchmark some of these.

--
nosy: +phr

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
pull_requests: +19066
pull_request: https://github.com/python/cpython/pull/19744

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Lysandros Nikolaou]

Change by Lysandros Nikolaou :


--
pull_requests: +19065
pull_request: https://github.com/python/cpython/pull/19743

___
Python tracker 

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

[issue2190] MozillaCookieJar ignore HttpOnly cookies

[Daniel Lenski]

Daniel Lenski  added the comment:

Also confused about why this was closed.

This format is still frequently used. In the absence of a solution in the 
standard library, I'm using this kludge to strip the leading `#HttpOnly_`.


from tempfile import NamedTemporaryFile
from http.cookiejar import MozillaCookieJar
from contextlib import contextmanager

def fix_cookie_jar_file(orig_cookiejarfile):
with NamedTemporaryFile(mode='w+') as cjf:
with open(orig_cookiejarfile, 'r') as ocf:
for l in ocf:
cjf.write(l[10:] if l.startswith('#HttpOnly_') else l)
cjf.seek(0)
yield cjf.name

MozillaCookieJar(filename=fix_cookie_jar_file(orig_cookiejarfile))

--
nosy: +dlenski

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> The parser generator imports modules token and tokenize. It is not correct, 
> because they are relevant to the Python version used to run the parser 
> generator, and not to the Python version for which the parser is generated. 
> It works currently only because there is no differences between 3.8 and 3.9, 
> but it will fail when you add a new token or change/remove an old one.

Very good point, Serhiy! Thanks for catching that

So there are two parts of the parser generator where we use these modules:

- For the grammar parser and the python-based generator (that generates the 
grammar parser) we are good because we just need the modules to parse the 
grammars and generate the metaparser so there is no need for those modules to 
be updated. Running the grammar parser (the one generated with the 
meta-grammar) is also fine.

- For the C generator we need the current set of "exact_token_types" and in 
this case we need them to be synchronized with the Tokens file. I think we can 
do as pgen and take the path to that file as part of the command line interface 
and parse it.

I will make a PR for this soon.

--

___
Python tracker 

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

[issue39104] ProcessPoolExecutor hangs on shutdown nowait with pickling failure

[STINNER Victor]

STINNER Victor  added the comment:

> bpo-39104: Fix hanging ProcessPoolExecutor on shutdown nowait with pickling 
> failure (GH-17670)
> https://github.com/python/cpython/commit/a5cbab552d294d99fde864306632d7e511a75d3c

ProcessPoolSpawnProcessPoolExecutorTest.test_killed_child() of 
test_concurrent_futures started to fail randomly since this change: see 
bpo-39995.

--
nosy: +vstinner

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

It seems like test_killed_child() race condition was introduced by:

commit a5cbab552d294d99fde864306632d7e511a75d3c (refs/bisect/bad)
Author: Thomas Moreau 
Date:   Sun Feb 16 19:09:26 2020 +0100

bpo-39104: Fix hanging ProcessPoolExecutor on shutdown nowait with pickling 
failure (GH-17670)

--

___
Python tracker 

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

[issue40394] difflib.SequenceMatcher.find_longest_match default arguments

[Lewis Ball]

Lewis Ball  added the comment:

Oh okay, well I was just saying I have added a test which is unrelated to the 
feature I have added, but it does test a different part of the same function. 
Anyway, I have raised a PR for this now (19742) and can separate it out if 
needed.

--

___
Python tracker 

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

[issue40394] difflib.SequenceMatcher.find_longest_match default arguments

[Lewis Ball]

Change by Lewis Ball :


--
keywords: +patch
pull_requests: +19064
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19742

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

> ERROR: test_killed_child 
> (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest)

The patch below makes this test failure more likely:

diff --git a/Lib/multiprocessing/connection.py 
b/Lib/multiprocessing/connection.py
index 510e4b5aba..63518e55d9 100644
--- a/Lib/multiprocessing/connection.py
+++ b/Lib/multiprocessing/connection.py
@@ -370,6 +370,7 @@ class Connection(_ConnectionBase):
 def _send(self, buf, write=_write):
 remaining = len(buf)
 while True:
+time.sleep(0.050)
 n = write(self._handle, buf)
 remaining -= n
 if remaining == 0:

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

terminate_broken() method was added by:

commit 0e89076247580ba0e570c4816f0e5628a7e36e83
Author: Thomas Moreau 
Date:   Sun Mar 1 21:49:14 2020 +0100

bpo-39678: refactor queue manager thread (GH-18551)

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

> It seems like Connection.close() was called while Connection._send() was 
> called. I added debug logs:

The connection was closed by terminate_broken() called by 
_ExecutorManagerThread.run() thread:

test_killed_child 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 
close handle 4
  File "/home/vstinner/python/master/Lib/threading.py", line 908, in _bootstrap
self._bootstrap_inner()
  File "/home/vstinner/python/master/Lib/threading.py", line 950, in 
_bootstrap_inner
self.run()
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 
313, in run
self.terminate_broken(cause)
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 
456, in terminate_broken
self.join_executor_internals()
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 
503, in join_executor_internals
self.thread_wakeup.close()
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", line 
75, in close
self._writer.close()

--

___
Python tracker 

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

[issue40394] difflib.SequenceMatcher.find_longest_match default arguments

[Tim Peters]

Tim Peters  added the comment:

I'm not clear on exactly what it is you're asking, but it's better to ask for 
forgiveness than permission ;-)  That is, it's unlikely anyone will object to 
adding a test in a feature PR.

--
stage:  -> needs patch
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

[issue40394] difflib.SequenceMatcher.find_longest_match default arguments

[Lewis Ball]

Lewis Ball  added the comment:

Adding a test for this and noticed I can add one more test case to get the 
method to full coverage. Can I add that to this PR or should I raise a separate 
one?

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

ERROR: test_killed_child 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest)
  (...)
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/connection.py",
 line 373, in _send
n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

It seems like Connection.close() was called while Connection._send() was 
called. I added debug logs:

* self._handle was equal to 4 at the function entry
* self._handle was equal to None when write() was called

--

___
Python tracker 

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

[issue40410] test_multiprocessing_forktest_terminate() timed out after 15 min on s390x Fedora LTO + PGO 3.x

[STINNER Victor]

New submission from STINNER Victor :

s390x Fedora LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/460/builds/364

0:15:21 load avg: 0.00 [423/423/1] test_multiprocessing_fork crashed (Exit code 
1)
Timeout (0:15:00)!
Thread 0x03ff83dff910 (most recent call first):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/connection.py",
 line 384 in _recv
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/connection.py",
 line 419 in _recv_bytes
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/connection.py",
 line 255 in recv
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py",
 line 600 in _handle_results
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/threading.py",
 line 888 in run
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/threading.py",
 line 950 in _bootstrap_inner
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/threading.py",
 line 908 in _bootstrap

Thread 0x03ff976f8b20 (most recent call first):
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py",
 line 673 in _help_stuff_finish
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py",
 line 693 in _terminate_pool
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/util.py",
 line 224 in __call__
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/multiprocessing/pool.py",
 line 655 in terminate
  File 
"/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Lib/test/_test_multiprocessing.py",
 line 2546 in test_terminate
  (...)

--
components: Tests
messages: 367457
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_forktest_terminate() timed out after 15 min on 
s390x Fedora LTO + PGO 3.x
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

[issue40394] difflib.SequenceMatcher.find_longest_match default arguments

[Lewis Ball]

Lewis Ball  added the comment:

Okay, that makes sense. I will raise a PR

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

x86 Gentoo Installed with X 3.x:
https://buildbot.python.org/all/#/builders/128/builds/726

test_del_shutdown 
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ...

Warning -- Unraisable exception
Exception ignored in: .weakref_cb at 0xb5067898>
Traceback (most recent call last):
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/concurrent/futures/process.py",
 line 281, in weakref_cb
thread_wakeup.wakeup()
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/concurrent/futures/process.py",
 line 80, in wakeup
self._writer.send_bytes(b"")
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/multiprocessing/connection.py",
 line 205, in send_bytes
self._send_bytes(m[offset:offset + size])
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/multiprocessing/connection.py",
 line 416, in _send_bytes
self._send(header + buf)
  File 
"/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.9/multiprocessing/connection.py",
 line 373, in _send
n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

0.04s ok

--

___
Python tracker 

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

[issue40409] urllib.parse.urlsplit parses schemes that do not begin with letters

[Samani Gikandi]

Change by Samani Gikandi :


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

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

AMD64 Fedora Stable Clang Installed 3.x:
https://buildbot.python.org/all/#/builders/127/builds/679

0:04:21 load avg: 1.29 [423/423/1] test_concurrent_futures failed (2 min 39 sec)
Warning -- threading_cleanup() failed to cleanup -1 threads (count: 0, 
dangling: 3)
Warning -- Dangling thread: <_MainThread(MainThread, started 139673296918336)>
Warning -- Dangling thread: 
Warning -- Dangling thread: <_ExecutorManagerThread(Thread-145, stopped 
139673053914880)>
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 
3)
Warning -- Dangling thread: <_MainThread(MainThread, started 139673296918336)>
Warning -- Dangling thread: 
Warning -- Dangling thread: <_ExecutorManagerThread(Thread-145, stopped 
139673053914880)>
/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/resource_tracker.py:216:
 UserWarning: resource_tracker: There appear to be 5 leaked semaphore objects 
to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '
Warning -- multiprocessing.process._dangling was modified by 
test_concurrent_futures
Warning -- threading._dangling was modified by test_concurrent_futures
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_first_exception_some_already_complete 
(test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.60s ok
test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ... 
0.11s ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... 6.11s ok
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 300, in _run_finalizers
finalizer()
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 224, in __call__
res = self._callback(*self._args, **self._kwargs)
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py",
 line 87, in _cleanup
sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 300, in _run_finalizers
finalizer()
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 224, in __call__
res = self._callback(*self._args, **self._kwargs)
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py",
 line 87, in _cleanup
sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 300, in _run_finalizers
finalizer()
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 224, in __call__
res = self._callback(*self._args, **self._kwargs)
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py",
 line 87, in _cleanup
sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 300, in _run_finalizers
finalizer()
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 224, in __call__
res = self._callback(*self._args, **self._kwargs)
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py",
 line 87, in _cleanup
sem_unlink(name)
FileNotFoundError: [Errno 2] No such file or directory
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 300, in _run_finalizers
finalizer()
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/util.py",
 line 224, in __call__
res = self._callback(*self._args, **self._kwargs)
  File 
"/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/multiprocessing/synchronize.py",
 line 87, 

[issue40408] GenericAlias does not support nested type variables

[Guido van Rossum]

Guido van Rossum  added the comment:

Good catch. Is there a reasonable fix?

--

___
Python tracker 

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

[issue40409] urllib.parse.urlsplit parses schemes that do not begin with letters

[Samani Gikandi]

New submission from Samani Gikandi :

RFC 3986 (STD66) says that a URL scheme should begin with an "letter", however 
urllib.parse.urlsplit (and urlparse) parse strings that don't adhere to this as 
valid schemes.

Example from Python3.8 using "+git+ssh://g...@github.com/user/project.git":

>>> from urllib.parse import urlsplit, urlparse
>>> urlparse("+git+ssh://g...@github.com/user/project.git")
ParseResult(scheme='+git+ssh', netloc='g...@github.com', 
path='/user/project.git', params='', query='', fragment='')
>>> urlsplit("+git+ssh://g...@github.com/user/project.git")
SplitResult(scheme='+git+ssh', netloc='g...@github.com', 
path='/user/project.git', query='', fragment='')

I double checked this behavior and number of other languages (Rust, Go, 
Javascript, Ruby) all complain if you try to use parse this URL

For reference, RFC3986 section 3.1 --

Scheme names consist of a sequence of characters beginning with a
   letter and followed by any combination of letters, digits, plus
   ("+"), period ("."), or hyphen ("-"). 

   [...]

   scheme  = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

--
components: Library (Lib)
messages: 367452
nosy: sgg
priority: normal
severity: normal
status: open
title: urllib.parse.urlsplit parses schemes that do not begin with letters
type: behavior
versions: Python 3.5, Python 3.6, 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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

> See also bpo-30966 "Add multiprocessing.SimpleQueue.close()".

I pushed a commit 1a275013d1ecc2e3778d64fda86174b2f13d6969: 
"Process.shutdown(wait=True) of concurrent.futures now closes
explicitly the result queue."

test_shutdown_deadlock_pickle() still rely on the queue to be closed 
implicitly. Queue created at:

  (...)
  File "/home/vstinner/python/master/Lib/test/test_concurrent_futures.py", 
lineno 1196
with self.executor_type(max_workers=2,
  File "/home/vstinner/python/master/Lib/concurrent/futures/process.py", lineno 
637
self._result_queue = mp_context.SimpleQueue()
  File "/home/vstinner/python/master/Lib/multiprocessing/context.py", lineno 113
return SimpleQueue(ctx=self.get_context())
  File "/home/vstinner/python/master/Lib/multiprocessing/queues.py", lineno 341
self._reader, self._writer = connection.Pipe(duplex=False)
  File "/home/vstinner/python/master/Lib/multiprocessing/connection.py", lineno 
539
c2 = Connection(fd2, readable=False)

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

AMD64 Ubuntu Shared 3.x:
https://buildbot.python.org/all/#/builders/101/builds/809

==
ERROR: test_shutdown_no_wait 
(test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest)
--
Traceback (most recent call last):
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_concurrent_futures.py",
 line 542, in test_shutdown_no_wait
executor.shutdown(wait=False)
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py",
 line 724, in shutdown
self._executor_manager_thread_wakeup.wakeup()
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py",
 line 80, in wakeup
self._writer.send_bytes(b"")
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py",
 line 188, in send_bytes
self._check_closed()
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py",
 line 141, in _check_closed
raise OSError("handle is closed")
OSError: handle is closed

(...)
0:32:37 load avg: 1.64 Re-running test_concurrent_futures in verbose mode
(...)

==
ERROR: test_shutdown_no_wait 
(test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest)
--
Traceback (most recent call last):
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_concurrent_futures.py",
 line 542, in test_shutdown_no_wait
executor.shutdown(wait=False)
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py",
 line 724, in shutdown
self._executor_manager_thread_wakeup.wakeup()
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/concurrent/futures/process.py",
 line 80, in wakeup
self._writer.send_bytes(b"")
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py",
 line 205, in send_bytes
self._send_bytes(m[offset:offset + size])
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py",
 line 416, in _send_bytes
self._send(header + buf)
  File 
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py",
 line 373, in _send
n = write(self._handle, buf)
OSError: [Errno 9] Bad file descriptor

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 5d1f32d33ba24d0aa87235ae40207bb57778388b by Victor Stinner in 
branch 'master':
bpo-39995: Split test_concurrent_futures.test_crash() into sub-tests (GH-19739)
https://github.com/python/cpython/commit/5d1f32d33ba24d0aa87235ae40207bb57778388b


--

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The parser generator imports modules token and tokenize. It is not correct, 
because they are relevant to the Python version used to run the parser 
generator, and not to the Python version for which the parser is generated. It 
works currently only because there is no differences between 3.8 and 3.9, but 
it will fail when you add a new token or change/remove an old one.

It should either parse the correct Grammar/Tokens file, or read the content of 
corresponding files Lib/token.py and Lib/tokenize.py and evaluate them with 
eval(). See for example Tools/scripts/generate_token.py.

--

___
Python tracker 

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

[issue40381] plistlib doesn't handle poorly-formatted plists

[Ronald Oussoren]

Ronald Oussoren  added the comment:

IMHO this is a bug and plistlib should behave the same as Apple’s libraries 
here.

--

___
Python tracker 

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

[issue38728] Update PC/pyconfig.h to support disabling auto linking

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +19062
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19740

___
Python tracker 

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

[issue17013] Allow waiting on a mock

[Mario Corchero]

Mario Corchero  added the comment:

For the record, I have no strong preference over either implementation. 
@voidspace preferred offline the new mock class, but sadly the rationale is 
lost in the physical word.

--

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue30966] Add multiprocessing.queues.SimpleQueue.close()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 1a275013d1ecc2e3778d64fda86174b2f13d6969 by Victor Stinner in 
branch 'master':
bpo-30966: concurrent.futures.Process.shutdown() closes queue (GH-19738)
https://github.com/python/cpython/commit/1a275013d1ecc2e3778d64fda86174b2f13d6969


--

___
Python tracker 

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

[issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.

[Steve Dower]

Steve Dower  added the comment:

As a secondary issue, why didn't the installer fail on the pip failure? Did we 
decide at some point not to fail the whole thing just because of pip? (It's 
probably the most unreliable part, as it's a custom action rather than simple 
installation.)

--

___
Python tracker 

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

[issue40395] Scripts folder is Empty in python 3.8.2 for Windows 7.

[Steve Dower]

Steve Dower  added the comment:

Thanks for including logs!

It looks like pip ran into an issue during install:

C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_vendor\ipaddress.py:1106:
 SyntaxWarning: 'str' object is not callable; perhaps you missed a comma?
C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_vendor\ipaddress.py:1106:
 SyntaxWarning: 'str' object is not callable; perhaps you missed a comma?
Traceback (most recent call last):
  File "C:\Python\Python38-32\lib\runpy.py", line 193, in _run_module_as_main
return _run_code(code, main_globals, None,
  File "C:\Python\Python38-32\lib\runpy.py", line 86, in _run_code
exec(code, run_globals)
  File "C:\Python\Python38-32\lib\ensurepip\__main__.py", line 5, in 
sys.exit(ensurepip._main())
  File "C:\Python\Python38-32\lib\ensurepip\__init__.py", line 200, in _main
return _bootstrap(
  File "C:\Python\Python38-32\lib\ensurepip\__init__.py", line 119, in 
_bootstrap
return _run_pip(args + , additional_paths)
  File "C:\Python\Python38-32\lib\ensurepip\__init__.py", line 27, in _run_pip
import pip._internal
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\__init__.py",
 line 40, in 
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\cli\autocompletion.py",
 line 8, in 
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\cli\main_parser.py",
 line 7, in 
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\cli\cmdoptions.py",
 line 24, in 
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\models\search_scope.py",
 line 11, in 
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_internal\utils\misc.py",
 line 21, in 
  File "", line 259, in load_module
  File 
"C:\Users\\AppData\Local\Temp\tmpppkvx8p2\pip-19.2.3-py2.py3-none-any.whl\pip\_vendor\pkg_resources\__init__.py",
 line 35, in 
  File "C:\Python\Python38-32\lib\plistlib.py", line 65, in 
from xml.parsers.expat import ParserCreate
  File "C:\Python\Python38-32\lib\xml\parsers\expat.py", line 4, in 
from pyexpat import *
ImportError: DLL load failed while importing pyexpat: The specified module 
could not be found.
Error 0x80070001: Command line returned an error.
Error 0x80070001: QuietExec Failed

However, as far as I can tell, all the dependencies it needs were installed. So 
the most likely cause is a virus scanner interfering. (Unless Python does not 
work for you at all, though that is still likely to be a scanner, since the 
setup logs seem fine.)

The easiest fix will be to disable your virus scanner and run a Repair install. 
That should make sure that everything is installed. If pip is the only thing 
missing, you could also run "python -m ensurepip" as admin.

--

___
Python tracker 

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

[issue30966] Add multiprocessing.queues.SimpleQueue.close()

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +19060
pull_request: https://github.com/python/cpython/pull/19738

___
Python tracker 

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

[issue40402] Race condition in multiprocessing/connection.py: broken handle

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I don't know if a try..except block is the best solution, but feel free to 
submit a PR and we can iterate on that :-)

--
stage:  -> needs patch

___
Python tracker 

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

[issue32117] Tuple unpacking in return and yield statements

[Roundup Robot]

Change by Roundup Robot :


--
nosy: +python-dev
nosy_count: 6.0 -> 7.0
pull_requests: +19059
pull_request: https://github.com/python/cpython/pull/19737

___
Python tracker 

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

[issue40402] Race condition in multiprocessing/connection.py: broken handle

[Rémi Lapeyre]

Rémi Lapeyre  added the comment:

A call to self._check_closed() is already present in Python 3.5 
https://github.com/python/cpython/blob/3.5/Lib/multiprocessing/connection.py#L202-L206

It is possible for some issues to appear when mixing multiprocessing and 
multithreading thought:

In [17]: from time import sleep 
...: import multiprocessing, threading 
...:  
...: class Test: 
...: def __reduce__(self): 
...: sleep(1) 
...: return (Test, ()) 
...:  
...: parent, child = multiprocessing.Pipe() 
...: threading.Thread(target=lambda: parent.send(Test())).start() 
...: parent.close() 


Exception in thread Thread-7:
Traceback (most recent call last):
  File "/Users/remi/src/cpython/Lib/threading.py", line 950, in _bootstrap_inner
self.run()
  File "/Users/remi/src/cpython/Lib/threading.py", line 888, in run
self._target(*self._args, **self._kwargs)
  File "", line 10, in 
/Users/remi/src/cpython/venv/lib/python3.9/site-packages/prompt_toolkit/renderer.py:514:
 DeprecationWarning: The explicit passing of coroutine objects to 
asyncio.wait() is deprecated since Python 3.8, and scheduled for removal in 
Python 3.11.
  await wait(coroutines, return_when=FIRST_COMPLETED)
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 211, 
in send
self._send_bytes(_ForkingPickler.dumps(obj))
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 416, 
in _send_bytes
self._send(header + buf)
  File "/Users/remi/src/cpython/Lib/multiprocessing/connection.py", line 373, 
in _send
n = write(self._handle, buf)
TypeError: an integer is required (got type NoneType)



Maybe using a try-catch block could be more appropriate than the current check.

CC-ing Antoine Pitrou as he is the original author of this part in 
87cf220972c9cb400ddcd577962883dcc5dca51a. If you are OK with replacing calls to 
self._check_closed() by an exception block I would be happy to open a PR for 
this.

--
components: +Library (Lib)
nosy: +pitrou
title: multiprocessing/connection.py broken handle -> Race condition in 
multiprocessing/connection.py: broken handle
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset b94dbd7ac34dc0c79512656eb17f6f07e09fca7a by Pablo Galindo in 
branch 'master':
bpo-40334: Support PyPARSE_DONT_IMPLY_DEDENT in the new parser (GH-19736)
https://github.com/python/cpython/commit/b94dbd7ac34dc0c79512656eb17f6f07e09fca7a


--

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
pull_requests: +19058
pull_request: https://github.com/python/cpython/pull/19736

___
Python tracker 

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

[issue40334] PEP 617: new PEG-based parser

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 2b74c835a7280840a853e3a9aaeb83758b13a458 by Pablo Galindo in 
branch 'master':
bpo-40334: Support CO_FUTURE_BARRY_AS_BDFL in the new parser (GH-19721)
https://github.com/python/cpython/commit/2b74c835a7280840a853e3a9aaeb83758b13a458


--

___
Python tracker 

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

[issue40405] asyncio.as_completed documentation misleading

[Guido van Rossum]

Guido van Rossum  added the comment:

Oh, you're right. The docstring correctly says this. :-(

Do you have the power to submit a PR? I think it should just say that the 
return values are coroutines (which is what it does). @Yury what do you think?

--
resolution: not a bug -> 

___
Python tracker 

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

[issue40360] Deprecate lib2to3 (and 2to3) for future removal

[Peter Ludemann]

Change by Peter Ludemann :


--
nosy: +Peter Ludemann

___
Python tracker 

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

[issue40405] asyncio.as_completed documentation misleading

[Bar Harel]

Bar Harel  added the comment:

It's a coroutine. Basically the same coroutine yielded over and over, returning 
the first future's result each time.
Like I said, I'm not entirely sure how to phrase it.
Maybe "Returns an iterator of awaitables"?

--

___
Python tracker 

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

[issue40405] asyncio.as_completed documentation misleading

[Guido van Rossum]

Guido van Rossum  added the comment:

Reopening so as to give the OP one more chance to state their case. They wrote:

"""
You've immediately closed the issue so I couldn't even reply to it,
Unfortunately, it doesn't return a Future object at all, so technically you're 
wrong, together with the docs of course, which was the bug I reported...
"""

If it's not a Future then what? You're not showing that in your report.

--
status: closed -> open

___
Python tracker 

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

[issue30966] Add multiprocessing.queues.SimpleQueue.close()

[miss-islington]

miss-islington  added the comment:


New changeset 9adccc1384568f4d46e37f698cb3e3a4f6ca0252 by Victor Stinner in 
branch 'master':
bpo-30966: Add multiprocessing.SimpleQueue.close() (GH-19735)
https://github.com/python/cpython/commit/9adccc1384568f4d46e37f698cb3e3a4f6ca0252


--
nosy: +miss-islington

___
Python tracker 

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

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-30966 "Add multiprocessing.SimpleQueue.close()".

--

___
Python tracker 

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

[issue30966] Add multiprocessing.queues.SimpleQueue.close()

[STINNER Victor]

Change by STINNER Victor :


--
title: multiprocessing.queues.SimpleQueue leaks 2 fds -> Add 
multiprocessing.queues.SimpleQueue.close()

___
Python tracker 

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

[issue40408] GenericAlias does not support nested type variables

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

While trying to replace typing._GenericAlias with GenericAlias I have found 
that the latter does not support nested type variables.

>>> from typing import *
>>> T = TypeVar('T')
>>> X = List[List[T]]
>>> X.__parameters__
(~T,)
>>> X[int]
typing.List[typing.List[int]]
>>> Y = list[list[T]]
>>> Y.__parameters__
()
>>> Y[int]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: There are no type variables left in list[list[~T]]

--
components: Interpreter Core
messages: 367433
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: GenericAlias does not support nested type variables
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

[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

[STINNER Victor]

STINNER Victor  added the comment:

bpo-23267 is marked as a duplicate of this issue.

--

___
Python tracker 

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

[issue18999] Support different contexts in multiprocessing

[STINNER Victor]

STINNER Victor  added the comment:

It seems like this issue has been fixed, so I set its status to closed.

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

___
Python tracker 

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

[issue40405] asyncio.as_completed documentation misleading

[Guido van Rossum]

Guido van Rossum  added the comment:

I declare this not a bug.

The docs do not promise that the Futures being returned are the *same* Futures 
that were passed in. They are not. They are (or at least may be) new Futures 
that represent the same event. Since Futures, when used as dict keys, use 
identity as equality, those new Futures will not be present as keys in the 
mapping of Futures passed in by the OP.

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

[issue30966] multiprocessing.queues.SimpleQueue leaks 2 fds

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

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

[issue40407] Zipfile couldn`t recognized character set rightly.

[김지훈]

New submission from 김지훈 :

Hi,

I am not a developer.
However, when I inquired about an abnormality of an open source program before,
it was said that there was a problem with the Zipfile module of Python.
So I would like to ask it here.

I`m a Korean, and a Windows user.
And there are useful Windows compression programs in Korea.
However, when using those compression programs, Debian's unzip utility finds 
character sets well, but fails to find in the case of python.

If you look at the attached file,
(File size is too large, so attach it elsewhere - https://kutt.it/2F2Xec)
there are other compressed files in the compressed file.
The names in the compressed file are the names of the compressed programs.

And, as I have seen, the result of the basic compression is:
7zip : UTF-8
Alzip : UTF-8
BandiZip : EUC-KR
BreadZip : EUC-KR
PKZip : UTF-8
StarZip : EUC-KR
WinRAR : UTF-8
WinZIP : EUC-KR
Zipware : EUC-KR

BandiZip and Alzip are the two programs that compete in Korea.
I use BandiZip with few ads and this supports multi-core for compression.
StarZip is also a Korean program, but its share is not high.
BreadZip is also a Korean program, which has been used a lot, but has been 
discontinued and used only for some people.

Anyway, it can be considered that compression softwares in Korea use both 
EUC-KR and UTF-8 formats. However, the Zipfile module does not recognize this 
properly.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 367429
nosy: 김지훈
priority: normal
severity: normal
status: open
title: Zipfile couldn`t recognized character set rightly.
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

[issue40375] Add the UNSELECT command to imaplib

[Dong-hee Na]

Dong-hee Na  added the comment:

I am now closing this issue.

Thank you Eric and Victor for the review!

--
nosy: +vstinner
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

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

I opened a PR to revert the change. issue25597 was open for sometime and the 
implications as reported here seem to be greater than the original report to 
just call the magicmethod. So we can revert the change to ensure there are no 
regressions in Python 3.9 for first beta and discuss the behavior for a later 
release.

--

___
Python tracker 

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

[issue40375] Add the UNSELECT command to imaplib

[Dong-hee Na]

Dong-hee Na  added the comment:


New changeset c5c42815ecb560bbf34db99b0e15fe9b604be889 by Dong-hee Na in branch 
'master':
bpo-40375: Implement imaplib.IMAP4.unselect (GH-19712)
https://github.com/python/cpython/commit/c5c42815ecb560bbf34db99b0e15fe9b604be889


--

___
Python tracker 

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

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
pull_requests: +19055
pull_request: https://github.com/python/cpython/pull/19734

___
Python tracker 

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

[issue25597] unittest.mock does not wrap dunder methods (__getitem__ etc)

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
pull_requests: +19056
pull_request: https://github.com/python/cpython/pull/19734

___
Python tracker 

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

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 91a5ae18351027867e99c96db5ea235d9c42e47a by Pablo Galindo in 
branch 'master':
bpo-40217: Clean code in PyType_FromSpec_Alloc and add NEWS entry (GH-19733)
https://github.com/python/cpython/commit/91a5ae18351027867e99c96db5ea235d9c42e47a


--

___
Python tracker 

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

[issue40406] MagicMock __aenter__ should be AsyncMock(return_value=MagicMock())

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +lisroach, xtreak
type:  -> behavior

___
Python tracker 

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

[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type

[Łukasz Langa]

Łukasz Langa  added the comment:

Please backport to 3.8, then it will become part of 3.8.3rc1 which I'll be 
releasing tomorrow.

--
nosy: +lukasz.langa

___
Python tracker 

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