[issue21910] [doc] File protocol should document if writelines must handle generators sensibly

Stanley added the comment: I'd be interested in taking a look at this - would these changes clarify things? Current (https://docs.python.org/3/library/codecs.html#codecs.StreamWriter): Writes the concatenated list of strings to the stream (possibly by reusing the write() method)

[issue21910] [doc] File protocol should document if writelines must handle generators sensibly

Change by Stanley : -- keywords: +patch pull_requests: +29414 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31245 ___ Python tracker <https://bugs.python.org/issu

[issue45492] stdlib inspect documentation on code.co_names is incorrect

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 2.0 -> 3.0 pull_requests: +29585 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31456 ___ Python tracker <https://bugs.python.org/i

[issue36557] [doc] Clarify the meaning of /uninstall in windows cli

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 7.0 -> 8.0 pull_requests: +29586 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31457 ___ Python tracker <https://bugs.python.org/i

[issue31327] [doc] Add example of platform-specific support for negative timestamps to the time doc

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 8.0 -> 9.0 pull_requests: +29589 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31460 ___ Python tracker <https://bugs.python.org/i

[issue23747] [doc] platform module exposes win32_ver function on posix systems

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +29591 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31462 ___ Python tracker <https://bugs.python.org/i

[issue34429] [doc] On Windows tempfile.TemporaryFile behaves like NamedTemporaryFile

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +29668 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31547 ___ Python tracker <https://bugs.python.org/i

[issue45991] Improve ambiguous docstrings in pkgutil

Stanley added the comment: Could you expand a bit on why 'list of paths' in pkgutil is understood by default to be 'list of PosixPath paths'? I would interpret it by default to be string paths if I saw it somewhere without context -

[issue30677] [doc] mention that os.mkdir() raises FileNotFound if path does not exist

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 3.0 -> 4.0 pull_requests: +29669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31548 ___ Python tracker <https://bugs.python.org/i

[issue12165] [doc] clarify documentation of nonlocal

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29672 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31551 ___ Python tracker <https://bugs.python.org/i

[issue45991] Improve ambiguous docstrings in pkgutil

Stanley added the comment: While it is ambiguous, when there's a path parameter I would default it to string unless otherwise specified. Maybe instead a note could be put in the Pathlib doc noting functions that accept path arguments might not accept Path ob

[issue27583] [doc ] configparser: modifying default_section at runtime

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 5.0 -> 6.0 pull_requests: +29685 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31562 ___ Python tracker <https://bugs.python.org/i

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29687 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31565 ___ Python tracker <https://bugs.python.org/i

[issue13821] [doc] misleading return from isidentifier

Stanley added the comment: For clarification then, would it be accurate to add a sentence like this in the documentation? "Note that isidentifier() still returns True even if the string may not be normalized." -- nosy: +slateny

[issue29251] [doc] Class __dict__ is only a mapping proxy

Stanley added the comment: >From what I can see, the original patch changed ... and the *dict* dictionary is the namespace containing definitions for class body and is copied to a standard dictionary to become the __dict__ attribute into this ... and the *dict* dictionary is copied to

[issue20970] [doc] contradictory documentation for prog option of argparse

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29725 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31602 ___ Python tracker <https://bugs.python.org/i

[issue25743] [doc] Clarify exactly what \w matches in UNICODE mode

