Re: [Python-Dev] collections.abc for data and non-data descriptors
A random thought: typing has ABCs for protocols, even more than collections.abc has (e.g. typing.SupportsInt). Some support for descriptors has been added to mypy recently. Maybe it makes sense to add support for descriptor protocol in typing? -- Ivan On 18 January 2017 at 05:44, Raymond Hettinger wrote: > > > On Jan 17, 2017, at 11:41 AM, Roberto Martínez < > robertomartin...@gmail.com> wrote: > > > > Oh, I understand. Maybe is not worth the effort anyway. > > FWIW, I'm also in the camp of thinking it is not worth the effort. Until > there is a demonstrated need (something than can't be met by checking for > __set__), the default position should be to stick with a core usable set of > ABCs that are know to have real value. Each new ABC has a non-trivial > maintenance burden and requires extra effort on the part of users to learn > and remember. > > > Raymond > ___ > 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/ > levkivskyi%40gmail.com > ___ 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] Can we use "designated initializer" widely in core modules?
On Wed, 18 Jan 2017 08:44:29 +0100 Victor Stinner wrote: > > My patch adds Py_TPFLAGS_HAVE_FINALIZE and Py_TPFLAGS_HAVE_FASTCALL to > Py_TPFLAGS_DEFAULT. So all modules compiled with Python 3.7 will > announce that they have tp_finalize and tp_fastcall fields, even if > they are NULL. I don't know why this change wasn't done before for > tp_finalize. I don't think I thought about that idea at the time. tp_finalize doesn't benefit many extension types, so it's not a huge burden to add a FLAGS value for the few cases where you want to use it. Regards Antoine. ___ 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] Can we use "designated initializer" widely in core modules?
> On 18 Jan 2017, at 02:16, Victor Stinner wrote: > > 2017-01-18 1:59 GMT+01:00 INADA Naoki : >> I think mixing two forms is OK only if new form is used only at bottom. >> (like keyword arguments are allowed after all positional arguments in >> Python function calling) >> >> Complete rewriting makes diff huge. And there is PyVarObject_HEAD_INIT >> already. > > I'm in favor of replacing all long list of fields with the /* tp_xxx > */ comments to use designated initializers. It would allow to remove a > lot of "0, /* tp_xxx */" lines and make the code much more > readable! It should help to prevent bugs when the code is modified. I agree. I’ve done this in my own projects and that made the code a lot easier to read. Ronald ___ 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] Can we use "designated initializer" widely in core modules?
2017-01-18 12:33 GMT+01:00 Antoine Pitrou : > I don't think I thought about that idea at the time. tp_finalize > doesn't benefit many extension types, so it's not a huge burden to add > a FLAGS value for the few cases where you want to use it. It isn't obvious to me that I have to define explicitly a Py_TPFLAGS_HAVE_FINALIZE flag if I want to _inherit_ the finalizer from the base class. The flag requires an #ifdef to only define it on Python >= 3.4, which can be painful when you have to support older Python versions and want a single code base for all Python versions. If a C extension defines a type which inherit from a type which has a finalizer, currently the finalizer is not inherited if the new type doesn't set explicitly the Py_TPFLAGS_HAVE_FINALIZE flag. I checked the _socket.socket type. Hopefully, sock_dealloc() calls PyObject_CallFinalizerFromDealloc(), so I guess that it should "just work" if tp_finalize is not inherited in the tp_finalize slot. But for tp_fastcall, if a type doesn't have the Py_TPFLAGS_HAVE_FASTCALL flag, the fastcall_wrapper() has to find the first base class with a tp_fastcall slot which. The search has a complexity of O(n), so it has an impact on performance (even if the impact is low). The flag only says that the C structure contains the field, not that it's set. So I think that it's safe to add Py_TPFLAGS_HAVE_FINALIZE and Py_TPFLAGS_HAVE_FASTCALL to Py_TPFLAGS_DEFAULT. 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] collections.abc for data and non-data descriptors
I'd rather wait until support for protocols has been added to PEP 484. On Wed, Jan 18, 2017 at 2:25 AM, Ivan Levkivskyi wrote: > A random thought: typing has ABCs for protocols, even more than > collections.abc has (e.g. typing.SupportsInt). Some support for descriptors > has been added to mypy recently. > Maybe it makes sense to add support for descriptor protocol in typing? > > -- > Ivan > > > On 18 January 2017 at 05:44, Raymond Hettinger < > raymond.hettin...@gmail.com> wrote: > >> >> > On Jan 17, 2017, at 11:41 AM, Roberto Martínez < >> robertomartin...@gmail.com> wrote: >> > >> > Oh, I understand. Maybe is not worth the effort anyway. >> >> FWIW, I'm also in the camp of thinking it is not worth the effort. Until >> there is a demonstrated need (something than can't be met by checking for >> __set__), the default position should be to stick with a core usable set of >> ABCs that are know to have real value. Each new ABC has a non-trivial >> maintenance burden and requires extra effort on the part of users to learn >> and remember. >> >> >> Raymond >> ___ >> 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/levkivsky >> i%40gmail.com >> > > > ___ > 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/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ 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] collections.abc for data and non-data descriptors
On 18 January 2017 at 16:35, Guido van Rossum wrote: > I'd rather wait until support for protocols has been added to PEP 484. > Sorry for offtopic but do you think this should be an addition to PEP 484 or a separate PEP? I am interested in writing the specification (based on what Jukka proposed on typing tracker) and implementing it in mypy. -- Ivan ___ 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] collections.abc for data and non-data descriptors
It's probably big enough to make it a new PEP. On Wed, Jan 18, 2017 at 7:45 AM, Ivan Levkivskyi wrote: > On 18 January 2017 at 16:35, Guido van Rossum wrote: > >> I'd rather wait until support for protocols has been added to PEP 484. >> > > Sorry for offtopic but do you think this should be an addition to PEP 484 > or a separate PEP? > I am interested in writing the specification (based on what Jukka proposed > on typing tracker) > and implementing it in mypy. > > -- > Ivan > > > -- --Guido van Rossum (python.org/~guido) ___ 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] Can we use "designated initializer" widely in coremodules?
On Tue, 17 Jan 2017 at 18:36 Nathaniel Smith wrote: > On Tue, Jan 17, 2017 at 4:48 PM, INADA Naoki > wrote: > > On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings > wrote: > >> > >> On 01/17/2017 12:02 PM, Steve Dower wrote: > >> > >> Avoiding header files would be my only request. As Brett says, the C99 > >> requirement should not be enforced on all embedders or extenders, so we > >> should try and keep the headers they'll use as compatible as possible. > >> > >> > > > > C99 style comment is used in header file already. > > see http://bugs.python.org/issue29215 > > > >> > >> While that's a reasonable policy, unless we have a way to automatically > >> detect that I suspect C99 stuff will creep into the header files and > break > >> the non-C99 customers. Maybe we could get some sort of buildbot that > >> exercises this scenario? > >> > > > > How about `gcc -ansi` ? > > I think the main concern isn't C90 compatibility, but C++ > compatibility, right? Correct. This is not about supporting old versions of C but making sure we continue to support C++ extensions. > The reason CPython is switching to allowing > (most of) C99 internally is that it seems like that it's now supported > as a matter of course on all the platforms we care about, so while > it's theoretically possible that someone uses C99 compiler to build > Python but then switches to a C90 compiler to build extensions, it > seems pretty unlikely. (Especially since the last hold-out on C99 > support was MSVC, and on Windows we already force people to build > extensions using the same version of MSVC as was used to build > CPython.) > > OTOH it is definitely important that the Python header files remain > polyglot C99-and-C++ compatible. > > Even a simple check like: > > echo '#include ' > test.cc && g++ -c test.cc -o /dev/null > > would probably catch most issues here. > I've gone ahead and added that to the Travis test matrix for when we move to GitHub: https://github.com/brettcannon/cpython-ci-test/blob/master/.travis.yml#L55 ___ 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
