[Python-Dev] SC Acceptance: PEP 646 -- Variadic Generics
On 17. 11. 21 23:47, Barry Warsaw wrote: Hello Mark, Matthew, Pradeep, Vincent, and Guido, The Python Steering Council discussed the latest version of PEP 646 (Variadic Generics) at our last meeting, and have unanimously decided to accept the PEP. Congratulations! We want to specifically mention that we appreciate the way you called out the Python grammar changes required by the typing features you proposed. As we’ve said before, the Steering Council strongly believes that the typing language and the “general” Python programming language should remain aligned, so the implications of syntax change proposed in the PEP for typing needed to be addressed for non-typed Python as well. The PEP explains this change well, and does a good job of justifying the semantics and usefulness of the change for non-type related purposes. Please feel free to change the PEP status to Accepted, and to merge your changes to Python 3.11 at your convenience. With our appreciation, -Barry (on behalf of the Python Steering Council) Hello Mark, Matthew, Pradeep, Vincent, and Guido, The 2022 Python Steering Council discussed the updated PEP 646 -- Variadic Generics, and decided to accept the PEP again, with the following note: The details around multiple unpackings in a type expression aren't specified precisely. This gives individual type checkers some leeway, but can be tightened in future PEPs. Please feel free to change the PEP status to Accepted and add the note to it, and merge your changes to Python 3.11. As Barry mentioned previously, we appreciate justifying the changes for non-typed Python as well. Thank you for your patience as we set up the new SC, and happy typing! - Petr (on behalf of the Python Steering Council) ___ 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/OR5RKV7GAVSGLVH3JAGQ6OXFAXIP5XDX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11
Am 18.01.22 um 22:57 schrieb Victor Stinner: At the end of my first email, I also suggest thinking about incompatible changes differently, try to make affected projects compatible in advance. The problem are not the changes themselves, but how they are introduced in Python, and more globally how they are introduced "in the Python ecosystem" (!). I believe that some (semi-) automated way to actively test and notify important projects of deprecations/removals before a release would be a great addition to the Python ecosystem. This is a complicated issue, but well worth it. (I'm not volunteering. :) ) - Sebastian ___ 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/4QVAHO4U5QC44QWMJNCONNNE5HVDQPX3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11
On Wed, Jan 19, 2022 at 11:58 AM Sebastian Rittau wrote: > > Am 18.01.22 um 22:57 schrieb Victor Stinner: > > At the end of my first email, I also suggest thinking about > > incompatible changes differently, try to make affected projects > > compatible in advance. The problem are not the changes themselves, but > > how they are introduced in Python, and more globally how they are > > introduced "in the Python ecosystem" (!). > > > I believe that some (semi-) automated way to actively test and notify > important projects of deprecations/removals before a release would be a > great addition to the Python ecosystem. This is a complicated issue, but > well worth it. (I'm not volunteering. :) ) In practice, it is the work that we are doing on Fedora, but for changes already merged in Python. Once, I wrote a small project https://github.com/vstinner/pythonci to test a few projects on a modified Python (with a patch applied), but it's really hard to automate the creation of the environment to test a project. It's hard to download and install dependencies in a reproducible way, especially for "non-Python" dependencies (Linux packages). Fedora already has recipes for that: RPM packages with "build dependencies", commands to download the code, apply patches if needed, run the test suite, etc. With my project, quickly, I had to patch pip, setuptools, etc. For example, to fix ResourceWarning or a DeprecationWarning (remember collections.MutableMapping removal? html5lib has to be patched manually, the vendored copy inside pip!). Maintaining patches on multiple projects is not easy. Well, if someone wants to help me on the pythonci project, you're welcome ;-) I'm interested to investigate different approaches to have simpler and more reliable "recipes". 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/EWS4TZTHBNAGH6N5SUXRPCGW7CUL5SB7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics
Fantastic, Petr! Thanks for letting us know - and thank you once again for your patience with our last-minute changes! We'll go ahead and mark the PEP as accepted, and merge our CPython implementation soon. On Wed, 19 Jan 2022 at 08:34, Petr Viktorin wrote: > On 17. 11. 21 23:47, Barry Warsaw wrote: > > Hello Mark, Matthew, Pradeep, Vincent, and Guido, > > > > The Python Steering Council discussed the latest version of PEP 646 > (Variadic Generics) at our last meeting, and have unanimously decided to > accept the PEP. Congratulations! > > > > We want to specifically mention that we appreciate the way you called > out the Python grammar changes required by the typing features you > proposed. As we’ve said before, the Steering Council strongly believes > that the typing language and the “general” Python programming language > should remain aligned, so the implications of syntax change proposed in the > PEP for typing needed to be addressed for non-typed Python as well. The > PEP explains this change well, and does a good job of justifying the > semantics and usefulness of the change for non-type related purposes. > > > > Please feel free to change the PEP status to Accepted, and to merge your > changes to Python 3.11 at your convenience. > > > > With our appreciation, > > -Barry (on behalf of the Python Steering Council) > > > Hello Mark, Matthew, Pradeep, Vincent, and Guido, > > The 2022 Python Steering Council discussed the updated PEP 646 -- > Variadic Generics, and decided to accept the PEP again, with the > following note: > >The details around multiple unpackings in a type expression aren't >specified precisely. This gives individual type checkers some leeway, >but can be tightened in future PEPs. > > Please feel free to change the PEP status to Accepted and add the note > to it, and merge your changes to Python 3.11. > > As Barry mentioned previously, we appreciate justifying the changes for > non-typed Python as well. > > > Thank you for your patience as we set up the new SC, and happy typing! > - Petr (on behalf of the Python Steering Council) > ___ 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/HSVDU4YJFOAEBS3NIE77UVEF7G34DZ7Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restated typing issue for class fields.
First note: Python itself does not enforce that annotations be type objects. So for your system, you are free to use (a,b) if you like. (As long as a and b are defined. Of course, then your code wouldn’t work with static type checkers. But the trick is that annotations are Python, and (a,b) is an instance of tuple, not the tuple type. When should a type checker use the type of the annotation rather than the annotation itself? So this would be introducing a typing language that’s a bit different that Python — see a recent thread on this list about that. Another note: making it really easy to type things as concrete types like list and tuple would encourage overly specific typing:-( Of course, if this was actually done, then [] could mean MutableSequence, rather than list, which I think would be pretty cool :-) -CHB On Tue, Jan 18, 2022 at 11:53 PM Vincent Risi wrote: > I have written an xsd parser to generate python classes. I also have > written a utility to read in an xml file to populate the python classes. > As well as a utility to write xml from the python classes thus generated. > For example the code below that I include here shows a small sample of the > generated code. > The __annotations__ for these are very easy to use by the utility code for > doing their job. > > Using the typing list[x] and tuple[a,b] do not work as well as > - [x] instead of list[x] > - (a, b) instead of tuple(a, b) > > I seem to feel list[x] and tuple[a,b] are far more non Python, requiring > having to parse the string they return in a complicated way. > > Looping through the annotations to get the field types it's easy to test > for list or tuple and then get the field type for the list or tuple and the > usage for the tuple. > > I have been using Python from version 1.6 and have been involved in > writing and generating tons of lines of Python. > > ATTRIB, PSEUDO, ASIS = range(3) > > class RecordType: > isNew: str > column: (str,ATTRIB) > whizz: (str,PSEUDO) > def __init__(self): > self.isNew = '' > self.whizz = '' > self.column = '' > > class MsgTableType: > record: [RecordType] > def __init__(self): > self.record = [] > > rt = RecordType() > for annote in rt.__annotations__: > print (annote, type(rt.__annotations__[annote])) > > mtt = MsgTableType() > for annote in mtt.__annotations__: > print (annote, type(mtt.__annotations__[annote])) > ___ > 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/ANSJXQTUQDGADZRLAV5YFRU74NHUBVBL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/HQARR5F3A5VY5O6DUVJIXOI6GJ3TJYC5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on PEP 673: Self Type
On Mon, Jan 17, 2022 at 7:02 AM Jelle Zijlstra wrote: > > > El lun, 17 ene 2022 a las 6:25, Petr Viktorin () > escribió: > >> On Wed, Nov 17, 2021 at 8:31 AM Pradeep Kumar Srinivasan >> wrote: >> > >> > This PEP [1] introduces a simple and intuitive way to annotate methods >> and classmethods that return an instance of their class. Such methods and >> classmethods occur quite frequently, but the existing way to annotate them >> correctly is quite arcane and error-prone. The PEP introduces a special >> type `Self` to represent the type of the `self` parameter, similar to the >> `this` type in TypeScript and the `Self` type in Rust. We have >> implementations for mypy and pyright. The PEP does not affect CPython >> directly except for the addition of one special form (Self) to typing.py >> [2]. >> > >> > Since we have reached consensus on the PEP in typing-sig [3], we wanted >> to get your comments and suggestions before submitting to the Steering >> Council. >> > >> > Thanks, >> > Pradeep Kumar Srinivasan >> > James Hilton-Balfe >> > >> > [1]: https://www.python.org/dev/peps/pep-0673/ >> > [2]: Adding `Self` to typing_extensions.py: >> https://github.com/python/typing/pull/933 >> > [3]: See the comments from typing-sig members on the Google doc: >> https://docs.google.com/document/d/1ujuSMXDmSIOJpiZyV7mvBEC8P-y55AgSzXcvhrZciuI/edit?usp=sharing >> >> Hello, and thanks for the PEP! >> Sorry I'm late, but I have two curious questions about the PEP. >> I don't think they should hold back accepting the PEP, but I'm >> interested in the answers. >> >> The PEP uses `reveal_type`, a function that's appeared in a few PEPs >> already, but was never described. Is it a standard function in typing >> tools, something specific to mypy, or pseudocode? >> > > It's a function that doesn't exist at runtime, but when a type checker > sees a call, it emits the inferred type of the argument. It originated with > mypy but I believe has been adopted by all type checkers. > > There's been some talk of adding it to the `typing` module, but that > hasn't happened so far. I opened https://bugs.python.org/issue46414 to > suggest adding it. > Yes, it is a pseudo function that has been adopted afaik by all type checkers, e.g., Mypy, Pyre, Pyright. It's useful for debugging type errors by using `reveal_type()` and running the type checker. I honestly didn't even realize that it wasn't specified in PEP 484 until you asked. Do you suggest adding an explanation in the PEP or is it reasonably self-explanatory? I see a few other PEPs using it. > >> >> The PEP says "we reject Self in metaclasses." >> "Metaclass" can mean "subclass of `type`", or it can refer to how a >> value is used -- for example, you can write `class >> Foo(metaclass=print): ...`. >> In the PEP's example, is MyMetaclass rejected because: >> - it's used as a metaclass in a class statement, or >> - it's a subclass of `type` (so it's rejected even if unused), or >> - it becomes a class of a class? >> Or is the exact interpretation best left to the type checker? >> > The PEP rejects `Self` used in `MyMetaclass` because the class is a subclass of `type`. So, there would be a type error even if `MyMetaclass` were unused. In general, the `# Rejected` comment indicates the position at which the type checker would emit a type error, as per the convention in other typing PEPs. So, in the PEP's metaclass example, we suggest that type errors be emitted at the uses of `Self` in the return annotations of `__new__` and `__mul__`. (The exact error and position is left up to the type checker.) Thanks for the questions! ___ >> 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/DVOQK3U6MOYXPRXF5OVLVLJBPEJRUIM5/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- S Pradeep Kumar ___ 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/KSFAFKT6Q7CGD4V6B5WXSPPJHATPYGIA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
> On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote: > > We considered using colours and other markers such as bold text, but that > opens a considerable can of worms with detecting in all systems and > configurations if that can be done. I have been told that some of these > situations are quite tricky and is not as easy as checking for tty support. > In the apps I work on as open source and paid work tracebacks are put into log files so that we can fix the rare bugs. It would not be nice if the traceback module API started providing text with embedded escape sequences without a way to turn then off in the API. On the other hand it would be great to be able, as an API call, to set the style of the traceback text. Barry ___ 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/UMWXLNTKNFX45HPIVM2U6TQP2JPQEWFF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
On 1/19/22 1:10 PM, Barry Scott wrote: > On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote: >> We considered using colours and other markers such as bold text, but that opens a considerable can of worms with >> detecting in all systems and configurations if that can be done. I have been told that some of these situations are >> quite tricky and is not as easy as checking for tty support. >> > > In the apps I work on as open source and paid work tracebacks are put into log files so that > we can fix the rare bugs. It would not be nice if the traceback module API started providing > text with embedded escape sequences without a way to turn then off in the API. An environment variable would solve this, yes? The default would be using the underlining carets, but an env var could switch that to using color instead. -- ~Ethan~ ___ 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/553Z6HJNAJ2N6KTRNTOYM54PD3NRU6FJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
> On 19 Jan 2022, at 21:19, Ethan Furman wrote: > > On 1/19/22 1:10 PM, Barry Scott wrote: > > On 18 Jan 2022, at 19:59, Pablo Galindo Salgado wrote: > > >> We considered using colours and other markers such as bold text, but that > >> opens a considerable can of worms with > >> detecting in all systems and configurations if that can be done. I have > >> been told that some of these situations are > >> quite tricky and is not as easy as checking for tty support. > >> > > > > In the apps I work on as open source and paid work tracebacks are put into > > log files so that > > we can fix the rare bugs. It would not be nice if the traceback module API > > started providing > > text with embedded escape sequences without a way to turn then off in the > > API. > > An environment variable would solve this, yes? The default would be using > the underlining carets, but an env var could switch that to using color > instead. I have no objection to use of an env var as the default at python startup. But not as the only way to set a feature. I find it a poor API. Give me a set/get API and I can design my app to behave in a suitable way for its use. It means that I cannot have all the logic of the app in the python sources. Barry ___ 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/AJZ7EELGOPHLEUJHPUBXIXTWV4G2QOH6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
> On 19 Jan 2022, at 21:19, Ethan Furman wrote: > > An environment variable would solve this, yes? The default would be using > the underlining carets, but an env var could switch that to using color > instead. Oh and if you use colours then you please give me the ability to set the colours for each usage. I have custom colour settings for a lots of unix tools so that I get contrast etc. The defaults used may only work in light mode and be unusable dark mode for example. Barry___ 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/FR24Y46TDGUN5K2DCLGCJCM6R7NDQ56P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
On 1/19/2022 5:01 PM, Barry Scott wrote: Oh and if you use colours then you please give me the ability to set the colours for each usage. IDLE has that for Error Text, along with other colors. I have custom colour settings for a lots of unix too ls so that I get contrast etc. The defaults used may only work in light mode and be unusable dark mode for example. IDLE's color settings come in themes. It comes with customizable light and dark themes. At the moment, IDLE does not see the extended non-SyntaxError error ranges because the traceback module functions do not provide them by default, or by a function-call argument. But they are supposed to be accessible with some subclassing or monkey-patching, and I intend to do so. -- Terry Jan Reedy ___ 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/P3FW2X6WCFRZ3VAEKYWA2XNVXLJMX4T7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?
> > It would not be nice if the traceback module API started providing > text with embedded escape sequences without a way to turn then off in the > API. > I think fobj.isatty() would give the traceback module a good idea whether it's writing to a display device or not. There are a number of other complications though (APIs, platform differences, TERM environment variables or lack thereof, forcible overriding through an API, what other systems (IDLE, PyCharm, etc) do, ...). If it seems the right place to make a change is in the traceback module, my recommendation would be to fork the existing module and publish your prototype on PyPI. Here's a PyPI module (last updated several years ago) that purports to color traceback output: https://pypi.org/project/colored-traceback/ (This really belongs on python-ideas, right?) Skip > ___ 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/AIOGXKOTAV6WGGQ6JHOBF4U4Q6S3RRRK/ Code of Conduct: http://python.org/psf/codeofconduct/
