Mailman 3 April 2021 - docs

[issue43750] Undefined constant PACKET_MULTIHOST referred to in package socket
by Tom Cook 06 Apr '21

06 Apr '21

New submission from Tom Cook <tom.k.cook(a)gmail.com>: The documentation for the `AF_PACKET` address family refers to `PACKET_MULTIHOST`. I believe this should read `PACKET_MULTICAST`, which is defined on Linux systems (`PACKET_MULTIHOST` is not). ---------- assignee: docs@python components: Documentation messages: 390345 nosy: Tom Cook, docs@python priority: normal severity: normal status: open title: Undefined constant PACKET_MULTIHOST referred to in package socket type: enhancement versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43750> _______________________________________

2 1

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by STINNER Victor 06 Apr '21

06 Apr '21

STINNER Victor <vstinner(a)python.org> added the comment: > In this case, having it off by default goes further to prevent breakage PyYAML was unsafe by default: it allowed to execute arbitary Python code by default. It took years to change the default to "safe". I don't think that adding a parameter for opt-in for security is a good approach. An application can use ipaddress internally without being aware of using it, if it's done by a third party module. It's hard to prevent security vulnerabilities if people have to "opt-in" for security. I prefer to break code and force people to manually get back the old behavior. It's better to make 90% safe by default but make 10% of people unhappy. It's uncommon to pass IPv4 addresses with leading zeros. If you want to tolerate leading zeros, you don't have to modify the ipaddress for that, you can pre-process your inputs: it works on any Python version with or without the fix. >>> def reformat_ip(address): return '.'.join(part.lstrip('0') if part != '0' else part for part in address.split('.')) ... >>> reformat_ip('0127.0.0.1') '127.0.0.1' Or with an explicit loop for readability: def reformat_ip(address): parts = [] for part in address.split('.'): if part != "0": part = part.lstrip('0') parts.append(part) return '.'.join(parts) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

2 1

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Steve Dower 06 Apr '21

06 Apr '21

Steve Dower <steve.dower(a)python.org> added the comment: The important quote from the linked issue seems to be: > Our new separator= parameter does not allow one to achieve the previous behavior if mixing and matching & And ; was intended to be allowed, as it is a single separator rather than a set of separators. So arguably, we added _the wrong_ parameter in that case, because it only allowed choosing between behaviours not including the "bad" behaviour. We should've added one that was "give me back the previous behaviour". In this case, having it off by default goes further to prevent breakage, and I wouldn't be opposed to a process level opt-in (e.g. a module-level flag), so that _applications_ have a way to force their dependencies to use the safer behaviour without needing to patch them. Similarly, a process level opt-out also seems good enough if we were to have it on by default. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by STINNER Victor 06 Apr '21

06 Apr '21

STINNER Victor <vstinner(a)python.org> added the comment: > Withdrawing the readiness - @ambv and I would prefer to see this behind a flag (probably "strict" parsing), on by default for 3.10, and maybe on by default for 3.9/earlier. Last time we added a new parameter in a stable branch, it didn't go well: https://bugs.python.org/issue42967#msg387638 ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue43325] Documentation should warn that 'is' is not a safe comparison operator for most values.
by Anthony Flury 06 Apr '21

06 Apr '21

New submission from Anthony Flury <anthony.flury(a)btinternet.com>: A frequent bug for beginners is to assume that 'is' is somehow 'better' then '==' when comparing values, and it is certainly a cause for confusion amongst beginners as to why: [1,2] is [1,2] evaluates to False but 'a' is 'a' evaluates to True and many similar examples. As far as I can see the first mention of the 'is' operator is under Section 5 - More on conditionals : https://docs.python.org/3/tutorial/datastructures.html?highlight=comparison…; and it is mentioned thus : The operators is and is not compare whether two objects are really the same object; this only matters for mutable objects like lists. As we know though this statement is misleading - it suggests that 'is' can be used to compare immutable values (ints, strings, tuples) etc, and while for some values of some immutables (small ints, shortish strings) 'is' can be used as an equivalent of '==' it wont be clear from this 'statement' that 'is' is simply not a safe way to compare values. There needs to be a warning here about 'is' and how it is not an equivalent to '==' in any general sense. ---------- assignee: docs@python components: Documentation messages: 387692 nosy: anthony-flury, docs@python priority: normal severity: normal status: open title: Documentation should warn that 'is' is not a safe comparison operator for most values. type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43325> _______________________________________

4 8

[issue43738] Clarify public name of curses.window
by Ryan McCampbell 06 Apr '21

06 Apr '21

New submission from Ryan McCampbell <rmccampbell7(a)gmail.com>: Until 3.8 the curses window class was not directly available in code, but now it is available as `_curses.window`. This is not explicitly stated in the documentation (although it is consistent with how the method signatures are written). It is useful to have a public name for the type to aid IDE's with explicit type annotations, i.e. @curses.wrapper def main(stdscr: curses.window): stdscr.addstr(...) See https://github.com/python/typeshed/pull/5180, which adds this name to type hints in the typeshed project. This name should be more clearly documented so programmers can annotate the type without worrying that it may change (which will cause a runtime error unless it is quoted). ---------- assignee: docs@python components: Documentation messages: 390266 nosy: docs@python, rmccampbell7 priority: normal severity: normal status: open title: Clarify public name of curses.window type: enhancement versions: Python 3.10, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43738> _______________________________________

2 1

[issue43689] difflib: mention other "problematic" characters in documentation
by Jürgen Gmach 05 Apr '21

05 Apr '21

New submission from Jürgen Gmach <juergen.gmach(a)googlemail.com>: In the documentation you can currently read for the "?"-output: "These lines can be confusing if the sequences contain tab characters." >From first hand experience :-), I can assure it is also very confusing for other types of whitespace characters, such as spaces and line breaks. I'd like to add the other characters to the documentation. ---------- assignee: docs@python components: Documentation messages: 389961 nosy: docs@python, jugmac00 priority: normal pull_requests: 23879 severity: normal status: open title: difflib: mention other "problematic" characters in documentation versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43689> _______________________________________

4 7

[issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong)
by Raymond Hettinger 05 Apr '21

05 Apr '21

Change by Raymond Hettinger <raymond.hettinger(a)gmail.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue20503> _______________________________________

1 0

[issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong)
by Raymond Hettinger 05 Apr '21

05 Apr '21

Raymond Hettinger <raymond.hettinger(a)gmail.com> added the comment: New changeset 028d5286d4255195ba6715e1aeb4bffed6b0279e by Miss Islington (bot) in branch '3.9': bpo-20503: Show how isinstance() works with ABC registered classes. (GH-25175) (GH-25202) https://github.com/python/cpython/commit/028d5286d4255195ba6715e1aeb4bffed6… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue20503> _______________________________________

1 0

[issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong)
by miss-islington 05 Apr '21

05 Apr '21

Change by miss-islington <mariatta.wijaya+miss-islington(a)gmail.com>: ---------- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +23941 pull_request: https://github.com/python/cpython/pull/25202 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue20503> _______________________________________

1 0