[issue44257] typo and verbous grammar in the grammar spec
Change by wim glenn : -- nosy: +wim.glenn nosy_count: 2.0 -> 3.0 pull_requests: +27651 pull_request: https://github.com/python/cpython/pull/29393 ___ Python tracker <https://bugs.python.org/issue44257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45356] Calling `help` executes @classmethod @property decorated methods
wim glenn added the comment: added Graham Dumpleton to nosy list in case he has some useful insight here, I think the PR from issue19072 may have been adapted from grahamd's patch originally? -- nosy: +grahamd ___ Python tracker <https://bugs.python.org/issue45356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40379] multiprocessing's default start method of fork()-without-exec() is broken
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue40379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45356] Calling `help` executes @classmethod @property decorated methods
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue45356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27153] Default value shown by argparse.ArgumentDefaultsHelpFormatter is backwards for action='store_false'
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue27153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes provides inaccurate documentation of defaults, so they should be overrideable
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue28742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29249] Pathlib glob ** bug
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue29249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28874] test_logging fails and freezes
wim glenn added the comment: I was seeing this problem when building 3.6.4. Fixed it by replacing the test cert with a newer one from 3.6.13: curl https://raw.githubusercontent.com/python/cpython/v3.6.13/Lib/test/keycert.pem > ./Lib/test/keycert.pem Hope this helps someone else one day.. -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue28874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42948] bytearray.copy is undocumented
wim glenn added the comment: Oh, I've missed that part. Although the note (5) seems to indicate that the copy method refers to sequence types which don't support slicing, it still seems adequately documented under the mutable sequence operations. I'll close this. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42948] bytearray.copy is undocumented
New submission from wim glenn : bytearray type has a copy method which seems to be undocumented https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations -- assignee: docs@python components: Documentation messages: 385164 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: bytearray.copy is undocumented type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37449] Move ensurepip off of pkgutil and to importlib.resources
Change by wim glenn : -- nosy: +wim.glenn nosy_count: 4.0 -> 5.0 pull_requests: +21636 pull_request: https://github.com/python/cpython/pull/22659 ___ Python tracker <https://bugs.python.org/issue37449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41793] Inaccuracy about reflected operands in datamodel docs.
Change by wim glenn : -- keywords: +patch pull_requests: +21312 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22257 ___ Python tracker <https://bugs.python.org/issue41793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41793] Inaccuracy about reflected operands in datamodel docs.
New submission from wim glenn : Qualifying that the right operand's type must be a *strict* subclass for the reflected method to take precedence avoids an edge case / counter-example when the types are actually equal. >>> class A: ... def __add__(self, other): ... print(1) ... def __radd__(self, other): ... print(2) ... >>> A() + A() 1 >>> issubclass(A, A) True -- assignee: docs@python components: Documentation messages: 376944 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: Inaccuracy about reflected operands in datamodel docs. ___ Python tracker <https://bugs.python.org/issue41793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34394] Descriptors HowTo doesn't mention __set_name__
wim glenn added the comment: Hi Raymond, any update on this? -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue34394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17005] Add a topological sort algorithm
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue17005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39269] Descriptor how-to guide wanting update for 3.6+ features
New submission from wim glenn : https://docs.python.org/3/howto/descriptor.html Current descriptor how-to guide, above, has no mention about API features added since Python 3.6 (see __set_name__ in PEP 487) It's an important and useful piece of using descriptors effectively and the guide could be updated to include some info about that. There's some info in datamodel.html (e.g. 3.3.3.6. Creating the class object) but a mention in the how-to guide would be welcome too. -- assignee: docs@python components: Documentation messages: 359642 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: Descriptor how-to guide wanting update for 3.6+ features versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
Change by wim glenn : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36761] Extended slice assignment + iterable unpacking
Change by wim glenn : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27413] Add an option to json.tool to bypass non-ASCII characters.
Change by wim glenn : -- pull_requests: +16953 pull_request: https://github.com/python/cpython/pull/17472 ___ Python tracker <https://bugs.python.org/issue27413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31542] pth files in site-packages of venvs are executed twice
Change by wim glenn : -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue31542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38557] PyTuple_GetSlice docs minor inaccuracy
New submission from wim glenn : https://docs.python.org/3/c-api/tuple.html#c.PyTuple_GetSlice In the c-api it says (emphasis mine): PyObject* PyTuple_GetSlice(PyObject *p, Py_ssize_t low, Py_ssize_t high)¶ Return value: New reference. Take a slice of the tuple pointed to by p from low to high and return it **as a new tuple**. But when slicing the entire tuple, CPython will return already existing instance, not a new tuple. https://github.com/python/cpython/blob/3.8/Objects/tupleobject.c#L448-L451 I propose the language in the docs be loosened so as not to tie the hands of implementation -- assignee: docs@python components: Documentation messages: 355141 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: PyTuple_GetSlice docs minor inaccuracy type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37684] list.extend docs inaccurate
wim glenn added the comment: Raymond, I understand that consecutive appends could potentially trigger multiple resizes behind the scenes, and so it's not really showing that extend is more like a bulk update as you mentioned. That's a good point! However I think it's a more important consideration to make sure the equivalent actually gives a correct *result*. Can you suggest an alternative code snippet to use which is correct, or perhaps soften the language claiming that the code is equivalent? For what it's worth, the stdtypes.html docs writes that extend is "for the most part the same as" the slice assignment: https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types -- ___ Python tracker <https://bugs.python.org/issue37684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37684] list.extend docs inaccurate
Change by wim glenn : -- keywords: +patch pull_requests: +14720 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14951 ___ Python tracker <https://bugs.python.org/issue37684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37684] list.extend docs inaccurate
New submission from wim glenn : >From https://docs.python.org/3/tutorial/datastructures.html#more-on-lists : list.extend(iterable) Extend the list by appending all the items from the iterable. Equivalent to a[len(a):] = iterable. The "equivalent" is not very good. Consider def gen(): yield 1 yield 2 raise Exception Using `a.extend(gen())` would mutate `a`. Using slice assignment would still consume the generator, but `a` would not be modified. I propose a different example to use to describe the behaviour of extend: for x in iterable: a.append(x) -- assignee: docs@python components: Documentation messages: 348450 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: list.extend docs inaccurate versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37684> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30052] URL Quoting page links to function Bytes instead of defintion
wim glenn added the comment: This anchor works, by the way: https://docs.python.org/3/library/functions.html#func-bytes Hopefully someone more fluent in the docs syntax can figure out a way to fix the anchor-link hovers -- ___ Python tracker <https://bugs.python.org/issue30052> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30052] URL Quoting page links to function Bytes instead of defintion
wim glenn added the comment: https://docs.python.org/3/library/functions.html Usually the little paragraph icon appears when you hover over a function name, giving an anchor link. It's not doing it for bytes or bytearray. Was that an unintended consequence of disambiguation from the stdtypes html? -- nosy: +wim.glenn ___ Python tracker <https://bugs.python.org/issue30052> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36909] LastUpdatedOrderedDict recipe uses super() unnecessarily
New submission from wim glenn : Section https://docs.python.org/3/library/collections.html#ordereddict-examples-and-recipes class LastUpdatedOrderedDict(OrderedDict): 'Store items in the order the keys were last added' def __setitem__(self, key, value): super().__setitem__(key, value) super().move_to_end(key) Why does it use super().move_to_end(key), isn't self.move_to_end(key) more direct/Pythonic? -- assignee: docs@python components: Documentation messages: 342395 nosy: docs@python, rhettinger, wim.glenn priority: normal pull_requests: 13209 severity: normal status: open title: LastUpdatedOrderedDict recipe uses super() unnecessarily ___ Python tracker <https://bugs.python.org/issue36909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36761] Extended slice assignment + iterable unpacking
wim glenn added the comment: Serhiy, `a, *L[::2] = "abc"` as an alternative is interesting, thanks. The other example `L[:], *rest = 'abcdef'` is less interesting because L[:] can be arbitrary size. When noticing this, I had tried to consume a generator into every other position in a list by using: L[::2], *extra = g Though there are obvious workarounds (e.g. using `itertools.islice`), it surprised me that CPython did not "do what I mean" out of the box. However, since creating the issue, it was brought to my attention that trying to handle this assignment may result in potential ambiguity, for example: L = [0, 1, 2] L[::2], *rest = "ab", "c", "d" There is no obvious choice for result here. So, perhaps this issue should just be closed. -- ___ Python tracker <https://bugs.python.org/issue36761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36761] Extended slice assignment + iterable unpacking
New submission from wim glenn : Could cases like these be made to work? *Should* cases like these be made to work? L = [0, 1, 2] L[::2], *rest = "abcdef" # ValueError: attempt to assign sequence of size 1 to extended slice of size 2 a, L[::2] = "abc" # ValueError: too many values to unpack (expected 2) The list slice knows exactly how many slots need to be filled, so I can't immediately think of any obvious ambiguity. Maybe there are some implementation complications with supporting e.g. generators on the RHS (because RHS must be evaluated before LHS - https://docs.python.org/3/reference/expressions.html#evaluation-order). -- components: Interpreter Core messages: 341160 nosy: wim.glenn priority: normal severity: normal status: open title: Extended slice assignment + iterable unpacking type: enhancement ___ Python tracker <https://bugs.python.org/issue36761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Change by wim glenn : -- keywords: +patch pull_requests: +9152 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue29636> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
Change by wim glenn : -- pull_requests: +8545 stage: commit review -> patch review ___ Python tracker <https://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11874] argparse assertion failure with brackets in metavars
Changes by wim glenn <wim.gl...@gmail.com>: -- versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue11874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29475] option to not follow symlinks when globbing
wim glenn added the comment: +1, would like to use this feature too, and I would like it also in pathlib.PosixPath.glob -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26253] tarfile in stream mode always set zlib compression level to 9
wim glenn added the comment: This issue also got me. compresslevel kwarg works fine for tarfile.open(..., mode='w:gz') but raises exception for tarfile.open(..., mode='w|gz') I want to use stream compression, and compresslevel=1 is more than enough for my use case, the default of 9 is way too slow. -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30583] docs mention datetuil presumably it should be dateutil
Changes by wim glenn <wim.gl...@gmail.com>: -- pull_requests: +2040 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30583] docs mention datetuil presumably it should be dateutil
Changes by wim glenn <wim.gl...@gmail.com>: -- type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30583] docs mention datetuil presumably it should be dateutil
Changes by wim glenn <wim.gl...@gmail.com>: -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30583] docs mention datetuil presumably it should be dateutil
Changes by wim glenn <wim.gl...@gmail.com>: -- pull_requests: +2038 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30583] docs mention datetuil presumably it should be dateutil
New submission from wim glenn: Typo from https://github.com/python/cpython/commit/94c8a3f91fbba72845706853d28bd5af8fc11875#diff-5a85d656ffad06e86bee33767ae24f33R1852 went unnoticed and is present in official docs https://docs.python.org/3.6/library/datetime.html#tzinfo-objects https://docs.python.org/3.7/library/datetime.html#tzinfo-objects -- messages: 295279 nosy: wim.glenn priority: normal severity: normal status: open title: docs mention datetuil presumably it should be dateutil versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11874] argparse assertion failure with brackets in metavars
wim glenn added the comment: May I ask, how to assign reviewers for CPython pull requests? https://github.com/python/cpython/pull/1826 has been sitting there for 10 days and the only comment was from a bot. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11874] argparse assertion failure with brackets in metavars
Changes by wim glenn <wim.gl...@gmail.com>: -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11874] argparse assertion failure with brackets in metavars
Changes by wim glenn <wim.gl...@gmail.com>: -- pull_requests: +1912 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29290] argparse breaks long lines on NO-BREAK SPACE
wim glenn added the comment: The test "test_help_non_breaking_spaces" from Zhang's commit fails on my platform (other 1563 tests in the module all pass). Interestingly, if running the entire test suite, it doesn't fail. It's only when executing the test_argparse.py module directly that causes the failure. I guess there is some mutable state, or the test doesn't entirely setup correctly. -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29290> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28848] Add CopyingMock to mock.py
wim glenn added the comment: Guess there was no interest in this. I've released it on pypi instead (pip install copyingmock). https://github.com/wimglenn/copyingmock -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
wim glenn added the comment: 1 month later.. is newpatch.diff OK to merge or any further improvements needed? thanks -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28848] Add CopyingMock to mock.py
wim glenn added the comment: Here's a first attempt at a patch. If it doesn't go into Lib finally, I'll just put up a CopyingMock on pypi instead. But it seemed like the kind of feature which should just be in mock directly rather than 3rd party, preferably. -- keywords: +patch Added file: http://bugs.python.org/file45715/copying_mock.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28848] Add CopyingMock to mock.py
New submission from wim glenn: Would people be interested to consider adding the CopyingMock example shown in the documentation section "coping with mutable arguments" into the mock module? https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments It seems like a useful and simple enough feature to add. -- components: Library (Lib) messages: 282136 nosy: wim.glenn priority: normal severity: normal status: open title: Add CopyingMock to mock.py versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
wim glenn added the comment: Perhaps it's better to call a spade a spade here - if they're implemented as comparisons, then why not document them as comparisons? A colleague has mentioned one point that sets `in` and `not in` apart from the other comparisons in the table: comparisons are generally made between objects of the same type (with the exception of numbers). But membership "comparisons" are made between different types (with the exception of substring checks). Here is an alternate patch which leaves the table alone, but corrects the inaccuracy in the note. -- Added file: http://bugs.python.org/file45360/newpatch.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
wim glenn added the comment: I want to add that the grammar explicitly mentions them as comparisons https://docs.python.org/3/reference/grammar.html And they are also listed in the comparisons section of the expressions documentation https://docs.python.org/3/reference/expressions.html#comparisons So the docs seem to be contradicting themselves here. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
wim glenn added the comment: Well, that wouldn't be true either. Because you can easily implement objects which support membership tests but don't support iteration. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
New submission from wim glenn:
Regarding
https://docs.python.org/3/library/stdtypes.html#comparisons
There is a line at the bottom claiming:
> Two more operations with the same syntactic priority, in and not in, are
> supported only by sequence types (below).
The claim is incorrect because `in` and `not in` are also supported by
non-sequence types such as sets, mappings, etc for membership testing.
Is there any good reason why we don't include them in the table of comparison
operations, and say that there are ten comparison operations in python? They
do support comparison chaining in the same way:
>>> 'x' in 'xy' in 'xyz'
True
>>> 0 in {0} in [{0}]
True
--
assignee: docs@python
components: Documentation
files: patch.diff
keywords: patch
messages: 280080
nosy: docs@python, wim.glenn
priority: normal
severity: normal
status: open
title: Why isn't "in" called a comparison operation?
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45359/patch.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28617>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28045] minor inaccuracy in range_contains_long
New submission from wim glenn: The [commented] code summarising this algorithm is incorrect because % has precedence over - Hey, no big deal it's just a comment after all, but may as well fix it up. -- assignee: docs@python components: Documentation, Interpreter Core files: mywork.patch keywords: patch messages: 275353 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: minor inaccuracy in range_contains_long type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file44505/mywork.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27244] print(';;') fails in pdb with SyntaxError
wim glenn added the comment: Seems to be as documented here: https://docs.python.org/2/library/pdb.html#debugger-commands "No intelligence is applied to separating the commands; the input is split at the first ;; pair, even if it is in the middle of a quoted string." -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26351] Occasionally check for Ctrl-C in long-running operations like sum
Changes by wim glenn <wim.gl...@gmail.com>: -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26478] dict views don't implement subtraction correctly
wim glenn added the comment: Well that was patched quickly, impressive turnaround on this -- nosy: +wim.glenn ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25574] 2.7 incorrectly documents objects hash as equal to id
New submission from wim glenn: The 2.7 glossary still incorrectly mentions instances of user-defined classes hash equal to their id. https://docs.python.org/2/glossary.html#term-hashable Just a minor documentation bug that was unfortunately missed by http://bugs.python.org/issue21782 -- assignee: docs@python components: Documentation files: mywork.patch keywords: patch messages: 254237 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: 2.7 incorrectly documents objects hash as equal to id versions: Python 2.7 Added file: http://bugs.python.org/file40966/mywork.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23986] Inaccuracy about in keyword for list and tuple
New submission from wim glenn:
The comparisons section of the python 2 docs says:
---
https://docs.python.org/2/reference/expressions.html#comparisons
For the list and tuple types, x in y is true if and only if there exists an
index i such that x == y[i] is true.
---
But it's not strictly speaking correct. Simplest counter-example:
x = float('nan')
y = [x]
The python 3 docs instead mention correct equivalent which is
any(x is e or x == e for e in y)
--
assignee: docs@python
components: Documentation
messages: 241317
nosy: docs@python, wim.glenn
priority: normal
severity: normal
status: open
title: Inaccuracy about in keyword for list and tuple
type: enhancement
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23986
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21642] _ if 1else _ does not compile
Changes by wim glenn wim.gl...@gmail.com: -- nosy: +wim.glenn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21642 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Wim added the comment: Ping -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Wim added the comment: Yes, the problem occurs regardless of whether the default_namespace parameter is the correct SVG namespace URI --- it's the fact of requesting a default namespace at all that exposes the bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Wim added the comment: Here's an improved patch (and improved testcase). It's a little more intrusive than the last patch because when a default namespace is being used, two distinct qname caches must be made. -- Added file: http://bugs.python.org/file33125/bug17088_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Wim added the comment: FWIW: I noticed that my patch has a bug due to sharing the cache dict between element names and attribute names, although I think this is unlikely to crop up very often in practice. I'll submit a better patch if/when I get the time to put one together. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Wim added the comment: I have run into this a few times although it is only recently that I've convinced myself I understood the XML namespace spec well enough to know what the right behavior was. (I came to the same interpretation as silverbacknet.) I have attached a patch which I believe fixes (and tests) the problem. -- keywords: +patch nosy: +wiml Added file: http://bugs.python.org/file32981/bug17088_1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17088 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1551113] random.choice(setinstance) fails
wim glenn added the comment: The implementation suggested by the OP def choice(self, seq): Choose a random element from a non-empty sequence. idx = int(self.random() * len(seq)) try: result = seq[idx] # raises IndexError if seq is empty except TypeError: result = list(seq)[idx] return result Is broken because input may be a dict with, for example, keys 0 1 and 7 - potentially causing the line result = seq[idx] to pass when logically it should raise. Rather it would be needed to determine from the input whether it was a non-sequence type collection, which sounds pretty hairy... -- nosy: +wim.glenn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1551113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1551113] random.choice(setinstance) fails
wim glenn added the comment: How about if isinstance(seq, collections.Sequence): # do it the usual way .. else: return choice(list(seq)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1551113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17255] test_any and test_all should validate short-circuiting behaviour
New submission from wim glenn: The docs http://docs.python.org/2/library/functions.html#all provide some equivalent code for all builtin (and similarly for any): def all(iterable): for element in iterable: if not element: return False return True The behaviour is clearly documented as short-circuiting, but the cases contained in test_builtin.py are lacking any test coverage for the short-circuiting behaviour. You could implement any/all in a broken way that still passes the current tests (consuming more of a generator than you want to for example), so it is important to guarantee the short-circuiting. My patch adds two simple test cases to make this behaviour explicit. -- components: Tests files: mywork.patch keywords: patch messages: 182496 nosy: wim.glenn priority: normal severity: normal status: open title: test_any and test_all should validate short-circuiting behaviour type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file29131/mywork.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16697] argparse kwarg 'choices' documentation
Changes by wim glenn wim.gl...@gmail.com: -- nosy: -wim.glenn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16468] argparse only supports iterable choices
Changes by wim glenn wim.gl...@gmail.com: -- nosy: -wim.glenn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16697] argparse kwarg 'choices' documentation
New submission from wim glenn: Any object that supports the in operator can be passed as the choices value, so dict objects, set objects, custom containers, etc. are all supported. (from http://docs.python.org/dev/library/argparse.html#choices ) Actual behaviour is contradicted by the docs - it seems the container must additionally be iterable. When using a custom container, argparse b0rks on trying to iterate through choices. Using a metavar prevents this, but it still breaks on cases where the element is not in the container. More details here: http://stackoverflow.com/questions/13833566/python-argparse-choices-from-an-infinite-set -- assignee: docs@python components: Documentation messages: 177599 nosy: docs@python, wim.glenn priority: normal severity: normal status: open title: argparse kwarg 'choices' documentation type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16697 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs
New submission from Wim:
Encoding a (well-formed) Unicode string containing a non-BMP character, using
the xmlcharrefreplace error handler, will produce two XML entities for
surrogate codepoints instead of one entity for the actual character.
Here's a transcript (Python 2.7.3, x86_64):
b = '\xf0\x9f\x92\x9d'
u = b.decode('utf8')
u
u'\U0001f49d'
u.encode('ascii', errors='xmlcharrefreplace')
'#55357;#56477;'
( u'\U0001f49d' ).encode('ascii', errors='xmlcharrefreplace')
'#55357;#56477;'
list(u)
[u'\ud83d', u'\udc9d']
u.encode('utf8', errors='xmlcharrefreplace')
'\xf0\x9f\x92\x9d'
The utf8 bytestring is correctly decoded, and the print representation shows
one single Unicode character. Encoding using xmlcharrefreplace produces two XML
entities, which is wrong[1]: a single non-BMP character should be represented
in XML as a single entity reference, in this case presumably '#128157;'.
As the last two lines show, I'm using a narrow build (so the unicode strings
are represented internally in UTF-16, I guess). Converting the string back to
utf8 does the right thing, and emits a single UTF8 sequence representing the
supplementary-plane codepoint.
(FWIW, the backslashreplace error handler also emits a surrogate pair, but I
don't know if there is a complete specification for what that handler does, so
it's possible that it's not wrong.)
[1] http://www.w3.org/International/questions/qa-escapes#bytheway
--
components: Library (Lib), Unicode
messages: 169886
nosy: ezio.melotti, wiml
priority: normal
severity: normal
status: open
title: encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15866
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9256] plistlib should create non-naïve datetime objects
New submission from Wim w...@.org:
The plistlib module parses date elements in the plist into datetime objects.
(This is good.) However, it produces naïve datetimes, even though the date
elements include an explicit timezone specification ('Z' for UTC, since they're
in ISO 8601 format).
Now that issue 5094 has been fixed, this should be a pretty trivial thing to
fix— just pass tzinfo=UTC when creating the datetime (since the regex it uses
won't even accept a date that doesn't have the 'Z' suffix, this will be
correct).
As an aside: RFC 3339 section 4.3 suggests a convention for distinguishing
between timestamps in UTC and timestamps which happen to be defined in terms
of UTC, but don't really live in any particular timezone. The python datetime
module is not currently able to make this distinction AFAIK, but even though
the plist date strings don't follow the RFC 3339 convention, they are most
accurately described as having an unknown local offset (like POSIX timestamps,
they are UTC-referenced but cannot carry local-timezone info).
--
files: plistdt.py
messages: 110249
nosy: wiml
priority: normal
severity: normal
status: open
title: plistlib should create non-naïve datetime objects
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17993/plistdt.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9256
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Wim w...@.org added the comment: I just ran across yet another implementation of sendmsg support for python sockets, whose feature set seems to complement Kalman Gergely's implementation: http://www.pps.jussieu.fr/~ylg/PyXAPI by Yves Legrandgerard (Out of curiosity, people have been submitting requests for, and patches with implementations of, this feature for five or more years now and they're never accepted. Is there some opposition to sendmsg support in Python? It's a missing feature that bites me pretty regularly.) -- nosy: +wiml ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
