[issue40078] asyncio subprocesses allow pids to be reaped, different behavior than regular subprocesses

Change by Justin Lebar : -- type: -> behavior versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue40078> ___ ___ Python-bugs-list mai

[issue40078] asyncio subprocesses allow pids to be reaped, different behavior than regular subprocesses

Change by Justin Lebar : -- versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue40078> ___ ___ Python-bugs-list mailing list Unsub

[issue1187312] subprocess: optional auto-reaping fixing os.wait() lossage

Justin Lebar added the comment: 15 years later, it seems asyncio subprocesses may have the same issue. :) https://bugs.python.org/issue40078 -- nosy: +Justin.Lebar ___ Python tracker <https://bugs.python.org/issue1187

[issue40078] asyncio subprocesses allow pids to be reaped, different behavior than regular subprocesses

New submission from Justin Lebar : >From https://bugs.python.org/issue1187312 about regular subprocesses: > So as long as the application keeps a reference to the > subprocess object, it can wait for it; auto-reaping only > starts when the last reference was dropped [in P

[issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode

Justin Lebar added the comment: Ah, I see. The examples do what you think they should do, but not for the reason you think they should do it -- the JSON encoding logic calls the encoder's encode() method before calling its default() method. I still think the examples could be imp

[issue16057] Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode

New submission from Justin Lebar: The JSONEncoder documentation says we can implement our own encoder as: >>> class ComplexEncoder(json.JSONEncoder): ... def default(self, obj): ... if isinstance(obj, complex): ... return [obj.real, obj.imag] ...

[issue10415] readline.insert_text documentation incomplete

Justin Lebar added the comment: Actually, maybe startup_hook doesn't do what it sounds like it does and insert_text() only works from startup_hook. If this is the case, then the documentation for startup_hook could also be improved: > The startup_hook function is called with no a

[issue10415] readline.insert_text documentation incomplete

New submission from Justin Lebar : The readline documentation currently says: > readline.insert_text(string) > Insert text into the command line. But as far as I can tell, readline.insert_text() does something only when called from startup_hook or pre_input_hook. Here's an

[issue7864] Deprecation markers in unittest docs are unclear

Justin Lebar added the comment: Oh, I see. I still think a complete sentence would be helpful here, although now that I understand that the colon doesn't mean "use instead" I suppose I'm less confused... -- ___ P

[issue7864] Deprecation markers in unittest docs are unclear

New submission from Justin Lebar : The documentation for assertTrue/assert_/failUnless reads: assertTrue(expr, msg=None) assert_(expr, msg=None) failUnless(expr, msg=None) ... Deprecated since version 3.1: failUnless(). The deprecation warning is confusing, since it appears to suggest

[issue7809] Documentation for random module should indicate that a call to seed() is not required

Justin Lebar added the comment: Ack. I read it twice looking for that line! Perhaps it should still indicate that new Random objects are automatically seeded. And perhaps the line I missed should be a little bit louder? -- status: pending -> o

[issue7809] Documentation for random module should indicate that a call to seed() is not required

New submission from Justin Lebar : Many programmers are used to languages where the RNG is deterministic unless it's explicitly seeded. This does not appear to be the case in Python. The documentation for random should indicate that Random objects are seeded on construction, and tha

[issue7797] base64 module docs should indicate that encode methods return bytes, not strings

New submission from Justin Lebar : It's not at all clear from the documentation that base64.base64encode() and its kin return bytes, rather than strings. Since this matters now, the docs should be clear on this point. http://docs.python.org/3.1/library/base64.html -- ass

[issue7746] Nit: Extra comma in itertools doc

New submission from Justin Lebar : At http://docs.python.org/3.1/library/itertools.html, "For instance, SML provides a tabulation tool: tabulate(f) which produces a sequence f(0), f(1), But, this effect can be achieved in Python by combining map() and count() to form map(f,