Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
Hi, 2016-12-10 7:43 GMT+01:00 Serhiy Storchaka : > It is documented for Py_BuildValue(), and the documentation of > PyObject_CallFunction() refers to Py_BuildValue(). You're right, but even if I read the documentation of Py_BuildValue() every week, I never noticed that PyObject_CallFunction() behaves differently if the result of Py_BuildValue() is a tuple or not. It is not explicit in the PyObject_CallFunction() documentation. Anyway, as I wrote, it would be a bad idea to change the behaviour, it would break too much C code in the wild, so I just proposed a patch to enhance the documentation: http://bugs.python.org/issue28977 > I just found that in spite of your changes of parameter names, the > documentation still have old names: > > PyObject* PyObject_CallMethod(PyObject *o, const char *method, const > char *format, ...) Ah? It's possible that I forgot to update the documentation of some functions. But sorry, I don't see where. Can you point me which file is outdated please? Since I finished to "cleanup abstract.h" (issue #28838), I will now work on updating the documentation (doc in .rst files and comments in .h files) of functions of the PyObject_Call() family. At least, make sure that .rst and .h almost contain the same doc ;-) Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
On 15.12.16 10:45, Victor Stinner wrote: > Ah? It's possible that I forgot to update the documentation of some > functions. But sorry, I don't see where. Can you point me which file > is outdated please? https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod Seems online documentation is not updated. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
2016-12-15 10:46 GMT+01:00 Serhiy Storchaka : > https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod > > Seems online documentation is not updated. "Last updated on Dec 08, 2016." Oh, right. No idea what/who compiles the documentation. I expected at least one build per day? Someone also proposed to have a mirror of the CPython documentation on readthedocs. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyObject_CallFunction(func, "O", arg) special case
2016-12-15 10:54 GMT+01:00 Victor Stinner : > Oh, right. No idea what/who compiles the documentation. I expected at > least one build per day? I am told that it can be related to https://github.com/python/docsbuild-scripts/pull/7 Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Cleanup of abstract.h header
Hi, I made multiple changes to the Include/abstract.h header file, because it was inconsistent in different manners: * Parameter names of functions of the PyObject_Call family were inconsistent: "func" versus "callable" for a Python callable object for example (sometimes, .c and .h files were inconsistent too) * Only this header file used an indentation of 4 spaces in the whole space * Only this header used comments *after* the function declaration and with a newline between the comment and the declaration. Other headers use a comment *before* the declaration and no newline. * Some comments were far (100 lines) from function declaration, so it wasn't possible anymore to understand these comments. * Other tiny changes Before: https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h Now: https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h (Not sure that it's easy to compare such long header file, ~1 200 lines, in a web browser.) See http://bugs.python.org/issue28838 for more information. Serhiy Storchaka was opposed to these changes, some extract of his comments: * "Isn't this just a lot of churn for not a lot of benefit?" - Eric V. Smith asked the same question * "It breaks "hg annotation" and makes harder researching the history of the file" I already pushed all my changes anyway, but Serhiy asked me to discuss these changes on Python-Dev, so here I am. I decided to cleanup abstract.h because I had to modify it multiple times last 2 years, especially when I added new functions for fast calls, and I was always surprised and confused by the style of header. I didn't know how to format my code, and it seems like I also introduced some inconsistent coding style in the newly added code. For the first change that I made recently, normalizing parameter names, I first pushed directly a change without review, but Serhiy asked me on this list to revert it. So I reverted the change and continued the discussion on the issue #28838. We agreed on better names, and so I pushed a different change. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.6.0rc2 coming soon, 3.6.0 final now 2016-12-23
Hi all! Today (2016-12-16) has long been our planned release date for 3.6.0 final. So far most of the feedback from users testing the preview versions of 3.6.0 has been very positive. We made it to the next-to-final milestone, the 3.6.0rc1 release candidate, 10 days ago with hopes of going directly to the final release. Alas, in the last few days at least one outstanding issue that we had hoped would not be a real-world problem has proven to be a showstopper during third-party package testing and I have been persuaded that we do need to fix it before 3.6.0 final. I take responsibility and apologize for not ensuring it was resolved earlier in the release cycle; I'll try to do better next time. Therefore, we are going to produce a second release candidate. Besides the showstopper fix (#28147), I've cherrypicked a few requested build fixes and, as promised, some last-minute documentation updates and additions. I'm also expecting to cherrypick at least one more asynchio fix before tagging and manufacturing 3.6.0rc2 sometime later today (i.e. within the next 24 hours). Assuming that is accomplished, we will be looking for quick feedback to ensure that we have addressed the problems and have not introduced any new ones. Then, assuming all goes well and no new showstoppers are found, we plan to release 3.6.0 final on Friday 2016-12-23, a week from now. Also note that there is no change in the status of the cpython repo branches. Continue to push appropriate changes to the 3.6 branch for the 3.6.1 maintenance release and to the default branch for the next feature release, 3.7.0. Should you run into a potential showstopper problem for 3.6.0, please make sure there is an open issue for it on the bug tracker marked as "release blocker", work to getting a fix pushed to the 3.6 branch for 3.6.1, and contact me ASAP to discuss potential cherrypicking. Please do the same for any necessary important documentation fixes for 3.6.0 final. As before, my goal will be to have no new changes after the release candidate. Thank you all again for your great efforts and co-operation throughout the 3.6 development cycle! We are oh-so-close to getting your work officially out there. --Ned P.S. Happy Beethoven's Birthday FYI: Here is a list of the post 3.6.0rc1 changesets that have been cherrypicked so far for 3.6.0rc2. There will likely be at least one more. (Note, the description and files list below for some changesets may be truncated.) user:Yury Selivanov date:Wed Dec 07 16:19:56 2016 -0800 files: Doc/whatsnew/3.6.rst description: Issue #28635: Drop the note that whatsnew is incomplete user:Ned Deily date:Wed Dec 07 23:37:12 2016 -0500 files: Doc/tools/templates/indexsidebar.html description: Issue #28900: Update documentation sidebar for 3.6.0rc. user:Benjamin Peterson date:Wed Dec 07 23:54:28 2016 -0800 files: Include/pyport.h description: guard HAVE_LONG_LONG definition to prevent redefinition (#28898) [prevent gdb build errors with 3.6.0] user:Steve Dower date:Wed Dec 07 13:02:27 2016 -0800 files: Doc/library/importlib.rst Doc/using/windows.rst Doc/whatsnew/3.6.rst Misc/NEW description: Issue #28896: Deprecate WindowsRegistryFinder user:Steve Dower date:Sun Dec 11 14:48:32 2016 -0800 files: Tools/msi/distutils.command.__init__.py Tools/msi/distutils.command.bdist_win description: Issue #28783: Replaces bdist_wininst in nuget packages with stub user:Yury Selivanov date:Mon Dec 12 16:44:58 2016 -0500 files: Doc/library/asyncio-protocol.rst Doc/whatsnew/3.6.rst description: Issue #28089: Document TCP_NODELAY in asyncio user:Victor Stinner date:Thu Dec 15 16:20:53 2016 +0100 files: Doc/whatsnew/3.6.rst description: Issue #28979: Fix What's New in Python 3.6, dict user:Victor Stinner date:Thu Dec 15 17:21:23 2016 +0100 files: Lib/test/test_dict.py Misc/NEWS Modules/_testcapimodule.c Objects/dictobject. description: Issue #28147: Fix a memory leak in split-table dictionaries: setattr() must not convert combined table into split table. Patch written by INADA Naoki. user:Yury Selivanov date:Thu Dec 15 17:36:05 2016 -0500 files: Doc/glossary.rst Doc/library/asyncio-eventloop.rst Doc/library/inspect.rst [...] description: Issue #28091: Document PEP 525 & PEP 530. user:Yury Selivanov date:Thu Dec 15 17:56:43 2016 -0500 files: Doc/whatsnew/3.6.rst description: Issue #28635: asyncio-related fixes and additions. [docs only] user:Yury Selivanov date:Thu Dec 15 18:58:19 2016 -0500 files: Doc/library/asyncio.rst description: docs: asyncio is no longer provisional user:Ned Deily date:Thu Dec 15 23:20:48 2016 -0500 files: Misc/NEWS description: Issue #28898: add Misc/NEWS entry -- Ned Deily n...@pyt
Re: [Python-Dev] Cleanup of abstract.h header
I think it looks better. Thank you. On Thu, Dec 15, 2016, at 02:22, Victor Stinner wrote: > Hi, > > I made multiple changes to the Include/abstract.h header file, because > it was inconsistent in different manners: > > * Parameter names of functions of the PyObject_Call family were > inconsistent: "func" versus "callable" for a Python callable object > for example (sometimes, .c and .h files were inconsistent too) > > * Only this header file used an indentation of 4 spaces in the whole > space > > * Only this header used comments *after* the function declaration and > with a newline between the comment and the declaration. Other headers > use a comment *before* the declaration and no newline. > > * Some comments were far (100 lines) from function declaration, so it > wasn't possible anymore to understand these comments. > > * Other tiny changes > > Before: > https://hg.python.org/cpython/file/f692dafe6797/Include/abstract.h > > Now: > https://hg.python.org/cpython/file/c4bcca326c0a/Include/abstract.h > > (Not sure that it's easy to compare such long header file, ~1 200 > lines, in a web browser.) > > See http://bugs.python.org/issue28838 for more information. > > > Serhiy Storchaka was opposed to these changes, some extract of his > comments: > > * "Isn't this just a lot of churn for not a lot of benefit?" - Eric V. > Smith asked the same question > * "It breaks "hg annotation" and makes harder researching the history > of the file" > > I already pushed all my changes anyway, but Serhiy asked me to discuss > these changes on Python-Dev, so here I am. > > > I decided to cleanup abstract.h because I had to modify it multiple > times last 2 years, especially when I added new functions for fast > calls, and I was always surprised and confused by the style of header. > I didn't know how to format my code, and it seems like I also > introduced some inconsistent coding style in the newly added code. > > For the first change that I made recently, normalizing parameter > names, I first pushed directly a change without review, but Serhiy > asked me on this list to revert it. So I reverted the change and > continued the discussion on the issue #28838. We agreed on better > names, and so I pushed a different change. > > Victor > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
