New submission from glubs9 <jonte.fry(a)gmail.com>:
in the dis library documentation where it lists all of the instructions in python bytecode, it includes a small sentence about half way dow "all of the following instructions use their arguments".
After this sentence there is an instruction specified LIST_TO_TUPLE which does not in fact use its argument.
It's a minor mistake but 100% on how it should be fixed so I have not yet made a pr. It could be fixed by removing the sentence or just moving it above the sentence. I'm not sure.
----------
assignee: docs@python
components: Documentation
messages: 394178
nosy: docs@python, glubs9
priority: normal
severity: normal
status: open
title: LIST_TO_TUPLE placed below the sentence "all of the following use their opcodes" in dis library documentaiton.
type: enhancement
versions: Python 3.11
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44213>
_______________________________________
New submission from ShinWonho <new170527(a)kaist.ac.kr>:
In Python Language Reference 10.Full Grammar Specification
typo: assigment_expression
verbous grammar: expressions and star_expression
----------
assignee: docs@python
components: Documentation
messages: 394630
nosy: docs@python, orangebana15
priority: normal
severity: normal
status: open
title: typo and verbous grammar in the grammar spec
type: enhancement
versions: Python 3.11
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44257>
_______________________________________
New submission from Gregory P. Smith <greg(a)krypto.org>:
https://docs.python.org/3/library/enum.html#private-names
"""
_Private__names
Private names will be normal attributes in Python 3.10 instead of either an error or a member (depending on if the name ends with an underscore). Using these names in 3.9 will issue a DeprecationWarning.
"""
It isn't clear from this documentation what is meant by "private names". Please expand on this to be explicit about what name pattern is being described.
----------
assignee: docs@python
components: Documentation
messages: 393919
nosy: docs@python, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Unclear meaning of _Private__names in enum docs.
versions: Python 3.10, Python 3.11, Python 3.9
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44174>
_______________________________________
New submission from STINNER Victor <vstinner(a)python.org>:
The https://docs.python.org/dev/c-api/init.html documentation lists many functions which is the legacy way to configure the Python initialization. These functions are kept for backward compatibility but have flaws and are less reliable than the new PyConfig API (PEP 587) documented at https://docs.python.org/dev/c-api/init_config.html
I propose to deprecate the legacy functions to configure the Python initialization. Examples:
* Py_SetPath()
* Py_SetProgramName()
* Py_SetPythonHome()
* Py_SetStandardStreamEncoding()
* PySys_AddWarnOption()
* PySys_AddWarnOptionUnicode()
* PySys_AddXOption()
I don't propose to schedule the removal of these functions, only mark them as deprecated in the *documentation*.
Related issue: bpo-43956 "C-API: Incorrect default value for Py_SetProgramName" and PR 24876.
----------
assignee: docs@python
components: C API, Documentation
messages: 393499
nosy: docs@python, vstinner
priority: normal
severity: normal
status: open
title: [C API] Deprecate legacy API for configure Python initialization
versions: Python 3.11
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44113>
_______________________________________
New submission from João Henrique Pimentel <joaozinho(a)gmail.com>:
The second parameter (classinfo) of the issubclass built-in function can be a Tuple and, starting from 3.10, it can be a Union Type as well.
The documentation states that in these cases "every entry in classinfo will be checked", but it doesn't explain if the check is AND (all) or OR (any). In contrast, the documentation of isinstance is clear: "return True if object is an instance of *any* of the types".
Here's a possible rewriting that reduces the odds of incorrect interpretations, based on the text of isinstance:
ORIGINAL: "in which case every entry in classinfo will be checked"
PROPOSAL: "in which case return True if class is a subclass of any entry in classinfo"
----------
assignee: docs@python
components: Documentation
messages: 393684
nosy: docs@python, joaozinho
priority: normal
severity: normal
status: open
title: issubclass documentation doesn't explain tuple semantic
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44135>
_______________________________________
New submission from Ahmet Burak <ahmetbozyurtt(a)gmail.com>:
Using Point class as in the documentation example, raises TypeError: Point() takes no arguments
https://docs.python.org/3.10/whatsnew/3.10.html#patterns-and-classes
Also there is same example in the PEP 636's latests parts, Point class used with dataclass decorator and works perfectly.
https://www.python.org/dev/peps/pep-0636/
----------
assignee: docs@python
components: Documentation
messages: 393454
nosy: ahmetveburak, docs@python
priority: normal
severity: normal
status: open
title: missing dataclass decorator in match-statement example
type: behavior
versions: Python 3.10
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44109>
_______________________________________
New submission from Isaac Ge <otakutyrant(a)gmail.com>:
str.istitle(): Return True if the string is a titlecased string and there is at least one character, for example uppercase characters may only follow uncased characters and lowercase characters only cased ones. Return False otherwise.
I saw this description from the doc. But what does "cased" andd "uncased" mean? I looked it up on a dictionary, and the latter only says: "cased in something: completely covered with a particular material".
I think "cased" may be "capitalized", but, if so, the usage of the former is not endorsed by dictionaries so that I think this word is confusing or informal. so does "uncased".
----------
assignee: docs@python
components: Documentation
messages: 393920
nosy: docs@python, otakutyrant
priority: normal
severity: normal
status: open
title: What does "cased" and "uncased" mean?
versions: Python 3.9
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44175>
_______________________________________
New submission from Jesse Silverman <jessevsilverman(a)gmail.com>:
I didn't know whether to file this under DOCUMENTATION or WINDOWS.
I recently discovered the joys of the interactive help in the REPL, rather than just help(whatever).
I was exploring the topics and noticed multiple encoding or rendering errors.
I realized I stupidly wasn't using the Windows Terminal program but the default console. I addressed that and they persisted in Windows Terminal.
I upgraded from 3.9.1 to 3.9.5...same deal.
I tried running:
Set-Item -Path Env:PYTHONUTF8 -Value 1
before starting the REPL, still no dice.
I confirmed this worked in the same session:
>>> ustr2='ʑʒʓʔʕʗʘʙʚʛʜʝʞ'
>>> ustr2
'ʑʒʓʔʕʗʘʙʚʛʜʝʞ'
It does.
The help stuff that doesn't render correctly is under topic COMPARISON:
lines 20, 21 and 25 of this output contain head-scratch-inducing mystery characters:
help> COMPARISON
Comparisons
***********
Unlike C, all comparison operations in Python have the same priority,
which is lower than that of any arithmetic, shifting or bitwise
operation. Also unlike C, expressions like "a < b < c" have the
interpretation that is conventional in mathematics:
comparison ::= or_expr (comp_operator or_expr)*
comp_operator ::= "<" | ">" | "==" | ">=" | "<=" | "!="
| "is" ["not"] | ["not"] "in"
Comparisons yield boolean values: "True" or "False".
Comparisons can be chained arbitrarily, e.g., "x < y <= z" is
equivalent to "x < y and y <= z", except that "y" is evaluated only
once (but in both cases "z" is not evaluated at all when "x < y" is
found to be false).
Formally, if *a*, *b*, *c*, …, *y*, *z* are expressions and *op1*,
*op2*, …, *opN* are comparison operators, then "a op1 b op2 c ... y
opN z" is equivalent to "a op1 b and b op2 c and ... y opN z", except
that each expression is evaluated at most once.
Note that "a op1 b op2 c" doesnΓÇÖt imply any kind of comparison between
*a* and *c*, so that, e.g., "x < y > z" is perfectly legal (though
perhaps not pretty).
That is: …, …, ’
em-dash or ellipsis might be involved somehow...maybe fancy apostrophe?
My current guess is that it isn't about rendering anymore, because something went awry further upstream?
Thanks!
----------
assignee: docs@python
components: Documentation
messages: 394817
nosy: docs@python, jessevsilverman
priority: normal
severity: normal
status: open
title: Is there a mojibake problem rendering interactive help in the REPL on Windows?
type: behavior
versions: Python 3.9
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44275>
_______________________________________
New submission from Sebastian Rittau <srittau(a)rittau.biz>:
The documentation of socket.SocketType (https://docs.python.org/3/library/socket.html?highlight=sockettype#socket.S…) is misleading. It states:
This is a Python type object that represents the socket object type. It is the same as type(socket(...)).
This is untrue. socket.SocketType is in reality re-exported from _socket, where it is an alias for class _socket.socket, a super type of class socket.socket. I think that either the documentation should be fixed, or SocketType should be moved to socket and made an alias of socket.socket.
----------
assignee: docs@python
components: Documentation
messages: 394665
nosy: docs@python, srittau
priority: normal
severity: normal
status: open
title: SocketType documentation misleading
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue44261>
_______________________________________
Joannah Nanjekye <nanjekyejoannah(a)gmail.com> added the comment:
New changeset 5f28752f5b51a1866f2428eeaf6082266723c78d by Zackery Spytz in branch 'main':
bpo-43750: Fix incorrect reference to PACKET_MULTIHOST in the docs (GH-25241)
https://github.com/python/cpython/commit/5f28752f5b51a1866f2428eeaf60822667…
----------
nosy: +nanjekyejoannah
_______________________________________
Python tracker <report(a)bugs.python.org>
<https://bugs.python.org/issue43750>
_______________________________________