[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
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. (To be fair, I'll have to add that new Cython versions are also part of those dependencies that might end up introducing incompatible changes and forcing your code to be adapted. The upcoming Cython 3.0 release will be such a case. However, given our compatibility record so far, I still consider Cython a very fair deal.) Stefan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4J3ZPCLJBHLPJRT32X2JIBAQ3C7OAL5H/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
Neil Schemenauer schrieb am 08.06.19 um 22:46: > It would be great if we had a system that did CI testing with the > top PyPI modules. E.g. pull the latest versions of the top 100 PyPI > modules and test them with the latest CPython branch. FWIW, travis-ci provides the latest CPython master builds (and some latest dev branches). We use them in Cython for our CI tests. One of the problems is that their images include some widely used libraries like NumPy, some of which in turn depend on Cython these days, so it happened once already that they failed to provide updated images because they were lacking a Cython version that worked with them, and we didn't notice that a change in Cython was needed because the CI builds were continuing to use an outdated CPython master version. :) Ah, circular dependencies… I think they fixed something about that, though. It wasn't a problem this time, at least. We also have the "Cython testbed", which we (irregularly) use before releases to check that we didn't break more than was broken before the release. https://travis-ci.org/cython-testbed It's pretty much what was asked for here, just for Cython, and it turns out to be a considerable amount of work to keep this from breaking arbitrarily for the included projects, even without changing something in Cython along the way. Thus, personally, I would prefer a decentralised CI approach, where interested/important projects test themselves against CPython master (which many of them do already), and have them report back when they notice an undermotivated breakage. Some projects do that with Cython (and CPython) already, and that works quite well so far and seems the least work for everyone. Stefan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EOGBRUUGY7PGUUONITJYFNIHURQ5E4OK/
[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures
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. 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 -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5MKG3RWJXSM6ZEOSFUPNTPAKHQ7YRCCH/
[Python-Dev] Re: Using Generic Type Constructors at Runtime
So I don't think python-dev is the best place to be asking this. For type-specific questions you probably want the typing-sig mailing list. For generic discussions you probably want python-list. (Based on how type-specific your question is I'm going to assume typing-sig might be the best place.) This mailing list is about the development _of_ Python and not _with_ Python. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PZIN7VZV5C3SGCNZWF3BEH4RKWLVBLKC/
[Python-Dev] Re: 1 PR, multiple issues
Thanks Jeffrey Kintscher for asking this question. It is one of those "less obvious way to triage CPython issues" kind of thing. I think it would be great if this workflow can be documented and clarified in the devguide. I've opened https://github.com/python/devguide/issues/494 ᐧ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/T2VY2IQRRLJ4WQGBOAAIBTOC7GBESNI2/
[Python-Dev] Using Generic Type Constructors at Runtime
Hello all, I am working on an expression and replacement system in Python and am trying to figure out if constructors for generic classes should be done with classmethods or with functions. I have laid out an example using each in a Github issue (https://github.com/Quansight-Labs/metadsl/issues/69#issuecomment-500898932) and wanted to open the issue up the larger community because I am unsure if there is an established pattern here yet. A minimal example showing the difference is `none(int)` vs `Optional[int].none()`. (Note Optional here is not typing.Optional, but my own class). This has implications for the language, because if we want to support Optional[int].none() then we need to be able to access the generic type arguments at runtime which is currently impossible (without monkeypatching some typing internals) see https://github.com/python/typing/issues/629. But if we think the functional approach is more appropriate then we should be able to pass in TypeVars to functions at runtime, so we can define replacements on this form (see the linked issue above for the example). This would require fixing https://github.com/python/mypy/issues/6964. I would appreciate any thoughts on which is more Pythonic and more likely to continue being relevant as the typing conversation evolves. The underlying motivation is that Python is increasingly being used to build up computation that executes on other runtimes (TensorFlow, PyTorch, even if they try to hide it now) and type annotations give a nice UX for describing these APIs. We need to be able to inspect them at runtime to build up the right computation graphs, but we also want them to valid under static systems like MyPy, to continue using all the benefits it provides for dev productivity. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/75MF2B62OGVX2BVN6N6ZZE4ZRWO4JA6F/
[Python-Dev] Re: Enum and annotations
On Mon, 10 Jun 2019 at 22:37, Ethan Furman wrote: > Greetings! > > I saw my first annotation mix-up with regards to Enum today: > >https://stackoverflow.com/q/56532591/208880 > > #enum import: > from enum import Enum > > # enum definition: > class Status(Enum): > on: 1 > off: 2 > > My question for the group: > > Is this worth "fixing" or should I leave it alone? On the one hand it > seems like an obvious error, but on the other I hate getting in the way of > needs I haven't thought of. > >From the point of view of static type checkers this is an error as well (e.g. mypy gives an error at the definition site because 1 and 2 are not valid types). I don't have any opinion about whether this should be a runtime error as well. -- Ivan ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/67F4LWTCYBMWJKESYXB6V65S7ZECWADM/
