[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 naming conventions, they are
very common across the documentation, but searching on '*args' or '**kwargs'
doesn't actually find anything useful - it certainly doesn't place
'https://docs.python.org/3/tutorial/controlflow.html#arbitrary-argument-lists'
at or close to the top of the list.
It is my view that the documentation should be beginner friendly, but in this
case (and many other I guess) you have to know what to search for to find
something useful.
I note that even common phrases in Computing (such as 'variable arguments' or
'variable parameters') don't find anything useful. The term 'variadic' does
find the relevant page, but the link displayed in the search results lands on
the page (but not the relevant section) - and many beginners wont search for
'variadic'.
The index and search need to be improved to help beginners - specifically in
this case
* Search Index should include common conventional names (such as args, kwargs)
* Search Index should include common computing terms ('variable arguments' for
example - even if the documentation doesn't actually use that terminology).
* Search should link to the relevant section (and not just the page).
--
assignee: docs@python
components: Documentation
messages: 389442
nosy: anthony-flury, docs@python
priority: normal
severity: normal
status: open
title: Search is not beginner friendly
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43614>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 which is why it can be surprising. I would be happy to do the grunt work to make the changes if some can suggest where. Do we - add a warning to the https://docs.python.org/3/tutorial/introduction.html#numbers page, or should we link to a new page that details and explains the behavior. Which is more 'pythonic' in terms of documentation ? -- messages: 390264 nosy: anthony-flury priority: normal severity: normal status: open title: Documentation of modulo operator should document behaviour clearly when second operator is negative ___ Python tracker <https://bugs.python.org/issue43737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of people using Python. Most Python users don't consider that int/float etc would be in the standard library either - for most users the built-ins are not the same. Can I suggest: 1) The identity that is mentioned on https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations should be made more clear - at the moment it is buried in a paragraph and easily missed. 2) The document https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex should also mention the identity and the need to preserve it. 3) A link fromhttps://docs.python.org/3/tutorial/introduction.html#numbers to the document https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex - the introductory tutorial should link to further detail where neccessary. -- ___ Python tracker <https://bugs.python.org/issue43737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- ___ Python tracker <https://bugs.python.org/issue43325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue43737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 off from any other useful information - When I was researching this issue I didn't even think to look in the reference section. Looking in the library section for information about the built-in types is also non-obvious to beginners. If the tutorial doesn't contain the detail, and doesn't link to the detail then beginners are left entirely puzzled by the behavior. Given how difficult it is to search the documentation if you don't know exactly what you are looking for, then how beginners would know to look at the FAQ is beyond me. Having communicated with a number of beginners on a number of issues they had no idea that the FAQ even existed. The change didn't 'bury the tutorial in detail' - it added once sentence which linked to the FAQ. In fact all the change did was expand the FAQ entry by a few lines and link to the FAQ from the three places that are relevant. I think this is a small change and it should be the start of making the tutorial beginner friendly. -- resolution: not a bug -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue43737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue39374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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#comparing-sequences-and-other-types; 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 <https://bugs.python.org/issue43325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 available is via the help command in the python console. or by reading the source code - neither of which are the first point of call for documentation. -- assignee: docs@python components: Documentation messages: 292596 nosy: anthony-flury, docs@python priority: normal severity: normal status: open title: No Documentation on tkinter dnd module type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32770] collections.counter examples are misleading
New submission from Anthony Flury :
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 words in a list
>>> cnt = Counter()
>>> for word in ['red', 'blue', 'red', 'green', 'blue', 'blue']:
... cnt[word] += 1
>>> cnt
Counter({'blue': 3, 'red': 2, 'green': 1})
clearly this could simply be :
>>> # Tally occurrences of words in a list
>>> cnt = Counter(['red', 'blue', 'red', 'green', 'blue', 'blue'])
>>> cnt
Counter({'blue': 3, 'red': 2, 'green': 1})
(i.e. the iteration through the array is unneeded in this example).
The 2nd example is better in showing the 'entry-level' use of the Counter class.
There possibly does need to be a simple example of when you might manually
increment the Counter class - but I don't think that the examples given
illustrate that in a useful way; and I personally haven't come across a
use-case for manually incrementing the Counter class entires that couldn't be
accomplished with a comprehension or generator expression passed directly to
the Counter constructor.
--
assignee: docs@python
components: Documentation
messages: 311630
nosy: anthony-flury, docs@python
priority: normal
severity: normal
status: open
title: collections.counter examples are misleading
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue32770>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32770] collections.counter examples are misleading
Anthony Flury 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 class - you could
implement exactly the same with a defaultdict(int) - the only difference would
be that output will read defaultdict(,{'blue': 3, 'red': 2,
'green': 1}).
I think the examples in the documentation should at least demonstrate something
important on the class being documented - and the first example doesn't.
I am very tempted to re-open - but I wont - no benefit in bouncing the status
as we discuss this.
--
___
Python tracker
<https://bugs.python.org/issue32770>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32770] collections.counter examples are misleading
Anthony Flury 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 iteration and the repr are ordered in different orders. -- ___ Python tracker <https://bugs.python.org/issue32770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
New submission from Anthony Flury :
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.
from unittest.mock import mock_open
read_data = 'line 1\nline 2\nline 3\nline 4\n'
with patch('builtins.open', mock_open) as mocked:
with open('a.txt', 'r') as fp:
assert [l for l in StringIO(read_data)] ==
[l for l in fp]
will fail although it will work on a normal file with the same data, and using
[l for l in fp.readlines()] will also work.
There is a relatively simple fix which I have a working local version - but I
don't know how to provide that back to the library - or even if i should.
--
components: Library (Lib)
messages: 312706
nosy: anthony-flury
priority: normal
severity: normal
status: open
title: mock_open does not support iteration around text files.
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue32933>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
Change by Anthony Flury : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
Change by Anthony Flury : -- keywords: +patch pull_requests: +5740 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
Change by Anthony Flury : -- pull_requests: +5741 ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
Change by Anthony Flury : -- pull_requests: +5742 ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
Change by Anthony Flury : -- pull_requests: +5743 ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28955] Not matched behavior of numeric comparison with the documentation
Change by Anthony Flury : -- keywords: +patch pull_requests: +5748 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue28955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33006] docstring of filter function is incorrect
Change by Anthony Flury : -- keywords: +patch pull_requests: +5782 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32933] mock_open does not support iteration around text files.
Anthony Flury 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 possible.
When a mock_open is created, you can provide an argument 'read_data' which is
meant to be the data from your mocked file, so it is key that the dunder iter
method actually returns an iterator. The mock_open implementation already
provides special versions of read, readline and readlines methods which use the
'read_data' initial value as the content.
Currently though the dunder iter method isn't set at all - so the returned
value would currently be an empty iterator (which makes mock_open unable to be
used to test idiomatic python :
def display(file_name):
with open('a.txt', 'r') as fp:
for line in fp:
print(line)
As a trivial example the above code when mock_open is used will be equivalent
of opening an empty file, but this code :
def display(file_name):
with open('a.txt', 'r') as fp:
while True:
line = readline(fp)
if line == '':
break
print(line)
Will work correctly with the data provided to mock_open.
Regardless of how and when #33236 is solved - a fix would still be needed for
mock_open to make it provide an iterator for the mocked file.
--
___
Python tracker
<https://bugs.python.org/issue32933>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33006] docstring of filter function is incorrect
Anthony Flury 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.' Implies that items are removed from the iterable are removed, but they aren't; they are simply not included in the sequence that is returned. Does the documentation need to be fixed too ? -- nosy: +anthony-flury ___ Python tracker <https://bugs.python.org/issue33006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31766] Python 3.5 missing from documentation
New submission from Anthony Flury : 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 repository, and still a supported release in other parts of python.org, so to see it disappearing from the drop-down was surprising. To note - if you pick a particular page - say : https://docs.python.org/3/tutorial/index.html and change the url to : https://docs.python.org/3.5/tutorial/index.html The pull down now does contain 3.5 (along side 2.7, 3.63 & 3.7) -- assignee: docs@python components: Documentation messages: 304181 nosy: anthony-flury, docs@python priority: normal severity: normal status: open title: Python 3.5 missing from documentation type: behavior versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue31766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31766] Python 3.5 missing from documentation
Anthony Flury 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 or 3.7 are available from the standard ubuntu repository); the docs.python.org site is the normal place people are directed to for help - and the implication of the removal will be for many people is that Python 3.5 is obsolete which isn't the case at all. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue31766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ? I am by no means an expert though. -- nosy: +anthony-flury ___ Python tracker <https://bugs.python.org/issue21258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 testing of what would be considered pythonic code. -- ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. The test case provides a read_data content to mock_open 3. The test case expects a response from the function which implies that the file provided is empty/invalid in all cases - regardless of the data provided. I simply cannot see that someone would implement a test case such as this - if your file has data, you would expect that your function under test would recognize that the data exists, if that data is valid; and most code will differentiate between invalid data and empty data. So the only time I think this fix would change the behavior of existing code is if someone has written an illogical test case, which is currently passing and would now fail (since the test function will no2 see the data being provided and respond as such). Specifically the only change in behavior to existing code is to highlight an invalid test case and potentially a bug in the code under test. It is for this reason I support backporting. -- ___ Python tracker <https://bugs.python.org/issue32933> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 dunder_name to a known string when the source dunder_name is missing It seems obvious to me that option 3 is correct - just a question of what funcopy dunder_name should be set to. I would imagine there is code that uses funcopy dunder_name in some way ? -- nosy: +anthony-flury ___ Python tracker <https://bugs.python.org/issue32153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.org/issue32153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 do work, in the interpreter within Linux (and Mac OS I think), where the O/S supports processes being forked. In fact it is only in Windows, where a brand new process needs to be started and the source is effectively re-imported is there an issue running the examples in the interpreter. Should the documentation make this clearer ? -- assignee: docs@python components: Documentation messages: 327046 nosy: anthony-flury, docs@python priority: normal severity: normal status: open title: Multi-processing example inaccurate warning versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 "license" for more information. >>> from multiprocessing import Pool >>> def f(x): ... return x**2 ... >>> with Pool(10) as p: ... print(p.map(f, range(1,10))) [1, 4, 9, 16, 25, 36, 49, 64, 81] So something about having Pool as a context manager means it works - very odd then. BTW - with the exception of the example saying 'don't do this it doesn't work', none of the examples on the page are shown on the command line interpreter; but the first example uses a Pool context manager - which works as above. -- ___ Python tracker <https://bugs.python.org/issue34891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 False Not sure which is `correct`, but I can see the Python3.5 result causing some issues with automatic code documenters. I have code which will break under Python3.5 with this - my code performs static analysis of code, detecting functions, classes, attributes, and also traversing the mro to find inherited methods etc. Amongst other things this code identifies methods on classes, without instantiating those classes. This may simply require a documentation change to explain the difference on Py3.5 - rather than a code change. -- components: Library (Lib) messages: 273955 nosy: anthony-flury priority: normal severity: normal status: open title: inspect.ismethod returns different results on the same basic code between Python2.7 Python3.5 versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 that the documentation could be a lot clearer. It does read as if it is written for someone who already knows what the library does, rather than as a guide for someone trying to work through it for the first time. I have changed this to a documentation issue - I hope that this is ok. -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python resolution: not a bug -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue27901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of Python. The inspect library is a bit different I conceed, as the user is starting to poke under the belly of the beast as it were, but i do think it would be useful to link from Inspect to the data model docs, were the terminology is discussed in more detail. If I had tried to port my existing code to Python3.5, and it would have failed it's test set at this point - I don't think that the inspect library docs as they are would have helped. I know inspect is deliving into the internals - but for most people a block of code within a def block within a class definition is a method - that is what everyone refers to them - even though internally they aren't bound, and aren't 'methods' strictly speaking - I think the docs should try to bridge the gap between common (non expert) language and the correct language terminology where neccessary -- ___ Python tracker <http://bugs.python.org/issue27901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
