"inherits <someclass>" grates to this reader. I think it should be "inherits from <someclass>".
(cherry picked from commit c9c6e04380)
Co-authored-by: Skip Montanaro <skip.montanaro@gmail.com>
PI objects instead of comment objects.
(cherry picked from commit de6f97cd35)
Co-authored-by: Christophe Nanteuil <35002064+christopheNan@users.noreply.github.com>
gh-111112: Avoid potential confusion in TCP server example. (GH-111113)
Improve misleading TCP server docs and example.
socket.recv(), as documented by the Python reference documentation,
returns at most `bufsize` bytes, and the underlying TCP protocol means
there is no guaranteed correspondence between what is sent by the client
and what is received by the server.
This conflation could mislead readers into thinking that TCP is
datagram-based or has similar semantics, which will likely appear to
work for simple cases, but introduce difficult to reproduce bugs.
(cherry picked from commit a79a27242f)
Co-authored-by: Aidan Holm <alfh@google.com>
Add note to `sys.orig_argv` clarifying the difference from `sys.argv` (GH-114630)
(cherry picked from commit 1836f674c0)
Co-authored-by: Bradley Reynolds <bradley.reynolds@darbia.dev>
Co-authored-by: Ned Batchelder <ned@nedbatchelder.com>
Prior to gh-114269, the iterator returned by ElementTree.iterparse was
initialized with the root attribute as None. This restores the previous
behavior.
(cherry picked from commit 66f95ea6a6)
Co-authored-by: Sam Gross <colesbury@gmail.com>
The text clearly seems to be referencing `TestFuncAcceptsSequencesMixin`,
for which no target is available. Name the class properly and suppress
the dangling reference.
(cherry picked from commit 7a93db4425)
Co-authored-by: Skip Montanaro <skip.montanaro@gmail.com>
A 'single tuple' means 'one tuple, of whatever length.
Remove the unneeded and slightly distracting parenthetical 'singleton' comment.
(cherry picked from commit a1332a99cf)
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
gh-110893: Improve the documentation for __future__ module (GH-114642)
nedbat took issue with the phrasing "real module". I'm actually fine
with that phrasing, but I do think the `__future__` page should be clear
about the way in which the `__future__` module is special. (Yes, there
was a footnote linking to the future statements part of the reference,
but there should be upfront discussion).
I'm sympathetic to nedbat's claim that no one really cares about
`__future__._Feature`, so I've moved the interesting table up to the
top.
(cherry picked from commit 3b86891fd6)
Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
(cherry picked from commit 6c2b419fb9)
- consistently use correct parameter markup
- consistently use submodule name as database name
- improve accuracy of the dbm.dumb.open() spec
- remove dumbdbm class refs and replace them with generic "database object"
- use parameter list for dbm.dumb.open()
(cherry picked from commit 6c2b419fb9)
Co-authored-by: Erlend E. Aasland <erlend@python.org>
It now always encodes non-ASCII characters in headers if utf8 is false.
(cherry picked from commit 504334c7be)
Co-authored-by: Rito Takeuchi <licht-t@outlook.jp>
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Also consolidate following paragraphs regarding database objects.
(cherry picked from commit 0bd8297a22)
Co-authored-by: Erlend E. Aasland <erlend@python.org>
(cherry picked from commit 4cf068ed08)
- add abbreviation directives for NDBM and GDBM
- consistently spell NDBM as NDBM
- silence broken ndbm class refs
- improve accuracy of dbm.ndbm.open() spec
- use replacement text for NDBM/GDBM file format incompatibility note
- add refs to other parts of the docs (dict, bytes, etc.)
- clarify whichdb() return value by using list markup
- silence refs to example or generic submodule methods (keys, get, etc.)
(cherry picked from commit 65cf5dce11)
Co-authored-by: Erlend E. Aasland <erlend@python.org>
