My plan was to post it here and see what the response was first. Back in January, when I posted the first draft, I got some very useful feedback that resulted in some dramatic changes. This time around, so far, nobody has suggested even minor changes. Folks have just expressed their opinions about it (which is fine).
Still left to do: ping the project leads of some other static type analysis projects and see if they have any feedback to contribute. Once the dust completely settles around the conversation here, I expect to formally submit the PEP, hopefully later this week.
On 4/14/21 12:22 PM, Brett Cannon wrote:
On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum <email@example.com mailto:firstname.lastname@example.org> wrote:
Let's just wait for the SC to join the discussion. I'm sure they will, eventually.
FYI the PEP has not been sent to us via https://github.com/python/steering-council/issues https://github.com/python/steering-council/issues as ready for pronouncement, so we have not started officially discussing this PEP yet.
On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings <email@example.com <mailto:firstname.lastname@example.org>> wrote: On 4/14/21 10:44 AM, Guido van Rossum wrote:
besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits, and undoing will be just as hard).
I'm not sure either of those statements is true. Accepting PEP 649 as written would deprecate stringized annotations, it's true. But the SC can make any decision it wants here, including only accepting the new semantics of 649 without deprecating stringized annotations. They could remain in the language for another release (or two? or three?) while we "kick the can down the road". This is not without its costs too but it might be the best approach for now. As for undoing the effort to make stringized annotations the default, git should do most of the heavy lifting here. There's a technique where you check out the revision that made the change, generate a reverse patch, apply it, and check that in. This creates a new head which you then merge. That's what I did when I created my co_annotations branch, and at the time it was literally the work of ten minutes. I gather the list of changes is more substantial now, so this would have to be done multiple times, and it may be more involved. Still, if PEP 649 is accepted, I would happily volunteer to undertake this part of the workload. Cheers, //arry/ _______________________________________________ Python-Dev mailing list -- email@example.com <mailto:firstname.lastname@example.org> To unsubscribe send an email to email@example.com <mailto:firstname.lastname@example.org> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/> Message archived at https://email@example.com/message/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/ <https://firstname.lastname@example.org/message/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/> -- --Guido van Rossum (python.org/~guido <http://python.org/~guido>) /Pronouns: he/him //(why is my pronoun here?)/ <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> _______________________________________________ Python-Dev mailing list -- email@example.com <mailto:firstname.lastname@example.org> To unsubscribe send an email to email@example.com <mailto:firstname.lastname@example.org> https://mail.python.org/mailman3/lists/python-dev.python.org/ <https://mail.python.org/mailman3/lists/python-dev.python.org/> Message archived at https://email@example.com/message/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/ <https://firstname.lastname@example.org/message/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>