[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 searchindex[2] is generated once when the html is being created. This is then used, locally, when user does search. Still it is not very good. Multiple word queries[3] and hyphenated words don't appear to work[4] well (I also tested this locally, f-string does not get searchindexed while fstring does. Searching also gives the lexical analysis as one of the pages when searching for fstring.) > What about doing the following: > * keep having stdtypes.rst cover and explain all the built-in types and their > features; > * move the "Format String Syntax", "Format Specification Mini-Language", > "Format examples" sections from string.rst to stdtypes.rst where they belong; > * integrate f-strings in these sections, and add a new section explaining > f-string-specific quirks; > * leave the printf-style string formatting in stdtypes.rst, after the format > sections > * use string.rst to document the string module and its objects, hence leaving > string.Formatter and string.Template here, where they belong > (string.Formatter is self contained enough that doesn't need to be with the > other format sections); > * leave the inputoutput.rst and lexical_analysis pages as they are; > * update the introduction.rst page to mention f-string; introduction.rst has a reference to "Formatted string literals" in the "See also:" box[5]. But I can still put an example here. Should we put both str.format() and f-strings, or make this exclusively for f-strings? > * once all this is done, update all links to point to the appropriate > sections and cross-link all related sections; Ok. Please can we progress as follows: (Each as sequential and independent PR) 1) f-string added to stdtypes.rst. I have done this in PR 21552. We can complete that one and commit it as the first step. It provides both the f-string and the f-string-specific quacks. 2) Add the same wording of f-string to pydoc. I have been studying how to do this. At this moment help(fstring) and help(f-string) do not work. PS C:\> py -3.9 Python 3.9.0b5 (tags/v3.9.0b5:8ad7d50, Jul 20 2020, 18:35:09) [MSC v.1924 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help(fstring) Traceback (most recent call last): File "", line 1, in NameError: name 'fstring' is not defined >>> help(f-string) Traceback (most recent call last): File "", line 1, in NameError: name 'f' is not defined >>> 3) Move "Format String Syntax", "Format Specification Mini-Language", "Format examples" sections from string.rst to stdtypes.rst and ensure references all work well. 4) Add additional f-string-quarks as we discuss into stdtypes.rst. [0] https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#index-generating-markup [1] https://docs.python.org/dev/genindex-F.html [2] https://docs.python.org/dev/searchindex.js [3] https://github.com/sphinx-doc/sphinx/issues/1486 [4] https://github.com/sphinx-doc/sphinx/issues/1486#issuecomment-122115215 [5] https://docs.python.org/3.9/tutorial/introduction.html -- ___ Python tracker <https://bugs.python.org/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 have information about f-strings. The tutorial[0] and the reference[1] I have done PR 21681 that adds index to the tutorial although searching[2][3] does not seem to be better now that the reference has an index. > The lexical analysis is probably fine as is. I agree. > The introduction in the tutorial should mention f-strings This is there[0] but it _IS_ hard to find, when you don't know it is there. It may not be very "introduction-y", and if you like I can make a go at trying to reword it. > The stdtypes page is already quite long and crowded ... True. But is this wrong? In my feeling this is reference documentation. It should be accurate, complete and clear. It may not need to be "textbook-like". Some thoughts: - There may be benefit in reorganising stdtypes.rst to improve the flow without changing the actual content. This could mean breaking it up into a number of documents rather than the monolith it is. - It does feel like printf[4] was plugged in later because str.format()[5] had been explained earlier. (Although I believe printf came before str.format()). A first time reader of the document will find it hard to know the one way that is right when it comes to formatting. - f-strings should probably also be described here because it _is_ built in, no? It may not be accurate to say it is in /Lib/strings. There is no reference that a developer can just look at to remind/confirm to themselves how to "do it". > So, unless we add a separate page somewhere This is why I was thinking of a HOWTO. Going back to your original pain in msg371912, someone wanted the f-string documentation and: -- It was hard to find. (indexing? better table of contents?) -- It was not very helpful WHEN it was found. (A second entry with f-strings in Lib that is easier for a dev to use?) But now (and this is mainly to me) it appears that another problem is a need to consistently, clearly, and in one place describe the various elements/nuances/eccentricities of presenting data in Python: - string - string.Formatter, - string.Template, - str.format() - f-string - Format Specification Mini-Language - maybe even __format__ and conversion? - etc I propose one of the following two: 1) A new section in Library documentation just to handle strings, then systematically removing them elsewhere.(Built-In Functions, Built-In Types, Text Processing Services) 2) We take all that Python history and explain it in a HOWTO, and add a developer friendly reference in the Library for f-string. More like Logging Cookbook rather than Logging Howto. !) above is similar to what you propose ... but different-ish. [0] https://docs.python.org/dev/tutorial/inputoutput.html#formatted-string-literals [1] https://docs.python.org/dev/reference/lexical_analysis.html#f-strings [2] https://docs.python.org/dev/search.html?q=fstring [3] https://docs.python.org/dev/search.html?q=f-string [4] https://docs.python.org/dev/library/stdtypes.html#printf-style-bytes-formatting [5] https://docs.python.org/dev/library/stdtypes.html#str.format -- ___ Python tracker <https://bugs.python.org/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 issue? -- ___ Python tracker <https://bugs.python.org/issue41045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. I request please that they be marked with skip-news. Also request feedback on the PRs. -- ___ Python tracker <https://bugs.python.org/issue41045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue41045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue25377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue25377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue24921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 cpython uses. I _think_ it uses three: a. Travis cpython/.travis.yml b. Github Actions .github/workflows/doc.yml c. Azures Pipelines .azure-pipelines/docs-steps.yml Beyond that no idea. I fear I am also blind here. Still google is my friend. -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue40770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 within Windows that break these rules. In my case it was to add the colon (:) to a file name. In Python for windows this would fail because the underlying system API would stop it from happening (and in zip, it will be changed to an underscore (_)) - but it is unclear what would actually happen if you do so. In the old days just trying to open C:\Con\Con (which did not exist) caused a BSOD. > > What is the safe way to use it? > The Security message suggests _with care_ - to wit - "Never extract archives from untrusted sources without prior inspection." There may be no absolutely safe way if the zipfile was crafted maliciously. Just like there are inherent vulnerabilities in using XML ... (https://docs.python.org/3/library/xml.html#xml-vulnerabilities). If a zipped file had a tree starting at C:\ and replaced a dll in C:\Windows (and was running as Admin), a lot of caveats I know, but it could be a problem. > I think documenting "this function is unsafe" without suggesting a > replacement or a safe way to use it isn't very constructive: as a developer, > I want to extract a zip archive, but the only function supposed to do the job > tells me "this is unsafe". Ok, so what am I supposed to do to be safe? Does it say that unzipping a file is unsafe? It looks to me like it says that in special conditions the extraction of a zipped file tree may be unsafe and it is important to use caution. It is the case in a lot of programming, is it not, that there are instances of security vulnerabilities entering ordinary looking code? It happens in sql (https://xkcd.com/327/) and many places within Python's Standard Library (https://hackernoon.com/10-common-security-gotchas-in-python-and-how-to-avoid-them-e19fbe265e03) even something as innocuous as using the new-style string format (https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/). > > That's what documentation should tell me, not let me puzzled with doubt. > This is an interesting point. What is the scope of Python Library Documentation? I disagree with your view on scope. In my view the Library Documentation should focus on what is exposed in the library for ordinary use. So e.g. implementation details may not be expected to be shown in the Documentation (like there is no documentation for zipfile._extract_member()). It does have a duty of care - especially to well known gotchas - but it is _not_ security documentation. I think (this is my view, it is not god given) that in many cases it is fair to assume that if one told a developer to be careful with her code it is enough in so far as library documentation is concerned. Thanks. -- title: zipfile.extractall is safe by now? -> zipfile.extractall is safe by now ___ Python tracker <https://bugs.python.org/issue40763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue40558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 what was discussed in msg181646 on issue6972. What I see is that from CPython 3.4 (https://docs.python.org/3.4/library/zipfile.html#zipfile.ZipFile.extractall) while the security warning is still there they add the following line in it: > This module attempts to prevent that. See extract() note. The extract() note goes into some detail to explain what and how they attempt to prevent it. It is not obvious to me that zipfile._extract_member() together with (for windows) zipfile._sanitize_windows_name() have handled everything that could happen. May I suggest that out of caution we leave it as it is? -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue40763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 output. > Yes, that is my understanding of the devguide. > As someone who is currently learning Python, however, consistency in > presentation is important to me and reduces cognitive load. This is a valid concern, but it may not be the case that all people will face this issue. More importantly it should be right so the second time you come back to refresh on a point you can also grasp it quickly ... no? > > By REPL, do you mean Read-Eval-Print Loop? I'm not familiar with the acronym > and that's what Google is telling me it means. But a Read-Eval-Print Loop > would have output, > and my understanding is that you are arguing against use of ... when there is > no output. > Yes - that is the shell of CPython that does the Read-Eval-Print Loop. My reading of the Docs Dev-quide - and I am not an expert - discourages the sys.ps1 and sys.ps2 (although the current docs site can hide them to allow for copy-pasta) -- ___ Python tracker <https://bugs.python.org/issue40748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ... screen prompts that show elsewhere in the > tutorial. This is potentially confusing to readers. > > I am going to attempt a PR by May 26, 2020. Are those sections really to be entered in the REPL or could they be seen as independent code blocks in a file e.g.? >From the dev guide https://devguide.python.org/documenting/#code-examples > The ellipsis for the sys.ps2 secondary interpreter prompt should only be used > sparingly, > where it is necessary to clearly differentiate between input lines and output > lines. > Besides contributing visual clutter, it makes it difficult for readers to > cut-and-paste > examples so they can experiment with variations. None of those sections has output ... so maybe not put the ellipsis? -- title: Tutorial 4 More Control Flow Tools missing screen prompts in some code blocks -> Tutorial 4.7 More on Defining Functions missing screen prompts ___ Python tracker <https://bugs.python.org/issue40748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 should handle it. PR against master(dev/3.10) should be enough. -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue40748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/file49186/docs.python.org.png ___ Python tracker <https://bugs.python.org/issue40733> __ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 versions. For us, most likely, we keep to the releases (maybe behind the very current version, but unlikely that we are compiling in the latest bug fixes, or (and here I could be absolutely wrong) pulling from a distribution that is). (If they are compiling their own Python with bug fixes, is it fair to assume they are also preparing their own documentation? Not sure.) Say I am using Python 3.7.5, the documentation, being for Python 3.7.7, is (hopefully?) sufficient for me to know it is not the same as the IDLE I am using - the addition of the date may help emphasize the point, but chances are I don't track the release schedule/know when my IDLE was packaged for me and so it may only further confuse me. I suggest that if the page has the release version don't also provide the "as of " . Now if Documentation for all patchlevels were available ... but I suspect that may not be possible. Thinking about it though Paul said: So I looked for it on the main docs page, docs.python.org, and didn't find it there. I ended up finding it by web search. > > From 3.5 there is a search on the top right of docs.python.org: @phr is that what you meant by web search or did you use google/bing/etc? Most likely many people use the search to find what they want from docs.python.org ... or it is hardly used. On Sat, May 23, 2020 at 4:14 AM Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > I agree that finding the online doc is slight pain. It is not listed in > the Modules index because idlelib, not IDLE, is the stdlib module, and does > not have a doc page. I may add one or, if possible, make the page serve as > one, as part of this issue. 'IDLE' *is* in the Index, and the first link > is the correct one. > > I don't control and would not unilaterally change the main page. I am > hesitant because I expect that there are people who would think it unfair > or deceptive to especially promote IDLE this way versus other stdlib > packages and non-stdlib IDEs and editors. I might subscribe to and post on > python-ideas to see what other users think. > > Help => IDLE Help displays an offline copy of idle.html as of the release > date in a tktinker text window. Have you noticed that? Would "IDLE doc" > be clearer? > > 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 ] > > -- > nosy: +taleinat > stage: -> needs patch > title: mention IDLE in main python docs page -> Make IDLE doc more > visible, mention in main python docs page > versions: +Python 3.10, Python 3.7, Python 3.8, Python 3.9 > > ___ > Python tracker > <https://bugs.python.org/issue40733> > ___ > ___ > docs mailing list -- d...@python.org > To unsubscribe send an email to docs-le...@python.org > https://mail.python.org/mailman3/lists/docs.python.org/ > Member address: amaajemyf...@gmail.com > -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue40733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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:20 PM Hanno Boeck wrote: > > New submission from Hanno Boeck : > > I'm not sure if this is a good place to report this, but I haven't found a > separate bug tracker or feedback contact for the webpages. > > https://pl.python.org/ > has an expired certificate and it contains a prominent link to django.pl, > which itself returns a DNS SERVFAIL error. > > -- > assignee: docs@python > components: Documentation > messages: 369531 > nosy: docs@python, hanno > priority: normal > severity: normal > status: open > title: pl.python.org has expired cert and links to nonexistent django.pl > page > > ___ > Python tracker > <https://bugs.python.org/issue40717> > ___ > ___ > docs mailing list -- d...@python.org > To unsubscribe send an email to docs-le...@python.org > https://mail.python.org/mailman3/lists/docs.python.org/ > Member address: amaajemyf...@gmail.com > -- nosy: +amaajemyfren ___ Python tracker <https://bugs.python.org/issue40717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to explain why it is rejected). My feeling is that putting two references complicates the goal of explaining it. -- ___ Python tracker <https://bugs.python.org/issue40434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue40434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 there is, however, PEP 3103(https://www.python.org/dev/peps/pep-3103/) which rejected the proposal for a switch statement. -- assignee: docs@python components: Documentation messages: 367633 nosy: amaajemyfren, docs@python priority: normal severity: normal status: open title: Update of reasoning why there is no case statement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue40166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of Unicode code points assigned so far. This document does not appear to be changed to concur with the number of actual code points supported by CPython or the latest standard by Unicode, Inc (http://www.unicode.org/versions/latest/#Summary). I propose that a change be done to reflect the current number of code points. -- assignee: docs@python components: Documentation messages: 365672 nosy: amaajemyfren, docs@python priority: normal severity: normal status: open title: UNICODE HOWTO: Change the total number of code points in the introduction section versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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#section-1.3> seems that: This document's goal is to apply the errata, remove inconsistencies with other specifications of JSON, and highlight practices that can lead to interoperability problems. When one reads a diff of the two RFCs together <https://www.diffchecker.com/xJoy0BDJ>, the only place that seems to have changed from a protocol point of view is in Section 8.1 (RFC 7159 <https://tools.ietf.org/html/rfc7159#section-8.1>, RFC 8259 <https://tools.ietf.org/html/rfc8259#section-8.1>) which now (RFC 8259) requires that all data should be encoded using UTF-8. The security section <https://tools.ietf.org/html/rfc8259#section-12> in the current (RFC 8259) standard states: certain characters such as U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are legal in JSON but not JavaScript (This has changed in the latest ECMAScript Edition) Therefore from my understanding: 1. which document better describes the behavior of our json module? The json module allows for utf-16 and utf-32 encoding in the loads method. It does not appear to enforce the utf-8 encoding - so closer to RFC 7159. 2. Does it need to be updated along with a doc change? Maybe. I defer to the maintainers of the module. On Sun, Mar 29, 2020 at 2:09 AM Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > The header for 8259 says "Obsoletes: 7159" (December 2017) and the header > for 7159 agrees: "Obsoleted by: 8259". But... to the extent that there is > any difference, which document better describes the behavior of our json > module? Does it need to be updated along with a doc change? > > -- > nosy: +ezio.melotti, rhettinger, terry.reedy > > ___ > Python tracker > <https://bugs.python.org/issue40090> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue40090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: Documentation messages: 365162 nosy: amaajemyfren, docs@python priority: normal severity: normal status: open title: The referenced RFC for the json module should be corrected to rfc8259 type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40090> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is though that the shutdown() call must be run in a different thread than the one where the serve_forever() was called otherwise it will deadlock. This is documented in the [code](https://github.com/python/cpython/blob/3.8/Lib/socketserver.py#L244) but not in the documentation. It should be in the documentation as well as it is not obvious. -- assignee: docs@python components: Documentation messages: 362981 nosy: amaajemyfren, docs@python priority: normal severity: normal status: open title: shutdown() in socketserver.BaseServer should be in a different thread from serve_forever() type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
