Mailman 3 March 2013 - docs

Re: [docs] [Python-Dev] undocumented argtypes magic in ctypes?
by Eli Bendersky March 7, 2013

March 7, 2013

On Thu, Mar 7, 2013 at 3:37 AM, Thomas Heller <theller(a)ctypes.org> wrote: > Am 06.03.2013 18:19, schrieb Eli Bendersky: > >> >> >> >> On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov <andrew.svetlov(a)gmail.com >> <mailto:andrew.svetlov@gmail.**com <andrew.svetlov(a)gmail.com>>> wrote: >> >> Looks like bug for me. >> >> >> ctypes seems to auto-convert arguments when argtypes is specified. This >> fact is documented. However, I'm not sure whether this auto-conversion >> is advanced enough to apply byref. Because otherwise, DIRENT is >> certainly not convertible to DIRENT_p >> > > If argtypes specify a 'POINTER(X)' type as an argument, then ctypes > automatically applies byref() if an 'X' instance is passed to the > actual call. This is by design, but I'm not sure if it is documented > or not. > > However, if argtypes is not given, this does (and of course cannot) work. > Great, thanks for confirming this, Thomas. I had the feeling it's a documentation issue (hence I sent it to the docs@ list first), because the behavior seems very deliberate and looking at the code of ctypes I did see conversions going on. Have I missed that this is documented somewhere, or should I open a docs issue? Eli

1 0

Python 3.3 Docs Bug
by Hc Z March 7, 2013

March 7, 2013

Hello, I found a bug in Python, see details in http://bugs.python.org/issue17371. Also I believe this a bug for Python 3.3 documents. Good luck, guys. Haochen Zhao

1 0

[issue17364] Multiprocessing documentation mentions function that doesn't exist
by Topher Brown March 6, 2013

March 6, 2013

