[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Anthony Flury added the comment: I fundamentally disagree with closing this - I know that this and many other 'quirks' catch beginners out, and the tutorial is what they use to learn.They don't look in the reference document - it is too dense in BNF definitions which turns a lot of people

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Change by Anthony Flury : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <https://bugs.python.org/issu

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Change by Anthony Flury : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue43737> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Change by Anthony Flury : -- pull_requests: +24015 pull_request: https://github.com/python/cpython/pull/25279 ___ Python tracker <https://bugs.python.org/issue43

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Change by Anthony Flury : -- keywords: +patch pull_requests: +23957 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25220 ___ Python tracker <https://bugs.python.org/issu

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Anthony Flury added the comment: I am working on a pull request for this. -- ___ Python tracker <https://bugs.python.org/issue43737> ___ ___ Python-bugs-list m

[issue43325] Documentation should warn that 'is' is not a safe comparison operator for most values.

Anthony Flury added the comment: Should the data structures page also link to the FAQ. The problem with the FAQ is that most beginners don't even know that == vs 'is' is actually a question they need to ask, and therefore they aren't likely to look at the FAQ in the first place

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

Anthony Flury added the comment: I take your point about warnings etc - but when you come from other languages the Python behavior can initially be very surprising. The reference section has always seemed to be a very technical document, certainly not targeted at the usual audience

[issue43737] Documentation of modulo operator should document behaviour clearly when second operator is negative

New submission from Anthony Flury : The behavior of a%b when a is positive and b is negative can be suprising. I understand that the behavior is so that the identity a = (a//b)*b + a%b can be preserved regardless of the signs of a or b. but the result is different from other languages

[issue43614] Search is not beginner friendly

Anthony Flury added the comment: Is PR 25045 the correct Pull request - this Issue is a documentation change - the linked PR is related to Issue 43433 (a change to xmlrpc.client ?) -- ___ Python tracker <https://bugs.python.org/issue43

[issue43614] Search is not beginner friendly

New submission from Anthony Flury : A commonly asked question on Quora is 'What do *args and **kwargs' mean ? While it is relatively easy for community to answer these questions the search tool on the standard documentation doesn't make it easy. I understand that 'args' and 'kwargs' are both

[issue43325] Documentation should warn that 'is' is not a safe comparison operator for most values.

New submission from Anthony Flury : 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

[issue39374] Key in sort -> Callable Object instead of function

Anthony Flury added the comment: I will submit a documentation only fix for this in the next day or so. -- nosy: +anthony-flury ___ Python tracker <https://bugs.python.org/issue39

[issue34891] Multi-processing example inaccurate warning

Anthony Flury added the comment: An example that does work : $ python3 Python 3.6.6 (default, Sep 12 2018, 18:26:19) [GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux Type "help", "copyright", "credits" or

[issue34891] Multi-processing example inaccurate warning

New submission from Anthony Flury : On the Multi-processing page <https://docs.python.org/3/library/multiprocessing.html> (just above the reference section) there is a warning that the examples wont work from the interpreter. This is not entirely accurate in that the examples d

[issue32153] mock.create_autospec fails if an attribute is a partial function

Anthony Flury added the comment: Am not a big fan of special casing, I think the functools.update_wrapper is the way to go - will have a look later and produce a pull request with some test cases. -- ___ Python tracker <https://bugs.python.

[issue32153] mock.create_autospec fails if an attribute is a partial function

Anthony Flury added the comment: It seems to me that we have three alternatives : 1. Refuse to create the mock object with a suitable Exception (rather than a crash 2. Copy the object and simply ignore the missing dunder_name (so that funcopy dunder_name is not set 3. Set funcopy

[issue32933] mock_open does not support iteration around text files.

Anthony Flury added the comment: Thank you. -- ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32933] mock_open does not support iteration around text files.

Anthony Flury added the comment: I still support backporting to 3.6 and 3.7 : Yes it is correct that this fix could change the behavior of existing test code, but only if someone has written a test case for a function where : 1. The function under test uses dunder_iter iteration 2

[issue32933] mock_open does not support iteration around text files.

Anthony Flury added the comment: Berker, Thanks for your work on getting this complete. I would strongly support backporting if possible. 3.5 and 3.6 will be in common use for a while (afaik 3.6 has only now got delivered to Ubuntu as the default Python 3), and this does fix does allow full

[issue21258] Add __iter__ support for mock_open

Anthony Flury added the comment: The lack of dunder_iter support on mock_open has been resolved in Issue 32933 (Git Hub 5974). Can I suggest that once the above PR is merged into 3.8 (due imminently allegedly ), that we should then backport that fix into 3.5, 3.6 & 3.7 as a minimum ?

[issue32933] mock_open does not support iteration around text files.

Anthony Flury added the comment: But the __next__ is a method on the iterator; So long as __iter__ returns a valid iterator (which it does in my pull request), it will by definition support __next___ Although it is entirely possible that I have misunderstood what you are saying

[issue33006] docstring of filter function is incorrect

Anthony Flury <anthony.fl...@btinternet.com> added the comment: Strictly speaking the official Python2 reference document isn't a great example - for instance: ' If function is None, the identity function is assumed, that is, all elements of iterable that are false are removed.' I

[issue32933] mock_open does not support iteration around text files.

Anthony Flury <anthony.fl...@btinternet.com> added the comment: No - it isn't related. In the case of mock_open; it isn't intended to be a simple MagicMock - it is meant to be a mocked version of open, and so to be useful as a testing tool, it should emulate a file as much as po

[issue33006] docstring of filter function is incorrect

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- keywords: +patch pull_requests: +5782 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue28955] Not matched behavior of numeric comparison with the documentation

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- keywords: +patch pull_requests: +5748 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32933] mock_open does not support iteration around text files.

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- pull_requests: +5743 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32933] mock_open does not support iteration around text files.

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- pull_requests: +5742 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32933] mock_open does not support iteration around text files.

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- pull_requests: +5741 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32933] mock_open does not support iteration around text files.

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- keywords: +patch pull_requests: +5740 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32933] mock_open does not support iteration around text files.

