On Fri, Nov 9, 2018 at 4:33 PM Victor Stinner wrote:
> It uses an opt-in option (Py_NEWCAPI define -- I'm not sure about the
> name) to get the new API. The current C API is unchanged.
>
While one can hope that this will be the only time the C API will be
revised, it may be better to number it
To hide all implementation details, I propose to stop using macros and
use function calls instead. For example, replace:
#define PyTuple_GET_ITEM(op, i) \
(((PyTupleObject *)(op))->ob_item[i])
with:
# define PyTuple_GET_ITEM(op, i) PyTuple_GetItem(op, i)
With this change, C extensions using
>
> That's exactly why I dislike "New", it's like adding "Ex" or "2" to a
> function name :-)
>
> Well, before bikeshedding on the C define name, I would prefer to see
> if the overall idea of trying to push code for the new C API in the
> master branch is a good idea, or if it's too early and the
On Fri, Nov 9, 2018 at 6:03 PM, Victor Stinner wrote:
> Le sam. 10 nov. 2018 à 02:50, Nathaniel Smith a écrit :
>> Doesn't this mean that you're just making the C API larger and more
>> complicated, rather than simplifying it? You cite some benefits
>> (tagged pointers, changing the layout of
Le sam. 10 nov. 2018 à 01:49, Michael Selik a écrit :
>> It uses an opt-in option (Py_NEWCAPI define -- I'm not sure about the
>> name) to get the new API. The current C API is unchanged.
>
> While one can hope that this will be the only time the C API will be revised,
> it may be better to
Sometimes, code is easier to understand than a long explanation, so
here is a very simple example of modified function for the new C API:
https://bugs.python.org/issue35206
https://github.com/python/cpython/pull/10443/files
PyTuple_GET_ITEM() becomes a function call and the function
Le sam. 10 nov. 2018 à 02:50, Nathaniel Smith a écrit :
> Doesn't this mean that you're just making the C API larger and more
> complicated, rather than simplifying it? You cite some benefits
> (tagged pointers, changing the layout of PyObject, making PyPy's life
> easier), but I don't see how
On Fri, Nov 9, 2018 at 4:30 PM, Victor Stinner wrote:
> Ah, important points. I don't want to touch the current C API nor make
> it less efficient. And compatibility in both directions (current C API
> <=> new C API) is very important for me. There is no such plan as
> "Python 4" which would
works for me, too:
In [9]: x = cast_int2float(0x7ff80001)
In [10]: hex(cast_float2int(x))
Out[10]: '0x7ff80001'
In [11]: x = cast_int2float(0x7ff1)
In [12]: hex(cast_float2int(x))
Out[12]: '0x7ff1'
OS-X, conda build:
Python 3.7.0 | packaged by
Hi,
The current C API of Python is both a strength and a weakness of the
Python ecosystem as a whole. It's a strength because it allows to
quickly reuse a huge number of existing libraries by writing a glue
for them. It made numpy possible and this project is a big sucess!
It's a weakness because
I'm trying to understand some unexpected behaviour with float NANs in
Python 3.5.
Background: in IEEE-754 maths, NANs (Not A Number) come in two flavours,
so called "quiet NANs" and "signalling NANs". By default, arithmetic
operations on qnans return a qnan; operations on snans "signal", which
09.11.18 13:05, Steven D'Aprano пише:
py> x = cast_int2float(0x7ff1)
py> x
nan
py> hex(cast_float2int(x))
'0x7ff80001'
I got '0x7ff1'.
___
Python-Dev mailing list
Python-Dev@python.org
ACTIVITY SUMMARY (2018-11-02 - 2018-11-09)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open6834 ( +6)
closed 40118 (+47)
total 46952 (+53)
Open issues
13 matches
Mail list logo
