Re: [Python-Dev] Let's change to C API!
On Thu, 23 Aug 2018 08:07:08 +0200
Jeroen Demeyer wrote:
>
> > - the dependency / versioning problem (Cython is a large quick-evolving
> >third-party package that we can't decently vendor)
>
> Is that a real problem? You're sort of doing the same thing with pip
> already.
Building and developing CPython doesn't depend on pip at all. The bundled
pip copy is just an inert pack of files, as far as we are concerned.
> > - the maintenance problem (how do ensure we can change small things in
> >the C API, especially semi-private ones, without having to submit PRs
> >to Cython as well)
>
> Why don't you want to submit PRs to Cython?
Because it forces a much longer cycle time when we want to introduce a
change in the C API: first prototype the C API change, then notice it
breaks Cython, then try to make a PR (which isn't trivial, given
Cython's size), then wait for the PR to be merged and a new Cython to
be released.
> If you're saying "I don't
> want to wait for the next stable release of Cython", you could use
> development versions of Cython for development versions of CPython.
But depending on the development version of a compiler isn't very
enticing, IMHO.
> > - the debugging problem (Cython's generated C code is unreadable,
> >unlike Argument Clinic's, which can make debugging annoying)
>
> Luckily, you don't need to read the C code most of the time. And it's
> also a matter of experience: I can read Cython-generated C code just fine.
Let's be serious here. Regardless of the experience, nobody enjoys
reading / stepping through code like the following:
__Pyx_TraceLine(206,0,__PYX_ERR(1, 206, __pyx_L1_error))
__Pyx_XDECREF(__pyx_r);
__pyx_t_2 = __Pyx_GetModuleGlobalName(__pyx_n_s_datetime); if
(unlikely(!__pyx_t_2)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_GOTREF(__pyx_t_2);
__pyx_t_3 = __Pyx_PyObject_GetAttrStr(__pyx_t_2, __pyx_n_s_datetime); if
(unlikely(!__pyx_t_3)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_GOTREF(__pyx_t_3);
__Pyx_DECREF(__pyx_t_2); __pyx_t_2 = 0;
__pyx_t_2 = __Pyx_PyObject_GetAttrStr(__pyx_t_3, __pyx_n_s_utcfromtimestamp);
if (unlikely(!__pyx_t_2)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_GOTREF(__pyx_t_2);
__Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
__pyx_t_3 = __Pyx_PyFloat_DivideObjC(__pyx_v_x, __pyx_float_1e3, 1e3, 0); if
(unlikely(!__pyx_t_3)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_GOTREF(__pyx_t_3);
__pyx_t_4 = NULL;
if (CYTHON_UNPACK_METHODS && likely(PyMethod_Check(__pyx_t_2))) {
__pyx_t_4 = PyMethod_GET_SELF(__pyx_t_2);
if (likely(__pyx_t_4)) {
PyObject* function = PyMethod_GET_FUNCTION(__pyx_t_2);
__Pyx_INCREF(__pyx_t_4);
__Pyx_INCREF(function);
__Pyx_DECREF_SET(__pyx_t_2, function);
}
}
if (!__pyx_t_4) {
__pyx_t_1 = __Pyx_PyObject_CallOneArg(__pyx_t_2, __pyx_t_3); if
(unlikely(!__pyx_t_1)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
__Pyx_GOTREF(__pyx_t_1);
} else {
#if CYTHON_FAST_PYCALL
if (PyFunction_Check(__pyx_t_2)) {
PyObject *__pyx_temp[2] = {__pyx_t_4, __pyx_t_3};
__pyx_t_1 = __Pyx_PyFunction_FastCall(__pyx_t_2, __pyx_temp+1-1, 1+1); if
(unlikely(!__pyx_t_1)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_XDECREF(__pyx_t_4); __pyx_t_4 = 0;
__Pyx_GOTREF(__pyx_t_1);
__Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
} else
#endif
#if CYTHON_FAST_PYCCALL
if (__Pyx_PyFastCFunction_Check(__pyx_t_2)) {
PyObject *__pyx_temp[2] = {__pyx_t_4, __pyx_t_3};
__pyx_t_1 = __Pyx_PyCFunction_FastCall(__pyx_t_2, __pyx_temp+1-1, 1+1);
if (unlikely(!__pyx_t_1)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_XDECREF(__pyx_t_4); __pyx_t_4 = 0;
__Pyx_GOTREF(__pyx_t_1);
__Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
} else
#endif
{
__pyx_t_5 = PyTuple_New(1+1); if (unlikely(!__pyx_t_5)) __PYX_ERR(1, 206,
__pyx_L1_error)
__Pyx_GOTREF(__pyx_t_5);
__Pyx_GIVEREF(__pyx_t_4); PyTuple_SET_ITEM(__pyx_t_5, 0, __pyx_t_4);
__pyx_t_4 = NULL;
__Pyx_GIVEREF(__pyx_t_3);
PyTuple_SET_ITEM(__pyx_t_5, 0+1, __pyx_t_3);
__pyx_t_3 = 0;
__pyx_t_1 = __Pyx_PyObject_Call(__pyx_t_2, __pyx_t_5, NULL); if
(unlikely(!__pyx_t_1)) __PYX_ERR(1, 206, __pyx_L1_error)
__Pyx_GOTREF(__pyx_t_1);
__Pyx_DECREF(__pyx_t_5); __pyx_t_5 = 0;
}
}
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
[Python-Dev] Python 2.7 EOL date
Hi All, Sorry if this has been mentioned before, but I noticed the Python 2.7 EOL date was recently set to Jan 1st, 2020. My understanding was Python releases get 5 years of support from their initial release, and Python 2.7 was extended an additional 5 years. Python 2.7 was originally released on 2010-07-03, and with an original EOL of 2015-07-03. Extended 5 years, shouldn't the EOL be 2020-07-03? Also, this statement is a little unclear to me: > Specifically, 2.7 will receive bugfix support until January 1, 2020. All 2.7 development work will cease in 2020. This statement makes it sound like bugfixes end on Jan 1st, but seems to leave open the possibility that security fixes could continue through the year. Thanks! Collin ___ 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] Python 2.7 EOL date
No more security fixes after Jan 1, 2020. It is the end of Python 2.7. On Thu, Aug 23, 2018, 12:47 PM Collin Anderson wrote: > Hi All, > > Sorry if this has been mentioned before, but I noticed the Python 2.7 EOL > date was recently set to Jan 1st, 2020. > > My understanding was Python releases get 5 years of support from their > initial release, and Python 2.7 was extended an additional 5 years. > > Python 2.7 was originally released on 2010-07-03, and with an original EOL > of 2015-07-03. Extended 5 years, shouldn't the EOL be 2020-07-03? > > Also, this statement is a little unclear to me: > > > Specifically, 2.7 will receive bugfix support until January 1, 2020. All > 2.7 development work will cease in 2020. > > This statement makes it sound like bugfixes end on Jan 1st, but seems to > leave open the possibility that security fixes could continue through the > year. > > Thanks! > Collin > > > ___ > 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/mariatta.wijaya%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] Let's change to C API!
Antoine Pitrou schrieb am 23.08.2018 um 09:04:
> On Thu, 23 Aug 2018 08:07:08 +0200
> Jeroen Demeyer wrote:
>>> - the maintenance problem (how do ensure we can change small things in
>>>the C API, especially semi-private ones, without having to submit PRs
>>>to Cython as well)
>>
>> Why don't you want to submit PRs to Cython?
>
> Because it forces a much longer cycle time when we want to introduce a
> change in the C API: first prototype the C API change, then notice it
> breaks Cython, then try to make a PR (which isn't trivial, given
> Cython's size), then wait for the PR to be merged and a new Cython to
> be released.
I think you can put that argument back into the attic. When CPython 3.6 and
3.7 came out, I swear I had already forgotten which new features they
provided, because we had implemented and released most of the major
features 6-12 months earlier in Cython (backported to Py2.6). And it has
happened more than once that we pushed out a point release within a few
days to fix a real need on user side.
What I would rather like to see instead is that both of our sides try to
jointly discuss ideas for C-API changes, so that we don't even run into the
problem that changes we made on one side surprisingly break the other.
Don't forget that the spark for this whole discussion was to make it easier
to change the C-API at all. Being able to change Cython in one place and
then adapt a whole bunch of real world extensions out there by simply
regenerating their C code with it is a really cool feature. Basically, it
passes the ability to do that back into your own hands.
>> If you're saying "I don't
>> want to wait for the next stable release of Cython", you could use
>> development versions of Cython for development versions of CPython.
>
> But depending on the development version of a compiler isn't very
> enticing, IMHO.
In case that need arises, feel free to ask which git revision we recommend
for use in CPython. In the worst case, we can always create a stable branch
for you that makes sure we don't break your productivity while we're doing
our thing.
>>> - the debugging problem (Cython's generated C code is unreadable,
>>>unlike Argument Clinic's, which can make debugging annoying)
>>
>> Luckily, you don't need to read the C code most of the time. And it's
>> also a matter of experience: I can read Cython-generated C code just fine.
>
> Let's be serious here. Regardless of the experience, nobody enjoys
> reading / stepping through code like the following:
Ok, you posted generated C code, let's read it together.
> __Pyx_TraceLine(206,0,__PYX_ERR(1, 206, __pyx_L1_error))
This shows that you have enabled the generation of line tracing code with
the directive "linetrace=True", and Cython is translating line 206 of one
of your source modules here.
> __Pyx_XDECREF(__pyx_r);
> __pyx_t_2 = __Pyx_GetModuleGlobalName(__pyx_n_s_datetime); if
> (unlikely(!__pyx_t_2)) __PYX_ERR(1, 206, __pyx_L1_error)
> __Pyx_GOTREF(__pyx_t_2);
> __pyx_t_3 = __Pyx_PyObject_GetAttrStr(__pyx_t_2, __pyx_n_s_datetime); if
> (unlikely(!__pyx_t_3)) __PYX_ERR(1, 206, __pyx_L1_error)
> __Pyx_GOTREF(__pyx_t_3);
> __Pyx_DECREF(__pyx_t_2); __pyx_t_2 = 0;
> __pyx_t_2 = __Pyx_PyObject_GetAttrStr(__pyx_t_3,
> __pyx_n_s_utcfromtimestamp); if (unlikely(!__pyx_t_2)) __PYX_ERR(1, 206,
> __pyx_L1_error)
> __Pyx_GOTREF(__pyx_t_2);
> __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
This implements "datetime.datetime.utcfromtimestamp", probably used in a
"return" statement.
> __pyx_t_3 = __Pyx_PyFloat_DivideObjC(__pyx_v_x, __pyx_float_1e3, 1e3, 0);
> if (unlikely(!__pyx_t_3)) __PYX_ERR(1, 206, __pyx_L1_error)
> __Pyx_GOTREF(__pyx_t_3);
This is "x/1e3", optimised for fast computation in the case that "x" turns
out to be a number, especially a float object.
> __pyx_t_4 = NULL;
> if (CYTHON_UNPACK_METHODS && likely(PyMethod_Check(__pyx_t_2))) {
> __pyx_t_4 = PyMethod_GET_SELF(__pyx_t_2);
> if (likely(__pyx_t_4)) {
> PyObject* function = PyMethod_GET_FUNCTION(__pyx_t_2);
> __Pyx_INCREF(__pyx_t_4);
> __Pyx_INCREF(function);
> __Pyx_DECREF_SET(__pyx_t_2, function);
> }
> }
> if (!__pyx_t_4) {
> __pyx_t_1 = __Pyx_PyObject_CallOneArg(__pyx_t_2, __pyx_t_3); if
> (unlikely(!__pyx_t_1)) __PYX_ERR(1, 206, __pyx_L1_error)
> __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
> __Pyx_GOTREF(__pyx_t_1);
> } else {
> #if CYTHON_FAST_PYCALL
> if (PyFunction_Check(__pyx_t_2)) {
> PyObject *__pyx_temp[2] = {__pyx_t_4, __pyx_t_3};
> __pyx_t_1 = __Pyx_PyFunction_FastCall(__pyx_t_2, __pyx_temp+1-1, 1+1);
> if (unlikely(!__pyx_t_1)) __PYX_ERR(1, 206, __pyx_L1_error)
> __Pyx_XDECREF(__pyx_t_4); __pyx_t_4 = 0;
> __Pyx_GOTREF(__pyx_t_1);
> __Pyx_DECREF(__pyx_t_3); __pyx_t_3 = 0;
> } else
> #endif
> #if CYTHON_FAST_PYCCALL
> if (__Pyx_PyFastCFunction_Check(__pyx_t_2)) {
> PyObject *__pyx_temp[2] = {__pyx_t_4, __p
Re: [Python-Dev] Let's change to C API!
Greg Ewing schrieb am 23.08.2018 um 03:34: > Neil Schemenauer wrote: >> Perhaps a "argument clinic on steroids" would be the proper >> approach. So, extensions would mostly be written in C. However, we >> would have a pre-processor that does some "magic" to make using the >> Python API cleaner. > > You seem to have started on the train of thought that > led me to create Pyrex (the precursor to Cython). Greg, thank you so much for doing that. It's a great design that we and hoards of Cython users out there continue to benefit from. Stefan ___ 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] Python 2.7 EOL date
Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update Victor 2018-08-23 20:53 GMT+02:00 Collin Anderson : > Hi All, > > Sorry if this has been mentioned before, but I noticed the Python 2.7 EOL > date was recently set to Jan 1st, 2020. > > My understanding was Python releases get 5 years of support from their > initial release, and Python 2.7 was extended an additional 5 years. > > Python 2.7 was originally released on 2010-07-03, and with an original EOL > of 2015-07-03. Extended 5 years, shouldn't the EOL be 2020-07-03? > > Also, this statement is a little unclear to me: > >> Specifically, 2.7 will receive bugfix support until January 1, 2020. All >> 2.7 development work will cease in 2020. > > This statement makes it sound like bugfixes end on Jan 1st, but seems to > leave open the possibility that security fixes could continue through the > year. > > Thanks! > Collin > > > > ___ > 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/vstinner%40redhat.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] Python 2.7 EOL date
On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update We could probably make it more clear in this section and/or in https://www.python.org/dev/peps/pep-0373/#id4 that there will be no 2.7 releases of any kind after 2020-01-01: no bugfix, no security, and no source releases after that date. I'll whip something up if there's general agreement. Eric Victor 2018-08-23 20:53 GMT+02:00 Collin Anderson : Hi All, Sorry if this has been mentioned before, but I noticed the Python 2.7 EOL date was recently set to Jan 1st, 2020. My understanding was Python releases get 5 years of support from their initial release, and Python 2.7 was extended an additional 5 years. Python 2.7 was originally released on 2010-07-03, and with an original EOL of 2015-07-03. Extended 5 years, shouldn't the EOL be 2020-07-03? Also, this statement is a little unclear to me: Specifically, 2.7 will receive bugfix support until January 1, 2020. All 2.7 development work will cease in 2020. This statement makes it sound like bugfixes end on Jan 1st, but seems to leave open the possibility that security fixes could continue through the year. Thanks! Collin ___ 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/vstinner%40redhat.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/eric%2Ba-python-dev%40trueblade.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] Python 2.7 EOL date
On Aug 23, 2018, at 15:23, Eric V. Smith wrote: > > On 8/23/2018 4:30 PM, Victor Stinner wrote: >> Hi, >> The reference is the PEP 373 "Python 2.7 Release Schedule". See the >> "Update" section: >> https://www.python.org/dev/peps/pep-0373/#update > > We could probably make it more clear in this section and/or in > https://www.python.org/dev/peps/pep-0373/#id4 that there will be no 2.7 > releases of any kind after 2020-01-01: no bugfix, no security, and no source > releases after that date. > > I'll whip something up if there's general agreement. +1 from me, but IIRC, Benjamin has said that the final 2.7 release may not happen *exactly* on January 1st (due to holidays and such), but that we should still consider that the “hammer date” when all support stops. We should get some confirmation from Benjamin (the 2.7 release manager) on the (tentative) exact final release date, and then codify that in the PEP. I’d be very happy if that, or say December 31 2019 were the actual last release date. Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ 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] Python 2.7 EOL date
On 8/23/2018 8:14 PM, Barry Warsaw wrote: On Aug 23, 2018, at 15:23, Eric V. Smith wrote: On 8/23/2018 4:30 PM, Victor Stinner wrote: Hi, The reference is the PEP 373 "Python 2.7 Release Schedule". See the "Update" section: https://www.python.org/dev/peps/pep-0373/#update We could probably make it more clear in this section and/or in https://www.python.org/dev/peps/pep-0373/#id4 that there will be no 2.7 releases of any kind after 2020-01-01: no bugfix, no security, and no source releases after that date. I'll whip something up if there's general agreement. +1 from me, but IIRC, Benjamin has said that the final 2.7 release may not happen *exactly* on January 1st (due to holidays and such), but that we should still consider that the “hammer date” when all support stops. We should get some confirmation from Benjamin (the 2.7 release manager) on the (tentative) exact final release date, and then codify that in the PEP. I’d be very happy if that, or say December 31 2019 were the actual last release date. Agreed on getting Benjamin's blessing. We can discuss it in a few weeks. Eric ___ 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
