[issue39797] shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()

New submission from Ama Aje My Fren : When a subclass of socketserver.BaseServer is running after calling serve_forever() and needs to be shutdown, it may be shut down by sending a [shutdown()](https://docs.python.org/3/library/socketserver.html#socketserver.BaseServer.shutdown). The thing

[issue39797] shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()

Change by Ama Aje My Fren : -- keywords: +patch pull_requests: +18278 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18926 ___ Python tracker <https://bugs.python.org/issu

[issue39797] shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()

Change by Ama Aje My Fren : -- pull_requests: +18281 pull_request: https://github.com/python/cpython/pull/18929 ___ Python tracker <https://bugs.python.org/issue39

[issue39797] shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()

Change by Ama Aje My Fren : -- pull_requests: +18282 pull_request: https://github.com/python/cpython/pull/18930 ___ Python tracker <https://bugs.python.org/issue39

[issue39797] shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()

Change by Ama Aje My Fren : -- pull_requests: +18284 pull_request: https://github.com/python/cpython/pull/18932 ___ Python tracker <https://bugs.python.org/issue39

[issue39797] shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()

Change by Ama Aje My Fren : -- pull_requests: +18285 pull_request: https://github.com/python/cpython/pull/18933 ___ Python tracker <https://bugs.python.org/issue39

[issue40166] UNICODE HOWTO: Change the total number of code points in the introduction section

Change by Ama Aje My Fren : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue40166> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue40166] UNICODE HOWTO: Change the total number of code points in the introduction section

Change by Ama Aje My Fren : -- keywords: +patch pull_requests: +18693 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19328 ___ Python tracker <https://bugs.python.org/issu

[issue40166] UNICODE HOWTO: Change the total number of code points in the introduction section

New submission from Ama Aje My Fren : The dev version of CPython gets the latest version of Unicode integrated to it regularly - and usually within dates of the latest version of Unicode coming out. The Unicode HOWTO documentation has a line in the introduction that refers to the number

[issue40090] The referenced RFC for the json module should be corrected to rfc8259

Change by Ama Aje My Fren : -- keywords: +patch pull_requests: +18558 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19197 ___ Python tracker <https://bugs.python.org/issu

[issue40090] The referenced RFC for the json module should be corrected to rfc8259

New submission from Ama Aje My Fren : Currently the Documentation of the json library module refers to :rfc:`7159` . That RFC has however been obsoleted by :rfc:`8259`. The Documentation for :mod:`json` should be changed to indicate this. -- assignee: docs@python components

[issue40090] The referenced RFC for the json module should be corrected to rfc8259

Ama Aje My Fren added the comment: I am not the expert on this but I did a swift check of the two documents before doing the documentation PR <https://github.com/python/cpython/pull/19197>. >From my reading of the two, RFC8259 <https://tools.ietf.org/html/rfc8259#sectio

[issue40434] Update of reasoning why there is no case statement

