[issue22662] subprocess.Popen.communicate causing local tty terminal settings to change inconsistently
New submission from Kyle: I'm not sure if this is a bash or Python issue. I'm trying to run a command on a remote server, using the subprocess module. I call ssh inside of subprocess.Popen(...).communicate(), like so: output = subprocess.Popen(["/bin/env %s /usr/bin/ssh -ttt %s@%s -- %s;" % (env, user, host, command)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True).communicate() Following the call to communicate(), my terminal settings are changed. However, it's not always repeatable. Sometimes it happens, and other times it does not. When it does happen, I've noticed that the following tty options are ON prior to the command executing, and OFF afterwards (output from stty -a): icrnl opost isig icanon echo echoe echok Something with the communicate() call seems to cause the issue. I don't actually have to print anything to the screen from Python for it to occur. The problem goes away if I remove the "-t" option to ssh, however, I'm passing through the TERM environmental variable, and need -t to be set. Because of this, I'm not sure if the problem is with the Python call, or something within Bash. I've been able to repeat this on Ubuntu 13.10 running Python 2.7.5, and on Red Hat 6.4 running Python 2.6.6. -- messages: 229602 nosy: kflavin priority: normal severity: normal status: open title: subprocess.Popen.communicate causing local tty terminal settings to change inconsistently type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue22662> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] BaseManager.register no longer supports lambda callable 3.8.12+
New submission from Kyle Smith :
The below code works on versions 3.5.2 to 3.8.10. Higher versions tested, such
as 3.9.12 and 3.10.2 result in the error:
"AttributeError: Can't pickle local object".
from multiprocessing import Lock
from multiprocessing.managers import AcquirerProxy, BaseManager, DictProxy
def get_shared_state(host, port, key):
shared_dict = {}
shared_lock = Lock()
manager = BaseManager((host, port), key)
manager.register("get_dict", lambda: shared_dict, DictProxy)
manager.register("get_lock", lambda: shared_lock, AcquirerProxy)
try:
manager.get_server()
manager.start()
except OSError: # Address already in use
manager.connect()
return manager.get_dict(), manager.get_lock()
HOST = "127.0.0.1"
PORT = 35791
KEY = b"secret"
shared_dict, shared_lock = get_shared_state(HOST, PORT, KEY)
shared_dict["number"] = 0
shared_dict["text"] = "Hello World"
This code was pulled from this article:
https://stackoverflow.com/questions/57734298/how-can-i-provide-shared-state-to-my-flask-app-with-multiple-workers-without-dep/57810915#57810915
I looked around and couldn't find any open or closed bugs for this, so I'm
sorry in advance if this is new expected behavior.
--
components: Interpreter Core
messages: 414137
nosy: kyle.smith
priority: normal
severity: normal
status: open
title: BaseManager.register no longer supports lambda callable 3.8.12+
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue46871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] BaseManager.register no longer supports lambda callable 3.8.12+
Kyle Smith added the comment:
Interesting. I did try between MacOS (12.2) and Ubuntu since I have servers
with older python versions. For scoping then, this appears to be related only
to MacOS since you were able to confirm it working correctly on Linux.
The code is the same, but here's the entire traceback. All below examples were
run on MacOS:
bash-3.2$ python3 --version
Python 3.9.6
bash-3.2$ python3 main.py
Traceback (most recent call last):
File "/Volumes/Workspace/co/router/main.py", line 21, in
shared_dict, shared_lock = get_shared_state(HOST, PORT, KEY)
File "/Volumes/Workspace/co/router/main.py", line 12, in get_shared_state
manager.start()
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/managers.py",
line 553, in start
self._process.start()
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/process.py",
line 121, in start
self._popen = self._Popen(self)
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py",
line 284, in _Popen
return Popen(process_obj)
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py",
line 32, in __init__
super().__init__(process_obj)
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_fork.py",
line 19, in __init__
self._launch(process_obj)
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/popen_spawn_posix.py",
line 47, in _launch
reduction.dump(process_obj, fp)
File
"/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/reduction.py",
line 60, in dump
ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'get_shared_state..'
Running this with 3.7.9 works:
bash-3.2$ python3.7 --version
Python 3.7.9
bash-3.2$ python3.7 main.py
{'number': 0, 'text': 'Hello World'}
If it's of interest, 3.10.2 is also failing on Mac.
bash-3.2$ /usr/local/opt/python\@3.10/bin/python3 --version
Python 3.10.2
bash-3.2$ /usr/local/opt/python\@3.10/bin/python3 main.py
Traceback (most recent call last):
File "/Volumes/Workspace/co/router/main.py", line 21, in
shared_dict, shared_lock = get_shared_state(HOST, PORT, KEY)
File "/Volumes/Workspace/co/router/main.py", line 12, in get_shared_state
manager.start()
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/managers.py",
line 562, in start
self._process.start()
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/process.py",
line 121, in start
self._popen = self._Popen(self)
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/context.py",
line 284, in _Popen
return Popen(process_obj)
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/popen_spawn_posix.py",
line 32, in __init__
super().__init__(process_obj)
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/popen_fork.py",
line 19, in __init__
self._launch(process_obj)
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/popen_spawn_posix.py",
line 47, in _launch
reduction.dump(process_obj, fp)
File
"/usr/local/Cellar/[email protected]/3.10.2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/multiprocessing/reduction.py",
line 60, in dump
ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object 'get_shared_state..'
--
___
Python tracker
<https://bugs.python.org/issue46871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] BaseManager.register no longer supports lambda callable 3.8.12+
Kyle Smith added the comment:
Since you were able to help me scope that this is probably an MacOS specific
issue, I was able to find this report:
https://github.com/pytest-dev/pytest-flask/issues/104
Setting `multiprocessing.set_start_method("fork")` _BEFORE_ the code is called
resolves this.
I don't understand enough of MP to understand why this is a problem, and why I
need to do this, but alas, at least I have a path forward.
Since this behavior changed, and it _doesn't_ work cleanly anymore with MacOS,
I would say this is a bug (from my casual understanding of python), because
it's mentioned in the documentation that using "fork" can be problematic and
lead to crashes outlined in bpo-33725.
> Changed in version 3.8: On macOS, the spawn start method is now the default.
> The fork start method should be considered unsafe as it can lead to crashes
> of the subprocess. See bpo-33725.
--
___
Python tracker
<https://bugs.python.org/issue46871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Change by Kyle Smith : -- title: BaseManager.register no longer supports lambda callable 3.8.12+ -> Lambda can't be pickled with "spawn" and only "fork" ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Kyle Smith added the comment: I think that's fair, thanks for the conversation at least. I understand python mp a little bit more now... -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Change by Kyle Smith : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12129] Document Object Model API - validation
Kyle Keating added the comment:
This looks to break pretty good... I did confirm this on 3.0, I'm guessing 3.2
is the same.
import sys
import xml.dom
doc = xml.dom.getDOMImplementation().createDocument(None, 'xml', None)
doc.firstChild.appendChild(doc.createElement('element00'))
element01 = doc.createElement('element01')
element01.setAttribute('attribute',
"script>")
doc.firstChild.appendChild(element01)
element02 = doc.createElement("script>")
doc.firstChild.appendChild(element02)
element03 = doc.createElement("new line \n")
element03.setAttribute('attribute-name','new line \n')
doc.firstChild.appendChild(element03)
print doc.toprettyxml(indent=" ")
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
output:
<![CDATA[alert('script!');]]>/>
--
___
Python tracker
<http://bugs.python.org/issue12129>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12129] Document Object Model API - validation
Kyle Keating added the comment: oops, the first xml element in the output should read "" not "" just a typo! don't get confused! -- ___ Python tracker <http://bugs.python.org/issue12129> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12825] Missing and incorrect link to a command line option.
New submission from Kyle Simpson : The documentation for the runpy module has a link to the -m command line option. In version 2.7.2 of the docs, the link doesn't exist. http://docs.python.org/release/2.7/library/runpy.html http://docs.python.org/release/2.7.2/library/runpy.html If you run touch library/runpy.rst make html then the link is created, but with an anchor of "cmdoption-unittest-discover-m" instead of "cmdoption-m". http://docs.python.org/release/2.7.2/using/cmdline.html#cmdoption-unittest-discover-m -- assignee: docs@python components: Documentation messages: 142797 nosy: Kyle.Simpson, docs@python priority: normal severity: normal status: open title: Missing and incorrect link to a command line option. versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12825> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing using docs cross-references
Changes by Kyle Simpson : -- nosy: +Kyle.Simpson ___ Python tracker <http://bugs.python.org/issue12602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12129] Document Object Model API - validation
New submission from Kyle Keating :
I was doing some tests on using this library and I noticed xml elements and
attribute names could be created with mal-formed xml because special characters
which can break validation are not cleaned or converted from their literal
forms. Only the attribute values are cleaned, but not the names.
For example
import xml.dom
...
doc.createElement("p>")
...
will just embed a pair of p tags in the xml result. I thought that the xml spec
did not permit <, >, &, \n etc. in the element name or attribute name? Could I
get some clarification on this, thanks!
--
components: Library (Lib)
messages: 136402
nosy: Kyle.Keating
priority: normal
severity: normal
status: open
title: Document Object Model API - validation
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12129>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3819] urllib2 sends Basic auth across redirects
New submission from Kyle McFarland <[EMAIL PROTECTED]>: when you request a url that requests Basic authentication info HTTPBasicAuthHandler adds the Authorization header to the request as a normal (not unredirected) header, then if the server returns a 301 or 302 redirect HTTPRedirectHandler will send a request to the redirected address keeping the normal headers including the Authorization header HTTPBasicAuthHandler added, I'll attach the code I used to test this. GET from libwww-perl seems to do this but most browsers don't seem to by default and although I can't find much in the RFCs about how redirecting is supposed to work wrt. auth headers (feel free to point out sections if I'm blind) I think it breaks ftp://ftp.isi.edu/in-notes/rfc2617.txt somewhat (section 1.1, """ The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server. """) since redirects can point to arbitrary urls off of the server. as in bug #1480067 just adding the header as an unredirected header would stop the header being sent across redirects if that's indeed the proper behaviour. -- components: Library (Lib) files: test.py messages: 72871 nosy: TFKyle severity: normal status: open title: urllib2 sends Basic auth across redirects Added file: http://bugs.python.org/file11441/test.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3819] urllib2 sends Basic auth across redirects
Changes by Kyle McFarland <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11442/untest.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3819] urllib2 sends Basic auth across redirects
Changes by Kyle McFarland <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11443/bug3819.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8235] Support FreeBSD's SO_SETFIB in socketmodule.c
New submission from Kyle VanderBeek : FreeBSD has a [gs]etsockopt() constant used to cause a given socket to use an alternate routing table (FIB); it appeared in FreeBSD 7.1. It would be useful to have this exposed as a constant in the socket module to allow special routing rules in complex environments. -- components: Extension Modules files: python-SO_SETFIB.patch keywords: patch messages: 101736 nosy: kylev severity: normal status: open title: Support FreeBSD's SO_SETFIB in socketmodule.c type: feature request versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file16662/python-SO_SETFIB.patch ___ Python tracker <http://bugs.python.org/issue8235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8086] ssl.get_server_certificate new line missing
Changes by Kyle VanderBeek : -- keywords: +patch Added file: http://bugs.python.org/file16672/python-ssl-PEM_FOOTER.patch ___ Python tracker <http://bugs.python.org/issue8086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8086] ssl.get_server_certificate new line missing
Kyle VanderBeek added the comment: Forgot to note that my patch is against 2.7 current trunk. -- nosy: +kylev ___ Python tracker <http://bugs.python.org/issue8086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Kyle VanderBeek added the comment: Ping? Is anyone working on this? Have Eric's concerns been addressed and can we pickle/unpickle all exceptions yet? -- nosy: +kylev ___ Python tracker <http://bugs.python.org/issue1692335> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4310] Comparison of two ints returns wrong result
New submission from Kyle Brandt <[EMAIL PROTECTED]>: The attached program returns a false result on one of my computers with a Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz processor. Is seems the comparison of two int does not perform correctly. I have python 2.5.2 and 2.6.27-7-generic kernel. The lines of interest are 89-71: print type(f_p),type(largest),f_p,largest if f_p > largest: print 'foo' largest = f_p When running this code: # python id_11-2.py | grep 70600 70600674 51267216 # python id_11-2.py | grep foo #doesn't return anything When I run the same code on another machine the end result of the program is 70600674, whereas my current machine the end result is 51267216. -- files: id_11-2.py messages: 75794 nosy: kbrandt severity: normal status: open title: Comparison of two ints returns wrong result type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file11996/id_11-2.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4310> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47260] os.closerange() can be no-op in a seccomp sandbox
Kyle Evans added the comment: Sure, sounds good to me. The original theory (IIRC, I've slept many times since then :-)) was that we already know first/last are valid and there are no other defined errors, so 'other errors' must be because close_range has started percolating up something from closing individual files. It's been years now and that hasn't happened, even with more recent flag additions. I think it's safe to say it won't, and such a fallback upon error won't put us back into a bogus pre-close_range situation where we're needlessly close()ing a bunch of closed fds. -- ___ Python tracker <https://bugs.python.org/issue47260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Kyle Stanley added the comment: > This is already backported to 3.6. I am not sure about what gets backported > to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which > made me think we are discouraged to backport to 3.5). I can work on a manual > backport if needed? As far as I'm aware, backports to 3.5 have to be manually approved by those with repository management permissions, such the the organization owners (https://devguide.python.org/devcycle/#current-owners) and admins (https://devguide.python.org/devcycle/#current-administrators) -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
New submission from Kyle Stanley : Last month, several tests were moved into test_importlib (https://bugs.python.org/issue19696): "test_pkg_import.py", "test_threaded_import.py", and "threaded_import_hangers.py". Those tests were created quite a while ago though and do not currently utilize importlib directly. They should be updated accordingly. Brett Cannon: > BTW, if you want to open a new issue and modernize the tests to use importlib > directly that would be great! I'm interested in helping with this issue, but I may require some assistance as I'm not overly familiar with the internals of importlib. I'll probably start with "test_pkg_import.py". Anyone else can feel free to work on the other two in the meantime, but they should be worked on together as "threaded_import_hangers.py" is a dependency for "test_threaded_import.py". -- components: Tests messages: 349984 nosy: aeros167, brett.cannon priority: normal severity: normal status: open title: Modernize several tests in test_importlib versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Kyle Stanley added the comment:
I'm not entirely certain as to which parts should be modernized, and which ones
can remain the same. A large part of my uncertainty is that there are no header
comments for "test_pkg_import.py" to explain the test coverage, so I don't know
if there are additional tests beyond the existing ones that should be added.
The first steps I can think of:
1) Use ``importlib.import_module()`` instead of the built-in ``__import__()``
2) Use ``with self.assertRaises(, ): ...`` instead of
```
try: __import__(self.module_name)
except SyntaxError: pass
else: raise RuntimeError('Failed to induce SyntaxError') # self.fail()?
...
```
3) Replace ``self.assertEqual(getattr(module, var), 1)`` with
``self.assertEqual(getattr(module, var, None), 1)`` so that AttributeErrors are
not raised when unexpected behaviors occur
4) Provide useful error messages for failed assertions
I'll begin working on those, probably with a separate PR for each of them for
ease of review. Let me know if there's anything else I should do, or if any of
the above steps are unneeded. If I think of anything else I'll update the issue
accordingly.
--
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Change by Kyle Stanley : -- nosy: +eric.snow, ncoghlan ___ Python tracker <https://bugs.python.org/issue37890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Change by Kyle Stanley : -- stage: -> needs patch type: -> enhancement ___ Python tracker <https://bugs.python.org/issue37890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Kyle Stanley added the comment:
Ah okay, I wasn't sure what exactly would be involved with the "modernization"
process, so those points were just rough ideas more than anything. I haven't
started working on anything yet since I figured it'd be worthwhile to wait for
approval first.
> 1) __import__() can be used for purpose. I would not change this.
Okay, I'll keep that part as is then. This idea was primarily based on
importlib's documentation:
"Programmatic importing of modules should use import_module() instead of
[importlib.__import__()]"
But that probably applies more to users of importlib, rather than the internal
tests for it. That would make sense.
3) How would you distinguish the case when the module have an attribute with
the value is None and when it does not have the attribute at all? This
information would lost with your change.
Good point. This might be a decent way to prevent the AttributeErrors, but
still allows for differentiation of actual None values:
```
try:
self.assertEqual(getattr(module, var), 1)
except AttributeError:
self.fail(f"{module} should have attribute {var}")
```
Personally I think it makes a bit more sense to use self.fail() with a helpful
message rather than raising errors within the tests. There's a comment on line
56, "# self.fail() ?", which gave me this idea. Is there a particular
preference in the context of Python's tests?
Also, do either of you (or anyone else) have any ideas for other modernization
improvements that could be made to either test_pkg_import.py or to the other
two? In the meantime, I can start working on ideas (2) and (4) if those ones
would be appropriate. (2) should be fairly straightforward, but (4) will
probably be a bit more subjective.
--
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Kyle Stanley added the comment:
> This might be a decent way to prevent the AttributeErrors, but still allows
> for differentiation of actual None values
Another alternative solution might be to use hasattr() before getattr(), if it
is not desirable for test_pkg_import.py to raise exceptions:
```
self.assertTrue(hasattr(module, var), msg=f"{module} should have attribute
{var}")
self.assertEqual(getattr(module, var), 1)
```
That would follow more of a LBYL style, but I know that EAFP is more common
within Python. The better alternative depends on the answer to my earlier
question regarding exceptions being raised from the unit tests:
> Is there a particular preference in the context of Python's tests?
--
___
Python tracker
<https://bugs.python.org/issue37890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Kyle Stanley added the comment: > A key question here is why are you trying to avoid the AttributeError case so > much? > but there's a reason that we don't have attribute existence tests before > every single attribute access throughout the test suite Hmm, good point. I may have been fixating on avoiding exceptions within the tests a bit too much, perhaps the exception would be appropriate in this case. > Basically unless the attribute is dynamic and thus you're explicitly testing > the attribute got set then don't worry about it. Ah, that answers my earlier question, thanks. (: With an initial glance, do you have any specific ideas as to how test_pkg_import.py should be changed to utilize importlib directly? I've been reading through the docs looking for ideas, but I'll admit that I'm not particularly experienced with using importlib. -- ___ Python tracker <https://bugs.python.org/issue37890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37890] Modernize several tests in test_importlib
Kyle Stanley added the comment: > I would just read through the other tests files under test_importlib to see > how other tests were done. Okay, I'll start with that and report back with any ideas for potential changes to test_pkg_import. Thanks. -- ___ Python tracker <https://bugs.python.org/issue37890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37585] Comparing PyDictValues does not give expected results
Kyle Stanley added the comment: Reopening the issue for adding the documentation clarification, that comparing the values view of two dictionaries will always return false (as was suggested in the ML discussion https://mail.python.org/archives/list/[email protected]/message/K3SYX4DER3WAOWGQ4SPKCKXSXLXTIVAQ/). A month ago, I opened to PR to add the clarification to the documentation for dict.values(): https://github.com/python/cpython/pull/14954/files. It probably went unnoticed because the issue had already been closed (which I hadn't realized at the time). -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue37585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37585] Comparing PyDictValues does not give expected results
Change by Kyle Stanley : -- stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issue37585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
New submission from Kyle Stanley : In the documentation for the NotImplemented constant (https://docs.python.org/3/library/constants.html#NotImplemented), the only use case mentioned is for binary special methods, (such as object.__eq__(other)). However, based on a conversation in a recent PR (https://github.com/python/cpython/pull/15327#discussion_r316561140), there seems be several other use cases as well. It's quite useful to utilize when it's desired to express that a particular operation is not supported, without raising an error. Expanding upon the use cases will provide readers an idea of other cases in which the constant could be useful. Also, the current wording could potentially come across as implying that the _only_ use case for the constant is for binary special methods, and as far as I'm aware, that is not the case. -- assignee: docs@python components: Documentation keywords: easy messages: 350333 nosy: aeros167, docs@python, eric.araujo, ezio.melotti, mdk, willingc priority: normal severity: normal stage: needs patch status: open title: Docs: Clarify NotImplemented use cases type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
Kyle Stanley added the comment: > python-dev likely isn't the right place. That is a forum for more mature > ideas. Agreed, that idea should be posted to python-list if they're having issues posting to python-ideas. Python-dev certainly wouldn't be appropriate for that. -- ___ Python tracker <https://bugs.python.org/issue37812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
Change by Kyle Stanley : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue37812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
Kyle Stanley added the comment: > May I suggest directing your efforts towards fixing known bugs or > implementing requested features. It isn't our goal to create more work for > one another There frequently is value in improving code readability, as it can improve maintainability in the long term, but I definitely understand your point. -- ___ Python tracker <https://bugs.python.org/issue37812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34679] asyncio.add_signal_handler call fails if not on main thread
Kyle Stanley added the comment: > Skipping this call for non-main thread in proactor implementation makes sense. How do we identify whether or not set_wakeup_fd() is being called from a non-main thread? -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue34679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34679] asyncio.add_signal_handler call fails if not on main thread
Kyle Stanley added the comment: > How do we identify whether or not set_wakeup_fd() is being called from a > non-main thread? Never mind, I think I found the answer to my own question and tested a patch locally, I'll open a PR. -- ___ Python tracker <https://bugs.python.org/issue34679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34679] asyncio.add_signal_handler call fails if not on main thread
Change by Kyle Stanley : -- keywords: +patch pull_requests: +15163 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15477 ___ Python tracker <https://bugs.python.org/issue34679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34679] asyncio.add_signal_handler call fails if not on main thread
Change by Kyle Stanley : -- keywords: +needs review -patch ___ Python tracker <https://bugs.python.org/issue34679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34679] asyncio.add_signal_handler call fails if not on main thread
Kyle Stanley added the comment: > Kyle, thanks for the fix. > I have basically the same change in my PR but with test and news note. No problem, that works for me. I was mostly just trying to help with resolving some of the release blockers for 3.8b4. -- ___ Python tracker <https://bugs.python.org/issue34679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23933] Struct module should accept arrays
Change by Kyle Stanley : -- nosy: +mark.dickinson, meador.inge ___ Python tracker <https://bugs.python.org/issue23933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Kyle Stanley added the comment: Thanks for the feedback Vedran and Raymond. > It is not the purpose of the docs to list use cases. Mostly we say what > something does or how it is defined. As Vedran says, how people use it is > their own business. The underlying issue here seems to be that I misunderstood the existing section to suggest to suggest binary special methods are the only use case, which is probably a good argument in favor of not listing additional use cases. This can be misinterpreted as suggesting that others are not recommended, and lead to further confusion. First sentence of the NotImplemented documentation: > Special value which should be returned by the binary special methods (e.g. > __eq__(), __lt__(), __add__(), __rsub__(), etc.) to indicate that the > operation is not implemented with respect to the other type; may be returned > by the in-place binary special methods (e.g. __imul__(), __iand__(), etc.) > for the same purpose. Would it be viable to rephrase the existing section in a manner that explains the functional purpose of NotImplemented without revolving around its use case in binary special methods? > Also, please be careful expanded the docs. They quickly become a promise. Good point, I may not have adequately considered that mentioning a use case turns into a promise for that functionality. This could easily result in a significant long-term maintenance cost. -- ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Kyle Stanley added the comment: > Would it be viable to rephrase the existing section in a manner that explains > the functional purpose of NotImplemented without revolving around its use > case in binary special methods? To expand further upon this, here's an initial idea for improving the first sentence: A special value used to indicate that an operation is not supported between specific types. The section regarding it's usage in binary special methods could potentially remain. I'm thinking the main issue here (if there is one) is that the NotImplemented constant is defined _exclusively_ from a specific use case, rather than its general purpose. -- ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Kyle Stanley added the comment: Thanks for the explanation. > Of course, you might argue that _once Python has NotImplemented_, it can be > used elsewhere - but as I said, I don't think it should be encouraged. Hmm, okay. My understanding of Raymond's explanation was more so "let's not encourage this because we don't want to guarantee the behavior" rather than "using it outside of binary operators shoudn't be encouraged". Prior to Jerome's usage of it in ``fractions._as_integer_ratio()`` (https://github.com/python/cpython/pull/15327/files), I had not seen it used outside of special binary operators. I thought it was an interesting usage of NotImplemented, and the current phrasing of the documentation seemed to implicitly discourage it from being used in that manner. -- ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18049] Re-enable threading test on macOS
Kyle Stanley added the comment: Ronald, is it feasible that the changes made in https://github.com/python/cpython/pull/14748/files to THREAD_STACK_SIZE in Python/thread_pthread.h could be causing intermittent failures for the Azure macOS PR tests? In a recent PR (https://github.com/python/cpython/pull/15651), test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) seemed to be timing out. See the build log for more details: https://dev.azure.com/Python/cpython/_build/results?buildId=49786&view=logs&j=18d1a34d-6940-5fc1-f55b-405e2fba32b1. It doesn't appear to be causing consistent failures for Azure, but the latest commit to PR-15651 was only involving a formatting change to the news entry, so it should not have had any influence on the test that timed out. Prior to that commit, there were no CI failures. -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue18049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37934] Docs: Clarify NotImplemented use cases
Kyle Stanley added the comment: > As you say, we currently have only one usage of NotImplemented outside its > intended purpose. Maybe we should wait to see whether it becomes at least a > little bit more popular, before thinking about blessing it. > I know at least 3 in CPython, so it's not so rare to use NotImplemented for > something else than binary operators I'm thinking that it might be worthwhile to start a discussion about this on python-dev, to see what the others think about how the NotImplemented docs should be defined, and whether or not it should be used outside of binary operators. Based on the feedback from Raymond and Vedran, I'm in agreement that it might not be the best idea in the long term to keep adding additional use cases to the documentation. But, it really doesn't make much sense to me that the constant is entirely defined around a single use case in the doc while we're using it for other purposes throughout CPython. -- ___ Python tracker <https://bugs.python.org/issue37934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37245] Azure Pipeline 3.8 CI: multiple tests hung and timed out on macOS 10.13
Kyle Stanley added the comment: It looks like the Azure macOS tests timed out again in the recently opened PR-15688. Specifically, for test_multiprocessing_spawn and test_functools (both of which also timed out in PR-15651, which Victor mentioned earlier): 0:26:41 load avg: 2.89 [418/419/1] test_multiprocessing_spawn crashed (Exit code 1) -- running: test_functools (14 min 38 sec) Timeout (0:20:00)! 0:32:03 load avg: 3.17 [419/419/2] test_functools crashed (Exit code 1) Timeout (0:20:00)! Build logs: https://dev.azure.com/Python/cpython/_build/results?buildId=49868&view=logs&j=18d1a34d-6940-5fc1-f55b-405e2fba32b1 As far as I can tell, PR-15688 should have had no direct influence on test_multiprocessing_spawn or test_functools. > Maybe macOS on Azure is running slower and we should just increase the > timeout? > Yeah, I agree that increasing the timeout shouldn't be the answer here. Since this seems to be affecting multiple PRs, would it be appropriate to attempt to increase the timeout duration as a temporary fix and open an issue for further investigation on the cause of the intermittent slowdown on those tests? -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue37245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads
Kyle Stanley added the comment: > Any plan to reapply my change, or fix it? I can try to help with this. I'm not the most familiar with the internals of asyncio, but I think it would provide a good learning experience. -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue34037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads
Change by Kyle Stanley : -- pull_requests: +15390 pull_request: https://github.com/python/cpython/pull/15735 ___ Python tracker <https://bugs.python.org/issue34037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads
Kyle Stanley added the comment: I've opened PR-15735 which applies the same functionality as Victor's PR-13786, but adds the public getter and setter methods (for both AbstractEventLoop and BaseEventLoop) as requested by Andrew. Since this is still causing intermittent CI failures from test_asyncio, I think it's important to implement these changes in some form in the near future. -- priority: normal -> high ___ Python tracker <https://bugs.python.org/issue34037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37635] Using constant for whence arg in seek()
Change by Kyle Stanley : -- keywords: +patch pull_requests: +15757 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16147 ___ Python tracker <https://bugs.python.org/issue37635> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37635] Using constant for whence arg in seek()
Kyle Stanley added the comment: Created GH-16147 for replacing the *from_what* argument with *whence* in the IO tutorial. I would like to consider following up on this with another PR that adds the IO constants `SEEK_SET`, `SEEK_CUR`, and `SEEK_END` to the tutorial. Those constants would be particularly useful for new users of the language, and would likely make the tutorial easier to understand for those who don't have prior experience with using `seek()`. However, I figured that replacing *from_what* with *whence* would be significantly less controversial and easier to review, which is why they will be in separate PRs. -- ___ Python tracker <https://bugs.python.org/issue37635> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37635] Using constant for whence arg in seek()
Kyle Stanley added the comment: > Thanks you Kyle! No problem, thanks for merging it Antoine! What do you think of the followup PR to make use of the SEEK_* constants listed in the documentation? I think it would be useful to at least mention them in the tutorial, or even make use of them directly in the examples. -- ___ Python tracker <https://bugs.python.org/issue37635> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26360] Deadlock in thread.join on Python 2.7/macOS
Kyle Stanley added the comment: > FWIW, I've confirmed again that the exact same script on the same machine > seems fine under Python 3.x. Given the imminent demise of Python 2, perhaps > this issue is just destined to be an unsolved historical oddity. Since it doesn't seem to be occurring across every macOS platform, is specific to 2.7, and isn't proving to be an easy fix, it's probably not worthwhile to invest a significant amount of further time into the issue. Thanks for working on it though, at least we tried. (: -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue26360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment: Upon digging through Modules/_xxsubinterpretersmodule.c, I noticed that on line 2059, `PyInterpreterState_Delete(interp);` is commented out (https://github.com/python/cpython/blob/bf169915ecdd42329726104278eb723a7dda2736/Modules/_xxsubinterpretersmodule.c#L2059). This was done when _xxsubinterpretersmodule.c was first added by Eric Snow (https://github.com/python/cpython/blob/bf169915ecdd42329726104278eb723a7dda2736/Modules/_xxsubinterpretersmodule.c#L2059), so it seems to have been done intentionally but I don't understand why. Is this because `Py_EndInterpreter()` is supposed to shutdown the interpreter, so `PyInterpreterState_Delete()` isn't needed? If so, that still doesn't particularly explain why it was commented out. Perhaps Eric can elaborate. -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment: Note that I'm not particularly experienced with the c-api, I'm just trying to take a stab at understanding why the buildbot failure is occuring. -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment: Clarification: In the above comment when I was referring to the commit made by Eric Snow, I meant to link to https://github.com/python/cpython/commit/7f8bfc9b9a8381ddb768421b5dd5cbd970266190. -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment:
Upon further reading of the documentation and some experimentation, it would
definitely not make sense to call `PyInterpreterState_Delete` here (since we're
only closing the sub-interpreter in the current thread), so that's not the
issue. I still have no idea as to why it's commented out there, but that's
besides the point.
I think I may have found the potential cause of the test failure though.
Looking into `test_still_running()`, it's clear that the intention is for a
RuntimeError to be raised if `interpreters.destroy()` is called on a currently
running interpreter:
```
def test_still_running(self):
main, = interpreters.list_all()
interp = interpreters.create()
with _running(interp):
with self.assertRaises(RuntimeError):
interpreters.destroy(interp)
self.assertTrue(interpreters.is_running(interp))
```
However, within interp_destroy
(https://github.com/python/cpython/blob/56a45142e70a1ccf3233d43cb60c47255252e89a/Modules/_xxsubinterpretersmodule.c#L2024),
it is apparent that the RuntimeError is ONLY raised when attempting to destroy
the current interpreter:
```
if (interp == current) {
PyErr_SetString(PyExc_RuntimeError,
"cannot destroy the current interpreter");
return NULL;
}
```
When attempting to destroy a running interpreter, NULL is returned without
raising the RuntimeError:
```
if (_ensure_not_running(interp) < 0) {
return NULL;
}
```
This was my first guess at a solution:
```
if (_ensure_not_running(interp) < 0) {
PyErr_SetString(PyExc_RuntimeError,
"cannot destroy a running interpreter")
return NULL;
}
```
But, within `_ensure_not_running()`
(https://github.com/python/cpython/blob/56a45142e70a1ccf3233d43cb60c47255252e89a/Modules/_xxsubinterpretersmodule.c#L1842),
a RuntimeError is supposed to be raised from:
```
if (is_running) {
PyErr_Format(PyExc_RuntimeError, "interpreter already running");
return -1;
}
```
Initially, I was unsure of the difference between `PyErr_SetString()` and
`PyErr_Format()`, so I referred to the documentation. `PyErr_Format()` is
similar, but it also returns NULL. If I'm not mistaken doesn't mean that the
`return -1` within the `if (is_running)` bock is effectively ignored? If so,
this would potentially explain the problem...
I think the appropriate solution would be to replace `PyErr_Format()` with
`PyErr_SetString()` within `_ensure_not_running()`. Also, I think it would be
more useful to additionally raise the RuntimeError within `interp_destroy()` if
the interpreter is running, to provide a more useful and specific error
message. "cannot destroy a running interpreter" is far more useful for
debugging purposes than a more generic "interpreter already running".
I plan on opening a PR to make these changes in the next few days. Let me know
what you think Victor.
--
___
Python tracker
<https://bugs.python.org/issue37224>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment: Clarification: "If I'm not mistaken doesn't mean that the `return -1` within ..." Should instead be: "If I'm not mistaken doesn't this mean that the `return -1` within ..." (I am really looking forward to moving issue over to GitHub at some point. It's nice to be able to edit comments and properly format code blocks...) -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38154] test__xxsubinterpreters: random failures on AMD64 FreeBSD CURRENT Shared 3.x
Kyle Stanley added the comment: I believe I found a potential fix, see https://bugs.python.org/issue37224?@ok_message=msg%20352516%20created%0Aissue%2037224%20message_count%2C%20messages%20edited%20ok&@template=item#msg352514. Should I attach the PR to that issue or this one? -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue38154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment: Upon further consideration, I don't think this will address the issue. If the RuntimeError was not being raised, this failure would be consistent rather than intermittent. I think I have have gotten a bit mixed up, even if the return value of PyErr_Format is NULL, it would not implicitly return NULL upon being called and exit the function early (like a macro could) . I'm not experienced with programming in C, I only started learning it more recently (Python, Java, and C# have been my primary languages) when I started contributing to CPython in June. Instead, I suspect this is likely a concurrency issue, where multiple threads are trying to access the same sub-interpreter during ``interp_destroy()``. The solution will likely involve finding the correct place for a lock. I'll continue to work on this and see if I can find a solution. -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads
Kyle Stanley added the comment: > Thanks, Kyle! No problem, and thanks for all of the help from Andrew, Yury, and Victor! > IMHO it will make asyncio more reliable, especially for tests on the CI. Awesome, that was my primary intention. (: > If it becomes an issue in Python 3.9 (executor hangs forever), Feel free to add me to the nosy list if you have to open an issue for it, I'd be glad to help out with this if it becomes an issue. -- ___ Python tracker <https://bugs.python.org/issue34037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
Kyle Stanley added the comment: > I'm one of the first to advocate to replace ugly macros with clean static > inline functions. Macros are evil and can be too easily misused. As someone who has only more recently started learning the C-API (and C in general), I'm certainly in favor of replacing macros with functions when possible. I might be a bit biased, but it definitely makes the code a lot easier to understand (especially the macros with implicit returns). As long as there's not a significant performance loss and it doesn't introduce new complications, I don't see an issue with it. >From my understanding, readability isn't as high of a priority in the C code, >but certainly there's some benefit to improving areas that are more difficult >to understand. The easier the code is to understand, the lower the overall >maintenance cost becomes. Of course, this should certainly be done in moderation to reduce the introduction of unnecessary new bugs and the cost in reviewer time for more pressing concerns. -- ___ Python tracker <https://bugs.python.org/issue37812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters failed on AMD64 Windows8.1 Refleaks 3.8
Kyle Stanley added the comment: Is there a currently reliable way of accessing the GIL functions within the sub-interpreters, without causing deadlock issues? I was trying to follow the advice in the documentation (https://docs.python.org/3/c-api/init.html?highlight=global%20interpreter%20lock#bugs-and-caveats). "It is highly recommended that you don’t switch sub-interpreters between a pair of matching PyGILState_Ensure() and PyGILState_Release() calls." But it seemed that any attempt to use any of the PyGIL* calls within ``interp_destroy()`` in a meaningful way resulted in a deadlock, even if it was done away from the sub-interpreter switching. My next idea would be to add a conditional check to see if the current thread has ownership of the GIL, and using ``PyEval_RestoreThread()`` to acquire it if it doesn't. This would be followed by releasing the GIL with ``PyThreadState_Get()`` at the end of the function. I'll try experimenting with that idea next. -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38154] test__xxsubinterpreters: random failures on AMD64 FreeBSD CURRENT Shared 3.x
Change by Kyle Stanley : -- keywords: +patch pull_requests: +15879 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16293 ___ Python tracker <https://bugs.python.org/issue38154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38154] test__xxsubinterpreters: random failures on AMD64 FreeBSD CURRENT Shared 3.x
Kyle Stanley added the comment: For an updated explanation of the PR, see https://bugs.python.org/msg352835 or the comments in the PR itself. -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue38154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
Kyle Stanley added the comment: > You can find my email in Git, and I'm on Zulip and Discourse; and I'd be > happy to start or follow a thread in a forum you think appropriate. Or if > you'd rather drop it entirely, that's fine too. I think opening a thread in https://discuss.python.org/c/users to talk about deciding between the usage of functions and macros (discussing when each may be appropriate) would be beneficial to the community at large. > The recommendation of the senior most developer is being ignored, and now two > developers are speaking in terms of strong belief systems and labeling > long-stable code as "evil". This doesn't bode well and it makes it difficult > to conduct reasoned discourse. Apologies if I added to that, I certainly respect your judgement on this issue. Pretty much everyone involved in this discussion has more experience in working with the CPython C-API than I do, you most of all (as far I'm aware). My perspective was coming from someone attempting to understand it better, and explaining how those learning the C-API might find it confusing. I don't find the code itself to be at all "evil", just potentially confusing. That long-stable code has provided a lot of benefit over the years, and I can definitely appreciate the effort that was put into writing it. -- ___ Python tracker <https://bugs.python.org/issue37812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)
Kyle Stanley added the comment: > Is there an "aesthetic code cleanup" patch that's ever turned out well? ;-) >From what I can tell, any remotely extensive aesthetic code patch I've seen >has been highly controversial. I think they can have value in some cases, but >the value relative to the potential cost may have been a bit overstated in >this particular case. -- ___ Python tracker <https://bugs.python.org/issue37812> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Change by Kyle Stanley : -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Kyle Stanley added the comment: > We have to document that Process objects use a third kind of stream object > that doesn't match either the old or new APIs, and how this one works >From my perspective, this point would have the largest user learning cost due >to the stream object having a completely different API. As a result, I'm >significantly more in favor of adding the two new subprocess functions. -- ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38267] Add thread timeout for loop.shutdown_default_executor
New submission from Kyle Stanley : Currently, for the recently added coroutine `loop.shutdown_default_executor()`, the executor shutdown can wait indefinitely for the threads to join. Under normal circumstances, waiting on the threads is appropriate, but there should be a timeout duration in the situation that the threads unable to finish joining. The motivation for this was based on the comments from Andrew Svetlov and Yury Selivanov in GH-16284. The original idea from Andrew was to add the timeout duration as a default for a new parameter in `asyncio.run()` and `loop.shutdown_default_executor()`. However, Yury would prefer for this to be defined as a constant instead and not as a parameter for `asyncio.run()` to avoid the creation of an excessive number of parameters to tweak for the user. I will attach a PR that adds the constant and the parameter for `loop.shutdown_default_executor()`, which will passed as an argument to `thread.join()`. -- messages: 353115 nosy: aeros167, asvetlov, yselivanov priority: normal severity: normal status: open title: Add thread timeout for loop.shutdown_default_executor versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38267] Add thread timeout for loop.shutdown_default_executor
Change by Kyle Stanley : -- keywords: +patch pull_requests: +15941 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16360 ___ Python tracker <https://bugs.python.org/issue38267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Kyle Stanley added the comment: > Andrew, do you want me to submit a PR or you can do it? Since this has been elevated to a release blocker, I wouldn't mind helping to revert this ASAP. I can open a PR to fix it today. -- ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Kyle Stanley added the comment: > You'll need to be careful to only revert the new functions & the > asyncio.Stream class. So far the trickiest part has proven to be the tests (specifically test_streams.py) and keeping the deprecation warning for passing explicit loop arguments. I've had to be careful to be certain that no tests were unintentionally removed. > Due to proximity to the deadline, please be prepared that we might need to > abandon your pull request if it's not ready by Sunday morning No problem, I'll make sure to allow anyone with write access (yourself and Andrew) to edit the PR I open directly to make any needed changes. That way, at least any progress I make on it can help reduce the amount of work for you two. -- ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Kyle Stanley added the comment: Currently focusing on the Lib/asyncio/* and Lib/test/* changes. Working on doc changes next, but that should be significantly easier. In addition to https://github.com/python/cpython/commit/23b4b697e5b6cc897696f9c0288c187d2d24bff2 (main commit from Andrew that added asyncio.Stream and new functions), I've also had to remove https://github.com/python/cpython/commit/4cdbc452ce3 (minor asyncio test change from Pablo) due to it causing issues with the other tests from deleting asyncio.StreamReader and asyncio.StreamWriter. -- ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Change by Kyle Stanley : -- keywords: +patch pull_requests: +16024 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16445 ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Change by Kyle Stanley : -- pull_requests: +16035 pull_request: https://github.com/python/cpython/pull/16455 ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38164] polishing asyncio Streams API
Kyle Stanley added the comment: This should no longer be a release blocker for 3.8 with the reversion of the new asyncio streaming API in GH-16455. -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue38164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Change by Kyle Stanley : -- stage: commit review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Kyle Stanley added the comment: > I've reverted the code. Andrew, would really appreciate if you could quickly > do a post commit review. Oops, I'll reopen it. -- ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Change by Kyle Stanley : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38242] Revert the new asyncio Streams API
Change by Kyle Stanley : -- stage: resolved -> commit review ___ Python tracker <https://bugs.python.org/issue38242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38164] polishing asyncio Streams API
Kyle Stanley added the comment: Closed by the new asyncio stream API reversion in GH-16485 and GH-16482. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Kyle Stanley added the comment: Welcome back from the OOOS break Mariatta! > My question (and it's just that) is whether we've made a decision to prefer > one formatting syntax over others (outside of examples discussing the > formatting approaches themselves). I agree that we should reach a consensus on the preferred string formatting style. However, there seems to be two separate questions here: 1) Should the code examples in the docs be updated to use f-strings? 2) Should ALL instances of the old string formatting be updated to use f-strings? This would affect every *.py; potentially leading to additional code churn, which adds clutter to the commit logs and git blame. The first one is far less costly and has very minimal risk of breakage. The cost of updating every *.py to use f-strings is worth considering, but is significantly higher and has more potential consequences, especially for the regression tests. I'm personally in favor of updating the code examples first and discussing the second question in a python-dev thread due to the wide impact. > If a decision is made to prefer one over others, it's worth making that > decision separately, and then using separate PRs to deal with updates to > different parts of the docs. Once we reach a decision on the matter, I think this particular issue could serve as a great first PR for a new contributor to become familiar with the workflow, so it would be a good candidate for the "newcomer friendly" label. Most python users are well acquainted with string formatting. I wouldn't mind opening a PR to fix it myself, but I think that leaving it open for a new contributor to work on as an intro to the workflow would be far more beneficial. Although there may be a benefit to use f-strings instead here, there's certainly no rush to have it completed in a short period of time. I would be in favor of having each PR address a single documentation file. This would help accelerate the review process and provide a valuable learning experience to a greater number of new contributors, in comparison to a single PR that updates every single code example in the docs. -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Kyle Stanley added the comment: > so it would be a good candidate for the "newcomer friendly" label Never mind, just noticed this was already labeled as newcomer friendly. I only saw the "easy" label at first. (: If consensus is reached for this, we can open a separate issue for addressing the other doc files, something along the lines of "Update code examples to use f-strings". As mentioned earlier I think it would be worth having each new contributor update all of the instances in a single *.rst in a PR, but it can be a single issue. -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads
Kyle Stanley added the comment: I can try to work on fixing this. -- nosy: +aeros167 ___ Python tracker <https://bugs.python.org/issue38356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Kyle Stanley added the comment: > I definitely think we should not modify any code in the stdlib just to switch > to f-strings. Does this also apply to updating code to use f-strings in an area that's already being modified for a functional purpose? I agree that that we shouldn't update stdlib code for the sole purpose of switching to f-strings, but if a function or method is already being changed for another purpose, I don't think updating the formatting to use f-strings is an issue. This would probably have to be decided on a case-by-case basis though. -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads
Kyle Stanley added the comment: First I'll work on adding a new method. Here's a few potential names, ordered roughly by my preferences: 1) join_threads() 2) shutdown_threads() 3) shutdown_threadpool() The first and second options are roughly equal, but I think join_threads() is a bit more specific to what this is doing. The third option is because a group of threads could be considered a "threadpool", but ThreadedChildWatcher doesn't utilize a dedicated threadpool class of any form, it just uses an internal dict named `_threads` that maps process IDs to threads. So this name might be potentially misleading. I'm also wondering whether or not this method should have a timeout parameter that defaults to None. I'm thinking we can probably leave it out for now, but I wanted to hear some other opinions on this. For now, I'll be implementing this as a regular method, but I could make it a coroutine if that's desired. Admittedly, I don't enough have knowledge of the realistic use cases for ThreadedChildWatcher to know if it would be particularly useful to have an awaitable method to join the threads. Another consideration is if we want this method to join the threads to be called in `ThreadedChildWatcher.close()`. I think it makes sense from a design perspective to join all of the threads when the close method is used. Plus, it would allow the method to be integrated with the tests better. Currently, the test uses the same `setUp()` and `tearDown()` for each of the different subprocess watchers. If it weren't called in the `close()` method, we'd have to add an `if isinstance(watcher, ThreadedChildWatcher)` conditional in `tearDown()`. So, I would prefer to have the method called from `close()`. Finally, should this method be part of the public API, or just a private method? As mentioned earlier, I'm not overly aware of the realistic use cases for ThreadedChildWatcher. As a result, I don't know if it would be especially useful for users to call this method independently, especially if this were called from `close()` as I was suggesting earlier. After we reach a consensus on the implementation details and API design for the new method, I'll work on adding an entry in the documentation (if it should be public) and updating test_subprocess.SubprocessThreadedWatcherTests to utilize it. -- ___ Python tracker <https://bugs.python.org/issue38356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads
Kyle Stanley added the comment: > Another consideration is if we want this method to join the threads to be > called in `ThreadedChildWatcher.close()`. An additional benefit of having the method called from `close()` is that it means we don't have to modify the tests directly. Also, ThreadedChildWatcher's implementation of `close()` does nothing at the moment. -- ___ Python tracker <https://bugs.python.org/issue38356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks threads
Change by Kyle Stanley : -- keywords: +patch pull_requests: +16140 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16552 ___ Python tracker <https://bugs.python.org/issue38356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
Kyle Stanley added the comment: > For the most part, templating examples can be switched to the .format() style > but shouldn't be switched to f-strings. Is there no specific use case for the older "%s" % sub template that .format() doesn't have? > The former technique is still necessary if someone wants to move templates to > an external file Interesting, I wasn't aware of that. This seems like it might be worth a brief mention in https://docs.python.org/3.9/library/stdtypes.html#str.format. > AFAICT, it will be around forever, so people still need to see some examples > of each. To allow users to see examples of each, would you suggest that we should leave the existing .format() examples as is and have more recently created examples use f-strings? I'd be okay with this, as long as there's a balance of both everywhere (particularly in the tutorial). Personally, I think that the f-string examples should be used more commonly used since they're generally more concise and readable. But, I can definitely understand the purpose of leaving the older ones around as long as they have a specific use case and are still utilized. -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38344] activate.bat else needs to be on the same line as the if
Change by Kyle Stanley : -- stage: patch review -> commit review ___ Python tracker <https://bugs.python.org/issue38344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38355] ntpath.realpath() fails on sys.executable
Change by Kyle Stanley : -- stage: backport needed -> commit review ___ Python tracker <https://bugs.python.org/issue38355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38359] pyw.exe opens console window in Windows 10
Change by Kyle Stanley : -- stage: backport needed -> commit review ___ Python tracker <https://bugs.python.org/issue38359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38449] regression - mimetypes guess_type is confused by ; in the filename
Kyle Meyer added the comment:
I've performed a bisect the issue with the following script:
#!/bin/sh
make -j3 || exit 125
./python <<\EOF || exit 1
import sys
import mimetypes
res = mimetypes.MimeTypes(strict=False).guess_type(";1.tar.gz")
if res[0] is None:
sys.exit(1)
EOF
That points to 87bd2071c7 (bpo-22347: Update mimetypes.guess_type to allow
proper parsing of URLs (GH-15522), 2019-09-05). That commit was included in
3.7.5rc1 when it was cherry picked by 8873bff287.
--
nosy: +kyleam
___
Python tracker
<https://bugs.python.org/issue38449>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37224] test__xxsubinterpreters fails randomly
Kyle Stanley added the comment: > Kyle Stanley proposed a fix: PR 16293. Note that I'm not confident about the fix I proposed in GH-16293, it was more of an idea to fix the intermittent failures more than anything. It definitely needs review from someone knowledgeable about sub-interpreters and the PyInterpreterState API. This isn't an area that I'm experienced in, but I am interested in it. -- ___ Python tracker <https://bugs.python.org/issue37224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31387] asyncio should make it easy to enable cooperative SIGINT handling
Change by Kyle Stanley : -- nosy: +aeros ___ Python tracker <https://bugs.python.org/issue31387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28533] Replace asyncore
Change by Kyle Stanley : -- nosy: +aeros ___ Python tracker <https://bugs.python.org/issue28533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27873] multiprocessing.pool.Pool.map should take more than one iterable
Kyle Stanley added the comment: > Is it still open? What else needs to be done? Yes, this patch needs to be translated into a GitHub PR. See https://devguide.python.org/pullrequest/ for more information on our PR workflow if you're not already familiar with it. Since naught101 wrote a patch, we should have their name in "Co-Authored-By" of the final commit to the PR if they have a GitHub account. If not, just mention it in a comment to the PR that they originally wrote the patch. Feel free to @mention me when you open the PR so I can help to review it, although this will likely require a final approval from a maintainer of multiprocessing module before it can be merged. -- nosy: +aeros ___ Python tracker <https://bugs.python.org/issue27873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
