[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
On 6/12/19 7:40 AM, Stefan Behnel wrote: Victor Stinner schrieb am 12.06.19 um 00:09: So yeah, the PyCode_New() change is very annoying in practical, since every single project using Cython requires a new release in practice. I think Cython's deal with regard to this is: """ If you use Cython, we will try hard to cover up the adaptations for upcoming (and existing) CPython versions for you. But you'll likely have to rerun Cython on your project before a new CPython major release comes out. """ That's obviously not ideal for projects that end up being unmaintained. But then again, you can't freeze time forever, and /any/ change to a dependency can end up being fatal to them. I personally think that rerunning Cython when a new CPython release comes out is an acceptable price to pay for a project. In the worst case, this can even be done by others, as you suggested as a common Fedora practice elsewhere, Victor. I hope this is something that improvements in Python's packaging story (specifically, PEP 518) should help with. I see the current practice of including Cython's output in releases as a workaround for the fact that you can't (reasonably) specify Cython as a build dependency. Cython is a much lighter dependency than a C compiler -- though a less common one. When there's a reliable way to specify build-time dependencies, running Cython on each build will hopefully become the obvious way to do it. Or is there something else blocking that future? ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/TGWDJ44NSCAWP2IC7DNFBJRHQL2JHQTL/
[Python-Dev] Re: Using Generic Type Constructors at Runtime
OK I will post this on typing-sig. I was directed to post here instead of there because apparently that's more about static typing not runtime typing: https://github.com/python/typing/issues/629#issuecomment-494028130 ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CK7ME3EYZPUKXMNWR4FWA5AII244ZRGR/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
Victor Stinner wrote: > Update. > > Le ven. 31 mai 2019 à 10:49, Petr Viktorin > PEP 570 (Positional-Only Parameters) changed the > > signatures of > > PyCode_New() and types.CodeType(), adding a new argument for "posargcount". > > > Pablo proposed a PR to revert PyCode_New() API to Python 3.7 API: > https://github.com/python/cpython/pull/13959 > > I dislike "PyCode_NewEx" name, it will become worse when another > parameter will be added in the future. I prefer "With" naming. I > prefer "PyCode_NewWithPosArgs()" name. I agree if a new name is chosen (I haven't decided if the parameter expansion was wrong or not in practice or if this was just poorly communicated). -Brett > > For types.CodeType constructor, well, I added CodeType.replace() to > help projects to be prepared for next CodeType constructor change :-) > But *I* am fine with breaking this constructor since very few projects > create explicitly code objects. > > > > Our policy for such changes seems to be fragmented > > tribal knowledge. I'm > > writing to check if my understanding is reasonable, so I can apply it > > and document it explicitly. > The doc has been updated: > https://bugs.python.org/issue36896 > > "If you instantiate any of these types, note that signatures may vary > between Python versions." > > > > There is a surprisingly large ecosystem of tools that > > create code objects. > > The expectation seems to be that these tools will need to be adapted for > > each minor version of Python. > For PyCode_New() change, it seems like (almost?) only projects using > Cython are affected, no? > > To not require Cython when they are installed, many projects include C > files generated by Cython in their tarball (and other released files). > > So yeah, the PyCode_New() change is very annoying in practical, since > every single project using Cython requires a new release in practice. > > For this reason, I'm in favor of reverting PyCode_New() API and add a > new function with the extra positional only parameter. > > > > Also, the expected level of API stability should be > > documented in the docs. > Note: code.h header is excluded from the stable API :-) The whole file > is surrounded by "#ifndef Py_LIMITED_API". > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/TRMWHAWPHPJIGQOEXSDTEKFARHVR3FAY/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
Petr Viktorin wrote: > On 6/12/19 7:40 AM, Stefan Behnel wrote: > > Victor Stinner schrieb am 12.06.19 um 00:09: > > So yeah, the PyCode_New() change is very annoying > > in practical, since > > every single project using Cython requires a new release in practice. > > I think Cython's deal with regard to this is: > > > > """ > > If you use Cython, we will try hard to cover up the adaptations for > > upcoming (and existing) CPython versions for you. But you'll likely have to > > rerun Cython on your project before a new CPython major release comes out. > > """ > > > > That's obviously not ideal for projects that end up being unmaintained. But > > then again, you can't freeze time forever, and /any/ change to a dependency > > can end up being fatal to them. > > > > I personally think that rerunning Cython when a new CPython release comes > > out is an acceptable price to pay for a project. In the worst case, this > > can even be done by others, as you suggested as a common Fedora practice > > elsewhere, Victor. > I hope this is something that improvements in Python's packaging story > (specifically, PEP 518) should help with. > I see the current practice of including Cython's output in releases as a > workaround for the fact that you can't (reasonably) specify Cython as a > build dependency. Cython is a much lighter dependency than a C compiler > -- though a less common one. When there's a reliable way to specify > build-time dependencies, running Cython on each build will hopefully > become the obvious way to do it. > > Or is there something else blocking that future? PEP 518 lets you specify Cython as a build dependency, but it's still up to _some_ build tool to specify that the project used Cython and then to know how to run Cython as appropriate. So if you're got setuptools working then listing setuptools, wheel, and cython as build dependencies _should_ work as you want. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CR642UOFJ4AQZCJ7WQECFURZFMHKM67E/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
I'm not one of the people who ever shipped pre-cythonized code, but I think at this point it should be pretty safe to ship just your .pyx files and not the generated C files - at least if your reason for shipping the C code was "it will be hard for people to pip install things". For /other/ reasons, it's best to ship wheels anyway, and pip will prefer wheels over source distributions, so if you ship a manylinux wheel and a Windows wheel for each of the most popular Python versions, the majority of your users won't even ever hit the source distribution anyway. PEP 518 has been supported in pip since I think version 18.0, and PEP 517/518 support in pip landed in 19.0 (though it's been a rocky few months). I do tend to live a bit ahead of the curve in terms of packaging because of my intimate familiarity with the topic, but I do think that we're at the point where the build-related problems you'll see from just shipping `.pyx` files are going to be pretty rare, if you do it right. On 6/12/19 4:11 AM, Petr Viktorin wrote: > I hope this is something that improvements in Python's packaging story > (specifically, PEP 518) should help with. > I see the current practice of including Cython's output in releases as > a workaround for the fact that you can't (reasonably) specify Cython > as a build dependency. Cython is a much lighter dependency than a C > compiler -- though a less common one. When there's a reliable way to > specify build-time dependencies, running Cython on each build will > hopefully become the obvious way to do it. signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/SMJ6WQD7Y3DRDU6OHDXUOW42MANHP2LC/
[Python-Dev] Re: Using Generic Type Constructors at Runtime
Yeah, you're kind of in an odd spot with that. :) You could try python-list. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/7CIDLPUKQEIS73HKBOQLDZEAZGSBSZBU/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
On Wed, 12 Jun 2019 00:09:10 +0200
Victor Stinner wrote:
> Update.
>
> Le ven. 31 mai 2019 à 10:49, Petr Viktorin a écrit :
> > PEP 570 (Positional-Only Parameters) changed the signatures of
> > PyCode_New() and types.CodeType(), adding a new argument for "posargcount".
> >
>
> Pablo proposed a PR to revert PyCode_New() API to Python 3.7 API:
> https://github.com/python/cpython/pull/13959
>
> I dislike "PyCode_NewEx" name, it will become worse when another
> parameter will be added in the future. I prefer "With" naming. I
> prefer "PyCode_NewWithPosArgs()" name.
Or perhaps the alternative is a struct-based approach:
typedef struct {
// ...
} PyCodeOptions;
PyObject* PyCode_New(PyCodeOptions opts);
?
Regards
Antoine.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/6K2R62CVNZXUZF3OCK6VVQIY3SD3KLBY/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
Hi Antoine,
In Python 3.4, I added "void PyMem_SetAllocator(PyMemAllocatorDomain
domain, PyMemAllocator *allocator)" to the public C API.
Problem: we wanted to add a new "calloc" field to PyMemAllocator structure.
I chose to rename the structure to PyMemAllocatorEx to ensure that all
C extensions using this function get a compilation error, rather than
leaving the new "calloc" field uninitialized. The function became:
"void PyMem_SetAllocator(PyMemAllocatorDomain domain, PyMemAllocatorEx
*allocator)"
I'm not sure what will be the new structure name when we will add new
fields (like malloc_aligned) :-(
For PyCodeOptions: does it contain posonlyargcount? If not, how do you
pass posonlyargcount. I'm not sure if you plan to handle the backward
compatibility.
Note: In the PEP 587, I added a private "_config_version" field to
PyConfig structure to prepare the structure to future extension, but
keep backward compatibility. The structure will be versionned ;-)
Victor
Le jeu. 13 juin 2019 à 01:08, Antoine Pitrou a écrit :
>
> On Wed, 12 Jun 2019 00:09:10 +0200
> Victor Stinner wrote:
> > Update.
> >
> > Le ven. 31 mai 2019 à 10:49, Petr Viktorin a écrit :
> > > PEP 570 (Positional-Only Parameters) changed the signatures of
> > > PyCode_New() and types.CodeType(), adding a new argument for
> > > "posargcount".
> >
> > Pablo proposed a PR to revert PyCode_New() API to Python 3.7 API:
> > https://github.com/python/cpython/pull/13959
> >
> > I dislike "PyCode_NewEx" name, it will become worse when another
> > parameter will be added in the future. I prefer "With" naming. I
> > prefer "PyCode_NewWithPosArgs()" name.
>
> Or perhaps the alternative is a struct-based approach:
>
> typedef struct {
> // ...
> } PyCodeOptions;
>
> PyObject* PyCode_New(PyCodeOptions opts);
>
> ?
>
> Regards
>
> Antoine.
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/6K2R62CVNZXUZF3OCK6VVQIY3SD3KLBY/
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/6OSS6VFDOPOVFBP5NEMVCZ5YN425TGBH/
