Mailman 3 March 2013 - docs

[issue16575] ctypes: unions as arguments
by Eli Bendersky March 4, 2013

March 4, 2013

Eli Bendersky added the comment: A minimal fix would be to update the documentation. A more comprehensive fix would be to tweak ctypes to reject unions and bit-fields when running on non-x86 (does this work for ARM and other non-Intel archs?) An even more comprehensive fix would be to make this work, but that would require forking libffi and should presumably be first implemented upstream. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, eli.bendersky stage: -> needs patch versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16575> _______________________________________

1 0

[issue16851] Hint about correct ismethod and isfunction usage
by Thomas Kluyver March 4, 2013

March 4, 2013

Thomas Kluyver added the comment: I agree that the docs for inspect.ismethod() for Python 2 are wrong. The docs say: "Return true if the object is a bound method written in Python." However, it also returns True for an unbound method: >>> class A: ... def meth(self): ... pass ... >>> A.meth <unbound method A.meth> >>> import inspect >>> inspect.ismethod(A.meth) True ---------- nosy: +takluyver _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16851> _______________________________________

1 0

Multiprocessing module example problem
by Bo Bayles March 3, 2013

March 3, 2013

I noticed that the "A test of `multiprocessing.Pool` class" at (http://docs.python.org/3/library/multiprocessing.html#examples) doesn't seem to work as expected. I'm using Python 3.3 on Windows. I saved the example and ran it. It gives the correct output until the "Testing callback" section. The map_async function doesn't seem to be written properly. I was confused about why the program I was writing didn't work until I realized the example might be wrong. If I can figure out a workaround I will write back, but otherwise I hope the example can be fixed by someone smarter than me. Thanks, -Bo Testing callback: *** callbacks failed [56] != [56, 0, 1, 8, 27, 64, 125, 216, 343, 512, 729]

1 0

Re: [docs] Doc: remove errors about mixed-type comparisons. (issue 12067)
by mhoy09＠gmail.com March 3, 2013

March 3, 2013

http://bugs.python.org/review/12067/

1 0

Re: [docs] Doc: remove errors about mixed-type comparisons. (issue 12067)
by mhoy09＠gmail.com March 3, 2013

March 3, 2013

On 2013/02/23 07:51:56, ezio.melotti wrote: > http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst > File Doc/reference/expressions.rst (right): > > http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst… > Doc/reference/expressions.rst:1048: specific :meth:`__eq__()` and > :meth:`__ne__()`. With ``<``, ``>``, > These should be :meth:`~object.__eq__` (or whatever creates a link to the __eq__ > documention). The () shouldn't be included. It appears that this section of the documentation is vary different from what I worked on 4 months ago. Can we please get some input as to whether or not this issue needs to remain open? http://bugs.python.org/review/12067/

1 0

Re: [docs] Doc: remove errors about mixed-type comparisons. (issue 12067)
by mhoy09＠gmail.com March 2, 2013

March 2, 2013

http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst File Doc/reference/expressions.rst (right): http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst… Doc/reference/expressions.rst:1048: specific :meth:`__eq__()` and :meth:`__ne__()`. With ``<``, ``>``, On 2013/02/23 07:51:56, ezio.melotti wrote: > These should be :meth:`~object.__eq__` (or whatever creates a link to the __eq__ > documention). The () shouldn't be included. Currently working on this. http://bugs.python.org/review/12067/

1 0

[issue17309] __bytes__ doesn't work in subclass of int and str
by Benjamin Peterson March 2, 2013

March 2, 2013

Benjamin Peterson added the comment: This has been fixed recently: $ ./python bytes.py b'\x00' b'hello' ---------- nosy: +benjamin.peterson resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17309> _______________________________________

1 0

[issue17309] __bytes__ doesn't work in subclass of int and str
by Terry J. Reedy March 1, 2013

March 1, 2013

Terry J. Reedy added the comment: More data: class myit(list): def __bytes__(self): return b'hello' print (bytes(b'a')) class myit(list): def __bytes__(self): return b'hello' print (bytearray (myit([1,2,3]))) # bytearray(b'a') # bytearray(b'\x01\x02\x03') class by: def __bytes__(self): return b'hello' # TypeError: 'by' object is not iterable (Error message is incomplete.) So bytearray *always* treats objects as specified in its library entry and never calls __bytes__, making its value sometimes unequal as a sequence of bytes from bytes with the same input. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17309> _______________________________________

1 0

[issue17309] __bytes__ doesn't work in subclass of int and str
by Terry J. Reedy March 1, 2013

March 1, 2013

Terry J. Reedy added the comment: The library doc says that if the source argument for bytes() or bytearray() is a string or integer it is treated a certain way. I believe 'string' and 'integer' are meant to include subclasses of str and int, else it should have said str or int. You have verified that int subclass instances are indeed treated as integers. The following shows that str subclass instances are treated as strings. class mystr(str): def __bytes__(self): return b'hello' print(bytes(mystr('a'))) raises TypeError: string argument without an encoding The language reference says "object.__bytes__(self): Called by bytes() to compute a byte-string representation of an object." No exception is given. I see this as a contradiction in the manual, in which case the current behavior rules and the contradiction is removed by changing the doc part that conflicts with behavior. That would mean extending the doc sentence with 'that is not a string or integer'. However, I am waiting for other opinions for two reasons. 1. The doc also specified special treatment for buffer interface and iterable objects. However, __bytes__ *is* checked first for those objects. class myit(list): def __bytes__(self): return b'hello' print (bytes (myit([1,2,3]))) # b'hello' class mybit(bytes): # example def __bytes__(self): return b'hello' print (bytes (mybit(b'a'))) # b'hello' So the exception is limited to 'strings' and 'integers', making it somewhat inconsistent. 2. If someone gives an str or int subclass a __bytes__ method, they can only mean for it to be called by bytes(), as there is no other use of that special method. On the third hand, a user of a class who tests its instances before calling bytes with "isinstance(x, (str, int))" instead of "type(x) is str or type(x) is int", likely expects getting normal string or integer behavior. Of course, the same might be true if the test is 'isiterable(x)'. If behavior were changed, I think it should wait for 3.4 since the current behavior is not clearly a bug to me. ---------- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python, terry.reedy title: __bytes__ doesn't work in subclass of int -> __bytes__ doesn't work in subclass of int and str versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17309> _______________________________________

1 0