Ama Aje My Fren added the comment: the statement initially said that there was _no consensus yet on how to do range tests_. This is not true because there is now a decision to not do range tests - that decision is only in PEP 3103 and not in PEP 275 (PEP 275 actually links to PEP 3103

[issue40434] Update of reasoning why there is no case statement

New submission from Ama Aje My Fren : The design and history FAQ (https://docs.python.org/dev/faq/design.html#why-isn-t-there-a-switch-or-case-statement-in-python) explains why there is no case statement referencing PEP 275(https://www.python.org/dev/peps/pep-0275/). For Python 3

[issue40434] Update of reasoning why there is no case statement

Change by Ama Aje My Fren : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue40434> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue40434] Update of reasoning why there is no case statement

Change by Ama Aje My Fren : -- keywords: +patch pull_requests: +19110 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19787 ___ Python tracker <https://bugs.python.org/issu

[issue40733] Make IDLE doc more visible, mention in main python docs page

Ama Aje My Fren added the comment: > > I could also add label with the online url and date above the text. > [https://docs.python.org/3.x/library/idle.html as of ] > > Maybe this is a bit messy? I may be wrong but I suspect that most people on docs.python.org use none dev v

[issue40733] Make IDLE doc more visible, mention in main python docs page

Ama Aje My Fren added the comment: > I think I used duckduckgo to find the docs. Ok, I just checked and when one has scrolled down the search is not seen. In most browsers web search is easier than searching on the docs site. -- Added file: https://bugs.python.org/file49

[issue40748] Tutorial 4 More Control Flow Tools missing screen prompts in some code blocks

Ama Aje My Fren added the comment: On Sun, May 24, 2020 at 2:54 AM Chas Belov wrote: > Do I need a separate issue for each code block that is not common across 3.5 through 3.10? Or would this be handled during the back-porting process? Unless there is an issue, automatic back-porting sho

[issue40748] Tutorial 4.7 More on Defining Functions missing screen prompts

Ama Aje My Fren added the comment: Hi @Chas Belov, On Sun, May 24, 2020 at 1:27 AM Chas Belov wrote: > The tutorial on More on Defining Functions at > https://docs.python.org/3.7/tutorial/controlflow.html#more-on-defining-functions > is missing most of the >>> and

[issue40717] pl.python.org has expired cert and links to nonexistent django.pl page

Ama Aje My Fren added the comment: Hello, I am not absolutely sure but I suspect this should be directed to the infrastructure team. There is an infrastructure email list. I am hoping one can write to them without being a member of the group as I have done. Thanks On Thu, May 21, 2020 at 9

[issue40770] RFE: Run linkchecker on documentation on the CI

Ama Aje My Fren added the comment: On Thu, May 28, 2020 at 3:13 PM Miro Hrončok wrote: > > Note: I would gladly contribute this check, but I have no idea where should I > do that. > I don't know either. I suspect it will have to be with one of the CI/CD providers that cpyt

[issue40748] Tutorial 4.7 More on Defining Functions missing screen prompts

Ama Aje My Fren added the comment: On Sun, May 24, 2020 at 11:34 PM Chas Belov wrote: > > I'm guessing your point is that we only need to show >>> and ... when there > will be print output so that we need to distinguish between what is input and > what is outpu

[issue40763] zipfile.extractall is safe by now

Ama Aje My Fren added the comment: Hi, On Mon, May 25, 2020 at 10:18 AM Va wrote: > > So, the big red warning in Python 3 documentation might be relevant only for > Python < 2.7.4, not for any Python 3 version. > You may be on to something. It does appear to be wha

[issue40558] update CONTRIBUTING.rst docs

Ama Aje My Fren added the comment: Hello all, they don't seem to be working now? Thanks. -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue40

[issue24921] Operator precedence table in 5.15 should be highest to lowest precedence

Change by Ama Aje My Fren : -- keywords: +patch nosy: +amaajemyfren nosy_count: 5.0 -> 6.0 pull_requests: +19812 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20572 ___ Python tracker <https://bugs.p

[issue40763] zipfile.extractall is safe by now

Ama Aje My Fren added the comment: On Tue, May 26, 2020 at 2:47 PM Va wrote: > > What hasn't been handled then? > The rules for naming files in Windows is long (https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file). It is e.g. possible to create files under WSL withi

[issue41411] Improve and consolidate f-strings docs

Ama Aje My Fren added the comment: Hi, Thanks Ezio for the detailed response. > In the list of proposed solutions in my first message, 1-3 should be quite > easy to implement. This leaves us with 4-5. To the best of my seeing there are only two places in the documentation that

[issue41411] Improve and consolidate f-strings docs

Change by Ama Aje My Fren : -- pull_requests: +20825 pull_request: https://github.com/python/cpython/pull/21681 ___ Python tracker <https://bugs.python.org/issue41

[issue41411] Improve and consolidate f-strings docs

Ama Aje My Fren added the comment: Hi, >The online docs seem updated, so I'm not sure why it's not working. Maybe you >could try So it seems that the .. index::[0] directive creates an index[1]. Both f-index and findex are available in it. Search is a bit different. A searchi

[issue25377] Mention octal format of mode argument of os.chmod

Change by Ama Aje My Fren : -- keywords: +patch nosy: +amaajemyfren nosy_count: 4.0 -> 5.0 pull_requests: +19846 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20621 ___ Python tracker <https://bugs.p

[issue25377] Mention octal format of mode argument of os.chmod

Ama Aje My Fren added the comment: I think I was finally able to do a PR for this on 3.10. Requesting a triager to please check because it does not appear as a Documentation change on Github. Thanks -- ___ Python tracker <https://bugs.python.

[issue41045] f-string's "debug" feature is undocumented

Change by Ama Aje My Fren : -- nosy: +amaajemyfren nosy_count: 5.0 -> 6.0 pull_requests: +20645 pull_request: https://github.com/python/cpython/pull/21509 ___ Python tracker <https://bugs.python.org/issu

[issue41045] f-string's "debug" feature is undocumented

Ama Aje My Fren added the comment: > then we can merge that one and close *this* issue. I am looking at the pydoc issue now. It will take me more than an hour but I will figure it. Can that be under this issue also or (since you raised it as an OT) make that another is

[issue41411] Improve and consolidate f-strings docs

Ama Aje My Fren added the comment: Hi Ezio, Would you see this being resolved in part by a HOWTO document? -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue41

[issue41045] f-string's "debug" feature is undocumented

Change by Ama Aje My Fren : -- pull_requests: +20698 pull_request: https://github.com/python/cpython/pull/21552 ___ Python tracker <https://bugs.python.org/issue41

[issue41045] f-string's "debug" feature is undocumented

Ama Aje My Fren added the comment: Hello all, I have attempted to resolve this issue by adding some comments to PR21464 and later provided a reworded PR21509 that attempts to resolve this using ideas from @rishi93. Finally I have tried to document f-string within pydoc itself with PR21552