Change by Anthony Flury <anthony.fl...@btinternet.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32933] mock_open does not support iteration around text files.

New submission from Anthony Flury <anthony.fl...@btinternet.com>: Using the unittest.mock helper mock_open with multi-line read data, although readlines method will work on the mocked open data, the commonly used iterator idiom on an open file returns the equivalent of an empty file.

[issue32770] collections.counter examples are misleading

Anthony Flury <anthony.fl...@btinternet.com> added the comment: Cheryl : When you iterate around a counter instance it does return keys in the order they are first encountered/inserted - so I agree with you that it is an ordered collection from Python 3.7 onwards (although the ite

[issue32770] collections.counter examples are misleading

Anthony Flury <anthony.fl...@btinternet.com> added the comment: Raymond, I completely understand your comment but I do disagree. My view would be that the documentation of the stdlib should document the entry level use cases. The first example given uses nothing special from the Counter

[issue32770] collections.counter examples are misleading

New submission from Anthony Flury <anthony.fl...@btinternet.com>: The first example given for collections.Counter is misleading - the documentation ideally should show the 'best' (one and only one) way to do something and the example is this : >>> # Tally occurrences of

[issue31766] Python 3.5 missing from documentation

Anthony Flury <anthony.fl...@btinternet.com> added the comment: Isn't Python 2.7 in Security Fix only as well ? It seems strange; Python 3.5 probably the most heavily installed Python 3 release (every Ubuntu installation has Python 3.5 installed by default - and neither Python 3.6

[issue31766] Python 3.5 missing from documentation

New submission from Anthony Flury <anthony.fl...@btinternet.com>: In the Python version pull down list on docs.python.org, Python3.5 used to be listed, but has now been removed; the list only contains 2.7, 3.6 & 3.7. Python 3.5 is still the official Python 3.5 release in the Ubuntu

[issue30210] No Documentation on tkinter dnd module

New submission from Anthony Flury: There is a level of drag and drop support within the tkinter package - namely the tkinter.dnd module. However there is no documentation at this time about drag and drop either on docs.python.org or on the tkinter reference manual. The only documentation

[issue27901] inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5

Anthony Flury added the comment: Assuming the reader knows the details of how Python works is not a great assumption when those documents are being used (by the most part) by people like me who are reasonable developers but who don't know, and for most cases don't care about the internals

[issue27901] inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5

Anthony Flury added the comment: Not sure I agree with closing this. I am not convinced (as a reasonably seasoned developer) that the documentation is clear. It may not be a bug in the code, resulting as it does from a change in the way methods are implemented in Python 3.5, but I do think

[issue27901] inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5

New submission from Anthony Flury: Consider the following code in Python2.7 & Python3.5 import inspect class a(object): def m(self): pass in Python 2.7 inspect.ismethod(a.m) returns True in Python 3.5 inspect.ismethod(a.m) returns F