[Python-Dev] [RELEASED] Python 3.4.6 and Python 3.5.3 are now available
On behalf of the Python development community and the Python 3.4 and Python 3.5 release teams, I'm delighted to announce the availability of Python 3.4.6 and Python 3.5.3. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. Python 3.5 is still in active "bug fix" mode. Python 3.5.3 contains many incremental improvements over Python 3.5.2. There were literally no code changes between rc1 and final for either release. The only change--apart from the necessary updates from "rc1" to final--was a single copyright notice update for one of the OS X ".plist" property list files in 3.5.3 final. You can find Python 3.5.3 here: https://www.python.org/downloads/release/python-353/ And you can find Python 3.4.6 here: https://www.python.org/downloads/release/python-346/ Best wishes, //arry/ ___ 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
Oh, I found another recent bug fixed because of the "O" weird behaviour: http://bugs.python.org/issue26478 "dict views don't implement subtraction correctly" Victor 2016-12-09 18:46 GMT+01:00 Victor Stinner : > Hi, > > The PyObject_CallFunction() function has a special case when the > format string is "O", to pass exactly one Python object: > > * If the argument is a tuple, the tuple is unpacked: it behaves like > func(*arg) > * Otherwise, it behaves like func(arg) > > This case is not documented in the C API ! > https://docs.python.org/dev/c-api/object.html#c.PyObject_CallFunction > > > The following C functions have the special case: > > * PyObject_CallFunction(), _PyObject_CallFunction_SizeT() > * PyObject_CallMethod(), _PyObject_CallMethod_SizeT() > * _PyObject_CallMethodId(), _PyObject_CallMethodId_SizeT() > > > I guess that it's a side effect of the implementation: the code uses > Py_BuildValue() and then checks if the value is a tuple or not. > Py_BuildValue() is a little bit surprising: > > * "i" creates an integer object > * "ii" creates a tuple > * "(i)" and "(ii)" create a tuple. > > Getting a tuple or not depends on the length of the format string. It > is not obvious when you have nested tuples like "O(OO)". > > Because of the special case, passing a tuple as the only argument > requires to write "((...))" instead of just "(...)". > > > In the past, this special behaviour caused a bug in > generator.send(arg), probably because the author of the C code > implementing generator.send() wasn't aware of the special case. See > the issue: > http://bugs.python.org/issue21209 > > I found code using "O" format in the new _asyncio module, and I'm > quite sure that unpacking special case is not expected. So I opened an > issue: > http://bugs.python.org/issue28920 > > > Last days, I patched functions of PyObject_CallFunction() family to > use internally fast calls. I implemented the special case to keep > backward compatibility. > > I replaced a lot of code using PyObject_CallFunction() with > PyObject_CallFunctionObjArgs() when the format string was only made of > "O", PyObject* arguments. I made this change to optimize the code, but > indirectly, it avoids also the special case for code which used > exactly "O" format. See: > http://bugs.python.org/issue28915 > > When I made these changes, I found some functions which rely the > unpacking feature! > > * time_strptime() (change 49a7fdc0d40a) > * unpickle() of _ctypes (change ceb22b8f6d32) > > I don't know well what we are supposed to do. I don't think that > changing the behaviour of PyObject_CallFunction() to remove the > special case is a good idea. It would be an obvious backward > incompatible change which can break applications. > > I guess that the minimum is to document the special case? > > 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] collections.abc for data and non-data descriptors
Hi, I miss abstract base classes in collections.abc implementing the descriptor protocol. Any reason why they do not exist? What do you think of adding NonDataDescriptor and DataDescriptor ABCs? Best regards, Roberto ___ 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 Mon, 16 Jan 2017 at 22:34 INADA Naoki wrote: > Hi. > > --- > This discussion is started in http://bugs.python.org/issue29259, and > there is separated issue at http://bugs.python.org/issue29260 . > But I want to see more comments, before issue 29259 is committed. > --- > > Since Python 3.6, some of C99 features are accepted in PEP 7. > "designated initializer" is one of them. > > PEP7 says "designated initializers (especially nice for type > declarations)" > > For example, issue 29259 is adding new slot named tp_fastcall in type > structure. > Without designated initializer, there are many diffs like this: > > 0, /* tp_free */ > +0, /* tp_is_gc */ > +0, /* tp_bases */ > +0, /* tp_mro */ > +0, /* tp_cache */ > +0, /* tp_subclasses */ > +0, /* tp_weaklist */ > +0, /* tp_del */ > +0, /* tp_version_tag */ > +0, /* tp_finalize */ > +(fastternaryfunc)attrgetter_call, /* tp_fastcall */ > }; > > With designated initializer, it becomes: > > 0, /* tp_free */ > +.tp_fastcall = (fastternaryfunc)attrgetter_call, > }; > > It's readable, and easy to review. > Without designated initializer, it's difficult to find copy & paste > mistake. > (Can you find if I missed /* tp_is_gc */ line in first patch?) > > On the other hand, this syntax is C99 specific. > C++ doesn't accept this syntax, even for newest C++14. > Using this feature make it's difficult to use (subset of) C++ features > in the future. > At this point I really doubt we will ever switch to C++ so I don't think making any such theoretical transition is worth holding back cleaner code. Plus if this isn't going into a header file that some C++ extension module is going to be pulling in then third-party C++ code should be shielded from the incompatibility. > > > So, how widely can we use "designated initializer"? > Only in Modules (_asyncio uses it already)? > Or almost everywhere (Objects/ and Python/)? > I say everywhere we can (and that also means we should probably update the xx* files in Modules/). -Brett > > I want to get decision before issue 29259 is committed, because it > will add many "0, /* tp_xxx */" > > Regards, > ___ > 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/brett%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
Re: [Python-Dev] collections.abc for data and non-data descriptors
Well, these are an example of the purest duck typing. Just implement __get__ and/or __set__ (and __delete__) and you're good. What's the situation where you miss them? --Guido On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez < robertomartin...@gmail.com> wrote: > Hi, > > I miss abstract base classes in collections.abc implementing the > descriptor protocol. Any reason why they do not exist? > > What do you think of adding NonDataDescriptor and DataDescriptor ABCs? > > Best regards, > Roberto > > ___ > 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
I need to check if some objects obey the descriptor protocol in the
construction of a metaclass. I expect to be able to write something like:
if isinstance(myobj, abc.DataDescriptor):
# do something
The other idea crossing my mind is something like:
if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
# do something
El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
escribió:
> Well, these are an example of the purest duck typing. Just implement
> __get__ and/or __set__ (and __delete__) and you're good.
>
> What's the situation where you miss them?
>
> --Guido
>
> On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
> Hi,
>
> I miss abstract base classes in collections.abc implementing the
> descriptor protocol. Any reason why they do not exist?
>
> What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
>
> Best regards,
> Roberto
>
> ___
> 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
For this use case I see nothing wrong with hasattr(myobj, '__set__').
On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
> I need to check if some objects obey the descriptor protocol in the
> construction of a metaclass. I expect to be able to write something like:
>
> if isinstance(myobj, abc.DataDescriptor):
># do something
>
> The other idea crossing my mind is something like:
>
> if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
> # do something
>
>
> El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
> escribió:
>
>> Well, these are an example of the purest duck typing. Just implement
>> __get__ and/or __set__ (and __delete__) and you're good.
>>
>> What's the situation where you miss them?
>>
>> --Guido
>>
>> On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
>> robertomartin...@gmail.com> wrote:
>>
>> Hi,
>>
>> I miss abstract base classes in collections.abc implementing the
>> descriptor protocol. Any reason why they do not exist?
>>
>> What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
>>
>> Best regards,
>> Roberto
>>
>> ___
>> 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)
>>
>
--
--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
Well, for me having to check both __get__ and __str__ for a data descriptor
feels inelegant.
After read the documentation of collections.abc again "This module provides
abstract base classes that can be used to test whether a class provides a
particular interface; for example, whether it is hashable or whether it is
a mapping." I ask: what is the criteria to decide which interfaces are
worth implemented as an ABC in the standard library?
To my understanding, any well defined python protocol should have a proper
ABC.
El mar., 17 ene. 2017 a las 18:55, Guido van Rossum ()
escribió:
> For this use case I see nothing wrong with hasattr(myobj, '__set__').
>
> On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
> I need to check if some objects obey the descriptor protocol in the
> construction of a metaclass. I expect to be able to write something like:
>
> if isinstance(myobj, abc.DataDescriptor):
># do something
>
> The other idea crossing my mind is something like:
>
> if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
> # do something
>
>
> El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
> escribió:
>
> Well, these are an example of the purest duck typing. Just implement
> __get__ and/or __set__ (and __delete__) and you're good.
>
> What's the situation where you miss them?
>
> --Guido
>
> On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
> robertomartin...@gmail.com> wrote:
>
> Hi,
>
> I miss abstract base classes in collections.abc implementing the
> descriptor protocol. Any reason why they do not exist?
>
> What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
>
> Best regards,
> Roberto
>
> ___
> 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)
>
>
>
>
> --
> --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
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just checking for __set__ (if it only has __set__ but
not __get__, do you care what it is?).
On Tue, Jan 17, 2017 at 10:18 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
> Well, for me having to check both __get__ and __str__ for a data
> descriptor feels inelegant.
>
> After read the documentation of collections.abc again "This module
> provides abstract base classes that can be used to test whether a class
> provides a particular interface; for example, whether it is hashable or
> whether it is a mapping." I ask: what is the criteria to decide which
> interfaces are worth implemented as an ABC in the standard library?
>
> To my understanding, any well defined python protocol should have a proper
> ABC.
>
> El mar., 17 ene. 2017 a las 18:55, Guido van Rossum ()
> escribió:
>
>> For this use case I see nothing wrong with hasattr(myobj, '__set__').
>>
>> On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
>> robertomartin...@gmail.com> wrote:
>>
>> I need to check if some objects obey the descriptor protocol in the
>> construction of a metaclass. I expect to be able to write something like:
>>
>> if isinstance(myobj, abc.DataDescriptor):
>># do something
>>
>> The other idea crossing my mind is something like:
>>
>> if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
>> # do something
>>
>>
>> El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
>> escribió:
>>
>> Well, these are an example of the purest duck typing. Just implement
>> __get__ and/or __set__ (and __delete__) and you're good.
>>
>> What's the situation where you miss them?
>>
>> --Guido
>>
>> On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
>> robertomartin...@gmail.com> wrote:
>>
>> Hi,
>>
>> I miss abstract base classes in collections.abc implementing the
>> descriptor protocol. Any reason why they do not exist?
>>
>> What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
>>
>> Best regards,
>> Roberto
>>
>> ___
>> 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)
>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
--
--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?
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. Cheers, Steve Top-posted from my Windows Phone -Original Message- From: "Brett Cannon" Sent: 1/17/2017 8:58 To: "INADA Naoki" ; "Python-Dev" Subject: Re: [Python-Dev] Can we use "designated initializer" widely in coremodules? On Mon, 16 Jan 2017 at 22:34 INADA Naoki wrote: Hi. --- This discussion is started in http://bugs.python.org/issue29259, and there is separated issue at http://bugs.python.org/issue29260 . But I want to see more comments, before issue 29259 is committed. --- Since Python 3.6, some of C99 features are accepted in PEP 7. "designated initializer" is one of them. PEP7 says "designated initializers (especially nice for type declarations)" For example, issue 29259 is adding new slot named tp_fastcall in type structure. Without designated initializer, there are many diffs like this: 0, /* tp_free */ +0, /* tp_is_gc */ +0, /* tp_bases */ +0, /* tp_mro */ +0, /* tp_cache */ +0, /* tp_subclasses */ +0, /* tp_weaklist */ +0, /* tp_del */ +0, /* tp_version_tag */ +0, /* tp_finalize */ +(fastternaryfunc)attrgetter_call, /* tp_fastcall */ }; With designated initializer, it becomes: 0, /* tp_free */ +.tp_fastcall = (fastternaryfunc)attrgetter_call, }; It's readable, and easy to review. Without designated initializer, it's difficult to find copy & paste mistake. (Can you find if I missed /* tp_is_gc */ line in first patch?) On the other hand, this syntax is C99 specific. C++ doesn't accept this syntax, even for newest C++14. Using this feature make it's difficult to use (subset of) C++ features in the future. At this point I really doubt we will ever switch to C++ so I don't think making any such theoretical transition is worth holding back cleaner code. Plus if this isn't going into a header file that some C++ extension module is going to be pulling in then third-party C++ code should be shielded from the incompatibility. So, how widely can we use "designated initializer"? Only in Modules (_asyncio uses it already)? Or almost everywhere (Objects/ and Python/)? I say everywhere we can (and that also means we should probably update the xx* files in Modules/). -Brett I want to get decision before issue 29259 is committed, because it will add many "0, /* tp_xxx */" Regards, ___ 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/brett%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
Re: [Python-Dev] collections.abc for data and non-data descriptors
Oh, I understand. Maybe is not worth the effort anyway.
Thank you
El mar., 17 ene. 2017 a las 19:40, Guido van Rossum ()
escribió:
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just checking for __set__ (if it only has __set__ but
not __get__, do you care what it is?).
On Tue, Jan 17, 2017 at 10:18 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
Well, for me having to check both __get__ and __str__ for a data descriptor
feels inelegant.
After read the documentation of collections.abc again "This module provides
abstract base classes that can be used to test whether a class provides a
particular interface; for example, whether it is hashable or whether it is
a mapping." I ask: what is the criteria to decide which interfaces are
worth implemented as an ABC in the standard library?
To my understanding, any well defined python protocol should have a proper
ABC.
El mar., 17 ene. 2017 a las 18:55, Guido van Rossum ()
escribió:
For this use case I see nothing wrong with hasattr(myobj, '__set__').
On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
I need to check if some objects obey the descriptor protocol in the
construction of a metaclass. I expect to be able to write something like:
if isinstance(myobj, abc.DataDescriptor):
# do something
The other idea crossing my mind is something like:
if all(hasattr(myobj, attr) for attr in ('__get__', '__set__')):
# do something
El mar., 17 ene. 2017 a las 18:07, Guido van Rossum ()
escribió:
Well, these are an example of the purest duck typing. Just implement
__get__ and/or __set__ (and __delete__) and you're good.
What's the situation where you miss them?
--Guido
On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
Hi,
I miss abstract base classes in collections.abc implementing the descriptor
protocol. Any reason why they do not exist?
What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
Best regards,
Roberto
___
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)
--
--Guido van Rossum (python.org/~guido)
--
--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 core modules?
On 2017-01-17 11:55 AM, Brett Cannon wrote: So, how widely can we use "designated initializer"? Only in Modules (_asyncio uses it already)? Or almost everywhere (Objects/ and Python/)? I say everywhere we can (and that also means we should probably update the xx* files in Modules/). +1. Yury ___ 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 17 January 2017 at 20:02, 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. Agreed, we probably shouldn't require users of Python.h to be C99-compliant. (Disclaimer: I have no idea how many compilers *don't* implement this feature). Paul ___ 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 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. 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? //arry/ ___ 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 17/01/17 06:32, INADA Naoki wrote: With designated initializer, it becomes: 0, /* tp_free */ +.tp_fastcall = (fastternaryfunc)attrgetter_call, }; It's readable, and easy to review. FWIW, I dislike mixing the two forms (because it still prevents the structure layout changing - or introduces bugs if it does - though I guess in Python's case that's not likely to happen). PEP 7 doesn't mention anything about this and I doubt a wholesale conversion effort to the C99 syntax would be desirable, but perhaps a recommendation that if a new initializer is being added then the whole expression should be changed to the C99 syntax is reasonable. Regards, E. ___ 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 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` ? $ cat head.c #include $ gcc `python-config --cflags` -ansi -c head.c In file included from /home/inada-n/pyenv/versions/3.6.0/include/python3.6m/Python.h:50:0, from head.c:1: /home/inada-n/pyenv/versions/3.6.0/include/python3.6m/pyport.h:40:1: error: C++ style comments are not allowed in ISO C90 // long long is required. Ensure HAVE_LONG_LONG is defined for compatibility. ^ /home/inada-n/pyenv/versions/3.6.0/include/python3.6m/pyport.h:40:1: error: (this will be reported only once per input file) ~ > > /arry > > ___ > 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/songofacandy%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, Jan 18, 2017 at 9:00 AM, Erik wrote: > On 17/01/17 06:32, INADA Naoki wrote: >> >> With designated initializer, it becomes: >> >> 0, /* tp_free */ >> +.tp_fastcall = (fastternaryfunc)attrgetter_call, >> }; >> >> It's readable, and easy to review. > > > FWIW, I dislike mixing the two forms (because it still prevents the > structure layout changing - or introduces bugs if it does - though I guess > in Python's case that's not likely to happen). > > PEP 7 doesn't mention anything about this and I doubt a wholesale conversion > effort to the C99 syntax would be desirable, but perhaps a recommendation > that if a new initializer is being added then the whole expression should be > changed to the C99 syntax is reasonable. > > Regards, E. > 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. ___ 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 01/17/2017 04:48 PM, INADA Naoki wrote: On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote: 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` ? That seems like it should work fine. Perhaps we could even add this gcc -ansi step to the normal Python build process. It shouldn't take very long, so it wouldn't slow down the build very much, and since most Python development happens on UNIX platforms (I think) this would help prevent more C99 constructs from creeping into the header files. //arry/ ___ 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 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. 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] Can we use "designated initializer" widely in core modules?
> On Jan 17, 2017, at 5:16 PM, Victor Stinner wrote: > > /* tp_xxx */" lines and make the code much more > readable! It should help to prevent bugs when the code is modified. I'm +0 on the change (it is a massive code churn with a huge diff and won't match any existing C extensions or published books on Python) but it does have advantages in the face of all the new tp slots being proposed which would be painful regardless. I don't want to pretend that it really prevents bugs though. Historically, this just hasn't been a problem for us in practice (I've written and reviewed many, many of these structs over the years). In fact, the change may become a source of bugs as people forget to fill-in slots or lose their cues as to what slots are available (I for one use the current copy and paste as a checklist for what should and shouldn't be included). I would really like to hear Guido's opinion on the subject (IIRC he designed the current system of slots and has had to live with its pros and cons over a long period time). Also at one time, Guido opined that he was somewhat resistant to adding new slots (otherwise, we would already have a __length_hint__ slot which I proposed a few years ago). Lastly, if we do go forward with this sweeping change, we should also explore the possibility of flattening the current tp_as_sequence, tp_as_mapping, and tp_as_number indirections. These have historically have been somewhat of a pain and have led to many otherwise unnecessary indirections. Raymond P.S. I'm not sure if we care about the size of the types but they are growing at an unprecedented rate (amidst lots of other code churn as well). ___ 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?
I'm for allowing the new convention. If it had been supported 20 years ago I would've used it. I'm against changing any existing code to use it -- such massive changes are high risk and low reward. Just do it for new fields or new types. I recommend being reluctant to add new fields -- the number of type objects is larger than you'd think and these are static bytes which I consider a relatively expensive resource. There's also an ABI issue with new fields -- new fields can only be accessed after checking that the type object has been compiled with a version of the headers that defines the field, else you'd be accessing garbage bytes. On Tue, Jan 17, 2017 at 5:52 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > > On Jan 17, 2017, at 5:16 PM, Victor Stinner > wrote: > > > > /* tp_xxx */" lines and make the code much more > > readable! It should help to prevent bugs when the code is modified. > > I'm +0 on the change (it is a massive code churn with a huge diff and > won't match any existing C extensions or published books on Python) but it > does have advantages in the face of all the new tp slots being proposed > which would be painful regardless. > > I don't want to pretend that it really prevents bugs though. > Historically, this just hasn't been a problem for us in practice (I've > written and reviewed many, many of these structs over the years). In fact, > the change may become a source of bugs as people forget to fill-in slots or > lose their cues as to what slots are available (I for one use the current > copy and paste as a checklist for what should and shouldn't be included). > > I would really like to hear Guido's opinion on the subject (IIRC he > designed the current system of slots and has had to live with its pros and > cons over a long period time). Also at one time, Guido opined that he was > somewhat resistant to adding new slots (otherwise, we would already have a > __length_hint__ slot which I proposed a few years ago). > > Lastly, if we do go forward with this sweeping change, we should also > explore the possibility of flattening the current tp_as_sequence, > tp_as_mapping, and tp_as_number indirections. These have historically have > been somewhat of a pain and have led to many otherwise unnecessary > indirections. > > > > Raymond > > > P.S. I'm not sure if we care about the size of the types but they are > growing at an unprecedented rate (amidst lots of other code churn as well). > > > > > ___ > 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] Can we use "designated initializer" widely in coremodules?
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? 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. -n -- Nathaniel J. Smith -- https://vorpus.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
Re: [Python-Dev] Can we use "designated initializer" widely incoremodules?
As well as pre-C99 compilers, there are also C++ compilers to think of. It may be easier to identify the likely features we want to avoid and regex find them in the test suite. Combined with code reviews and the fact that we can change syntax in the header files whenever we want without impact (and if that's not true, let's definitely add checks for those cases), I think we can achieve this without excessive effort. (And I'm fairly sure MSVC 9.0 in C mode is the most regressive compiler we have available ;) ) Cheers, Steve Top-posted from my Windows Phone -Original Message- From: "Larry Hastings" Sent: 1/17/2017 17:02 To: "Python-Dev" Subject: Re: [Python-Dev] Can we use "designated initializer" widely incoremodules? On 01/17/2017 04:48 PM, INADA Naoki wrote: On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote: 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` ? That seems like it should work fine. Perhaps we could even add this gcc -ansi step to the normal Python build process. It shouldn't take very long, so it wouldn't slow down the build very much, and since most Python development happens on UNIX platforms (I think) this would help prevent more C99 constructs from creeping into the header files. /arry___ 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 Jan 17, 2017, at 11:41 AM, Roberto Martínez > 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/archive%40mail-archive.com
Re: [Python-Dev] Can we use "designated initializer" widely in core modules?
2017-01-18 3:28 GMT+01:00 Guido van Rossum : > I recommend being reluctant to add new fields -- the number of type objects > is larger than you'd think and these are static bytes which I consider a > relatively expensive resource. > > There's also an ABI issue with new fields -- new fields can only be accessed > after checking that the type object has been compiled with a version of the > headers that defines the field, else you'd be accessing garbage bytes. A new t_finalize field was added to the PyTypeObject object: https://www.python.org/dev/peps/pep-0442/ The ABI is protected by a new Py_TPFLAGS_HAVE_FINALIZE flag in tp_flags. If a type doesn't have this flag, the tp_finalize is not read nor written. If an extension was compiled for Pyhon 3.3, static PyTypeObject types are smaller than Python 3.4 types, since the compiler used Python 3.3 size without tp_finalize. I'm working on adding a new tp_fastcall field with a new Py_TPFLAGS_HAVE_FASTCALL flag. Same story, tp_fastcall is only used if Py_TPFLAGS_HAVE_FASTCALL is set. A wrapper is used to call the tp_fastcall field of base classes if needed: http://bugs.python.org/issue29259 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. Having Py_TPFLAGS_HAVE_FINALIZE/FASTCALL allows to inherit tp_finalize/fastcall in child classes. I want to add tp_fastcall for performance, to avoid the creation of temporary tupe/dict to pass arguments. I measured a speedup up of 22% on the bm_telco benchmark. 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] Can we use "designated initializer" widely in coremodules?
On Tue, Jan 17, 2017, at 15:34, Paul Moore wrote: > On 17 January 2017 at 20:02, 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. > > Agreed, we probably shouldn't require users of Python.h to be > C99-compliant. (Disclaimer: I have no idea how many compilers *don't* > implement this feature). We already require it through the use of several C99 features in headers such as // comments and . I agree they should be compatible with C++, though. ___ 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