Stanley added the comment: Would a change like this be accurate? Matches Unicode word characters; this includes most alphanumeric characters as well as the underscore. In Unicode, alphanumeric characters are defined to be the general categories L + N (see https://unicode.org/reports/tr44

[issue23453] [doc] Clarify bytes vs text with non-seeking tarfile stream

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 3.0 -> 4.0 pull_requests: +29733 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31610 ___ Python tracker <https://bugs.python.org/i

[issue45991] Improve ambiguous docstrings in pkgutil

Stanley added the comment: I feel like there might be some backwards compatibility issues if pkgutil wraps it like that, but similarly I'm not at all familiar with how common the package is used and whether it'd be fine to make that change, so I'll also differ

[issue10149] [doc] Data truncation in expat parser

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 6.0 -> 7.0 pull_requests: +29752 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31629 ___ Python tracker <https://bugs.python.org/i

[issue25415] [doc] "there is no public constructor" should be reworded in io module documentation

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 5.0 -> 6.0 pull_requests: +29753 pull_request: https://github.com/python/cpython/pull/31631 ___ Python tracker <https://bugs.python.org/issu

[issue23323] [doc] mention that flags arg to imaplib's append should be a string

Stanley added the comment: How would this sound as clarification for the flags argument? *flags* is a space-separated string containing IMAP flags tokens. Must start with ``\``. Perhaps optionally also provide the list of system flags as given in https://datatracker.ietf.org/doc/html

[issue18534] [doc] State clearly that open() 'file' param is "name" attr of the result

Stanley added the comment: Would it be fine to modify FileIO.name like this: "... given in the constructor. Depending on the type of *name* that was passed into the constructor, this may not necessarily e a string." -- nosy: +slateny

[issue26545] [doc] os.walk is limited by python's recursion limit

Stanley added the comment: I'm not too sure about documenting the recursive limit here. There's a few other recursive functions in the os library (such as makedirs()) and if we note the recursive limit for os.walk then all of them should be noted too, but that doesn't seem qu

[issue9305] Don't use east/west of UTC in date/time documentation

Change by Stanley : -- nosy: +slateny nosy_count: 14.0 -> 15.0 pull_requests: +29817 pull_request: https://github.com/python/cpython/pull/31697 ___ Python tracker <https://bugs.python.org/iss

[issue9182] document “--” as a way to distinguish option w/ narg='+' from positional argument in argparse

Change by Stanley : -- nosy: +slateny nosy_count: 13.0 -> 14.0 pull_requests: +29908 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31810 ___ Python tracker <https://bugs.python.org/

[issue47031] math.nan should note that NANs do not compare equal to anything

Stanley added the comment: How does this sound instead? The unequalness is pushed to the front and the IEEE part back so it's less likely missed: Math.nan and float('nan') are never equal to any other value, including themselves, as per IEEE 754. Use math.isnan t

[issue33028] [doc] tempfile.TemporaryDirectory documentation improvements

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30104 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32016 ___ Python tracker <https://bugs.python.org/i

[issue47031] math.nan should note that NANs do not compare equal to anything

Stanley added the comment: Vedran's got a good point, as existing documentation for math.nan already says "... Equivalent to the output of float('nan')." so it does seem a bit redundant to say both, though I wonder if we should still be explicit since >&g

[issue47031] math.nan should note that NANs do not compare equal to anything

Stanley added the comment: Then perhaps saying that it's *never* equal is too strong, and instead we just say it's *not* equal. Not too sure how to phrase the behavior difference between `==` and `is` though, if that's something that

[issue37430] [doc] range is not a built-in function

Stanley added the comment: Terry, how do you think the example/paragraph should be improved? I notice that the previous paragraphs talk about continue/break/else, so were you looking for some new example with all those? And I think the indexing's been fixed by now, but a clickable li

[issue39971] [doc] Error in functional how-to example

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30250 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32172 ___ Python tracker <https://bugs.python.org/i

[issue32658] Metacharacter (\) documentation suggestion

Stanley added the comment: Mike, are you still working on this issue? -- nosy: +slateny ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Pytho

[issue32658] Metacharacter (\) documentation suggestion

Stanley added the comment: Feel free, it's all yours -- ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Python-bugs-list mailing list

[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?

Stanley added the comment: Is there a bpo page or some sort that discusses why the imperative mood is used over the indicative mood other than convention of PEP 257? I found this (https://mail.python.org/pipermail/tutor/2012-May/089584.html) question and answer that seems to make sense, but

[issue44158] Clarify documentation for redirected stdout/stderr when using subprocess in Linux

Stanley added the comment: Hmm, I'm not quite following - when you say that the subproccess-ed command should also inherit the redirection, which subprocess command are you referring to, and nested or unnested? I gave it a ran and everything seems to run how I'd expected it, so

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example

Stanley added the comment: Samriddhi, are you still working on this? -- nosy: +slateny ___ Python tracker <https://bugs.python.org/issue46168> ___ ___ Python-bug

[issue30718] [doc] open builtin function: specifying the size of buffer has no effect for text files

Change by Stanley : -- keywords: +patch nosy: +slateny nosy_count: 4.0 -> 5.0 pull_requests: +30403 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32351 ___ Python tracker <https://bugs.python.org/i

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

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

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

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

[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

[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

[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

[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

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

[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/python-...@python.org/message

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

[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

[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

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

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

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

[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. -- ___

[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/issu

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

[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

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

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

[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

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

[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

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

[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

[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: +

[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/issue34

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

[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/issu

[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

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

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

[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

[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.o

[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

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

[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

[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

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

[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

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

[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

[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/issu

[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/issu

[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

[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

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

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

[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

[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/issu

[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

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

[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

[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/issu

[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/issue38

[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/issue38

[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> ___ ___ Pyth

[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.py

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

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

  1   2   3   4   5   >