New submission from Topher Brown: multiprocessing documentation (http://docs.python.org/2/library/multiprocessing.html#pipes-and-queues) for multiprocessing.Queue mentions Queue.get_no_wait() as an alias for Queue.get_nowait(). This function does not seem to exist. ---------- assignee: docs@python components: Documentation messages: 183566 nosy: Topher.Brown, docs@python priority: normal severity: normal status: open title: Multiprocessing documentation mentions function that doesn't exist versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17364> _______________________________________

4 3

[issue17363] Argument Mixup in PyState_AddModule
by Tobias Becker March 6, 2013

March 6, 2013

New submission from Tobias Becker: http://docs.python.org/3.3/c-api/module.html?highlight=pymodule#PyState_Add… the arguments of PyState_AddModule are in wrong order: currently: int PyState_AddModule(PyModuleDef *def, PyObject *module) correct: int PyState_AddModule(PyObject *module,PyModuleDef *def) ---------- assignee: docs@python components: Documentation messages: 183564 nosy: Tobias.Becker, docs@python priority: normal severity: normal status: open title: Argument Mixup in PyState_AddModule versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17363> _______________________________________

3 2

[issue17356] Invalid link to repr() built-in function description
by Vladimir Rutsky March 5, 2013

March 5, 2013

New submission from Vladimir Rutsky: References to built-in function repr() links to repr module (http://docs.python.org/2/library/repr.html#module-repr), but must link to description in http://docs.python.org/2/library/functions.html. It can be at least in http://docs.python.org/2/library/functions.html (link in table at page top). ---------- assignee: docs@python components: Documentation messages: 183538 nosy: docs@python, vrutsky priority: normal severity: normal status: open title: Invalid link to repr() built-in function description type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17356> _______________________________________

2 1

undocumented argtypes magic in ctypes?
by Eli Bendersky March 5, 2013

March 5, 2013

Hello, While playing with ctypes a bit, I noticed a feature that doesn't appear to be documented. Suppose I import the readdir_r function (assuming DIRENT is a correctly declared ctypes.Structure): DIR_p = c_void_p DIRENT_p = POINTER(DIRENT) DIRENT_pp = POINTER(DIRENT_p) readdir_r = lib.readdir_r readdir_r.argtypes = [DIR_p, DIRENT_p, DIRENT_pp] readdir_r.restype = c_int It seems that I can then call it as follows: dirent = DIRENT() result = DIRENT_p() readdir_r(dir_fd, dirent, result) Note that while readdir_r takes DIRENT_p and DIRENT_pp as its second and third args, I pass in just DIRENT and DIRENT_p, accordingly. What I should have done is use byref() on both, but ctypes seems to have some magic applied when argtypes declares pointer types. If I use byref, it still works. However, if I keep the same call and comment out the argtypes declaration, I get a segfault. So, is it a feature that should be documented, explicitly discouraged or is it a bug? Eli

1 0

[issue16851] Hint about correct ismethod and isfunction usage
by Ezio Melotti March 4, 2013

March 4, 2013

Ezio Melotti added the comment: I checked the tests on 2.7 and found this: # contrary to spec, ismethod() is also True for unbound methods # (see #1785) self.assertIn(('f', B.f), inspect.getmembers(B, inspect.ismethod)) #1785 also has some discussion about this. ---------- nosy: +pitrou _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16851> _______________________________________

1 0

os.rename documentation slightly inaccurate (issue 16278)
by ezio.melotti＠gmail.com March 4, 2013

March 4, 2013

I left a few comments. Most of them apply to several parts of the code, even though I just commented in a single place. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py File Lib/test/test_os.py (right): http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode55 Lib/test/test_os.py:55: # Tests creating TESTFN and os.rename I think it would be better to make a separate class for os.rename. The changes to setUp/tearDown are only needed for the new tests, but they are executed for all the old tests too, and that's not necessary. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode62 Lib/test/test_os.py:62: self.rename_src_file = "%s_%d_tmp" % ("test_rename_src_file", \ All the \ are useless and should be removed (or possibly replaced by an extra set of ()). http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode85 Lib/test/test_os.py:85: if (os.path.exists(self.rename_dst_directory + "/file.txt")): Shouldn't this use os.path.join()? Also "/file.txt" is repeated over and over -- it would be better to use a variable instead. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode125 Lib/test/test_os.py:125: os.rmdir(self.rename_src_directory) This could be rewritten as: files = [support.TESTFN, self.rename_src_file, ...] for file in files: if os.path.exists(file): os.unlink(file) for the dirs you can have the same 4 lines with rmdir instead, or check if they are files or dir and use the same loop. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode161 Lib/test/test_os.py:161: @support.cpython_only Why are this cpython_only? Does the behavior depend on the CPython implementation or on the OS and/or underlying posix function? http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode164 Lib/test/test_os.py:164: (sys.platform == 'win32') ), \ All the \ should be removed, and there are also 4 sets of () that are not necessary and could be removed as well. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode165 Lib/test/test_os.py:165: 'test specific to windows or linux or darwin only') Is this because you only tested it on these platforms? I would run it on other platforms too, and possibly add specific skips if they fail there (unless of course the failure is caused by a bug that should be fixed). If the skip is really necessary I would create a new skip decorator and use that, instead of repeating this over and over. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode167 Lib/test/test_os.py:167: if ((sys.platform == 'darwin') or (sys.platform.startswith == "linux")): All the () are unnecessary and should be removed. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode171 Lib/test/test_os.py:171: [b"beans", b"bacon", b"eggs", b"spam"]) PEP8 says that this should either be indented as self.assertEqual(fobj.read().splitlines(), [b"beans", b"bacon", b"eggs", b"spam"]) or as self.assertEqual( fobj.read().splitlines(), [b"beans", b"bacon", b"eggs", b"spam"]) http://www.python.org/dev/peps/pep-0008/#indentation http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode185 Lib/test/test_os.py:185: os.unlink(self.rename_dst_file) # delete rename_dst_file Shouldn't the setUp/tearDown already take care of this? http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode369 Lib/test/test_os.py:369: self.assertRaises(OSError, os.rename, self.rename_src_file, \ self.assertRaises() can be used as a context manager too, to make the code more readable. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode396 Lib/test/test_os.py:396: self.assertEqual(os.path.exists(self.rename_dst_directory), True) self.assertTrue(os.path.exists(self.rename_dst_directory)) http://bugs.python.org/review/16278/

1 0

[issue14123] Doc change re old and new string formatting
by Christine Jones March 4, 2013

March 4, 2013

New submission from Christine Jones <silly.english.knights(a)gmail.com>: Change to this http://docs.python.org/py3k/library/stdtypes.html as suggested by Nick Coghlan here http://www.gossamer-threads.com/lists/python/dev/969817 "The formatting operations described here are modelled on C's printf() syntax. They only support formatting of certain builtin types, and the use of a binary operator means that care may be needed in order to format tuples and dictionaries correctly. As the new string formatting syntax is more powerful, flexible, extensible and handles tuples and dictionaries naturally, it is recommended for new code. However, there are no current plans to deprecate printf-style formatting." ---------- assignee: docs@python components: Documentation messages: 154283 nosy: docs@python, telephonebook priority: normal severity: normal status: open title: Doc change re old and new string formatting _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14123> _______________________________________

8 10

[issue16575] ctypes: unions as arguments
by Armin Rigo March 4, 2013

March 4, 2013

Armin Rigo added the comment: See also http://bugs.python.org/issue16576. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16575> _______________________________________

1 0