[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: (First time contributor here seeking guidance) I see that this problem of automatically linking to the unintended page has occurred in other parts of the docs and has been handled in another way - In Doc/library/functions.rst, local targets are used with replacement texts- unintended linking code- :func:`dict` local target code- |func-dict|_ and this substitution is added- .. |func-dict| replace:: ``dict()`` Would this be the preferred way of solving this? I tried this change and it achieves the correct linking for me -- nosy: +meersuri ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: I looked through the sys.float_info docs and I guess that you are referring to the max and min attributes of sys.float_info that are linking to the built-in max() and min() functions? In that case as there is no documentation for the max and min attributes of sys.float_info, should they not link to anything? -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46494] Mention typing_extensions in the typing documentation
Meer Suri added the comment: (First time contributor looking for guidance) Is this diff okay? I'm not sure if the package name should be typing-extensions, or if the formatting is okay diff --git a/Doc/library/typing.rst b/Doc/library/typing.rst index 94a46b01a1..c0fe656c1c 100644 --- a/Doc/library/typing.rst +++ b/Doc/library/typing.rst @@ -32,6 +32,11 @@ In the function ``greeting``, the argument ``name`` is expected to be of type :class:`str` and the return type :class:`str`. Subtypes are accepted as arguments. +New features have been added to the typing module in each major version of +Python. The `typing_extensions <https://pypi.org/project/typing-extensions/>`_ +package provides backports to all supported versions of Python 3 for almost +all of these features. + .. _relevant-peps: Relevant PEPs -- nosy: +meersuri ___ Python tracker <https://bugs.python.org/issue46494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46494] Mention typing_extensions in the typing documentation
Change by Meer Suri : -- keywords: +patch pull_requests: +29426 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31260 ___ Python tracker <https://bugs.python.org/issue46494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: It took me some time to figure out how to prevent the creation of a reference/hyperlink using the ! prefix. I've made the change to remove the references to the max and min attributes of sys.float_info and pushed. How do I find other instances of this problem? Is there a systematic way to look for such references? -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: Can someone guide me on why I'm getting a no-new-line at end of file error for the NEWS entry when I didnt change this file in the last commit and it passed the Azure checks earlier Error: [1] ../Misc/NEWS.d/next/Documentation/2022-02-08-15-38-16.bpo-46586.6qVFVL.rst:0: No newline at end of file (no-newline-at-end-of-file). Do I need to manually add the new line? -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: Thanks Jelle for the cool idea of the script to look for more instances of this problem. I've been working on this script and am still refining it, but one of the candidates that my program returned is in zipfile.rst - https://docs.python.org/3.11/library/zipfile.html?highlight=zipfile#zipfile.ZipFile.open Changed in version 3.6: open() can now be used to write files into the archive with the mode='w' option. Changed in version 3.6: Calling open() on a closed ZipFile will raise a ValueError. Previously, a RuntimeError was raised. Here the first instance of open() points to the builtins function rather than ZipFile.open(), whereas the second instance points to ZipFile.open(). Seems like a true positive to me, what do you think? -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: Also this one?- https://docs.python.org/3.11/library/urllib.request.html?highlight=urllib%20request#urllib.request.OpenerDirector.open Arguments, return values and exceptions raised are the same as those of urlopen() (which simply calls the open() method on the currently installed global OpenerDirector). open() points to the builtins function but the markup used is :meth:`open` and the logic of the sentence suggests the link was meant to be to OpenerDirector.open() -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: Looks like another one - https://docs.python.org/3.11/library/fileinput.html#fileinput.hook_encoded Deprecated since version 3.10: This function is deprecated since input() and FileInput now have encoding and errors parameters. The input() here points to builtins which doesnt have the mentioned parameters -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Meer Suri added the comment: https://docs.python.org/3.11/library/io.html?highlight=io#text-i-o - The easiest way to create a text stream is with open(), optionally specifying an encoding: https://docs.python.org/3.11/library/io.html?highlight=io#binary-i-o - The easiest way to create a binary stream is with open() with 'b' in the mode string: For both of these cases, the markup for the open() is :meth:`open()` but it links to the builtins open(), which I see is an alias of io.open() so maybe it doesn't matter? Another question is why do only these two instances use :meth: while the other instances in the file use :func: (some refer directly to builtins open() so its understandable, but not all instances) I'm wondering if the above two should be left alone or changed to :meth:`~io.open` or even :func:`open` -- ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46586] In documentation contents enum.property erroneously links to built-in property
Change by Meer Suri : -- pull_requests: +29564 pull_request: https://github.com/python/cpython/pull/31429 ___ Python tracker <https://bugs.python.org/issue46586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
