Great summary Pradeep. I had some discussions with SC members when I said we would be proposing a PEP for Dataclasses and I very much got the message "if your PEP does not involve any changes to the language we'll largely defer to the Typing SIG but otherwise your chances are really slim", which merely confirms what has been said above. I'm assuming this is because at this point typing is still seen as something that is of interest to a relatively small subset of the total Python user base and secondly it has largely (entirely?) been able to be bolted on without language changes, and so that's a tough line for the SC to cross. Perhaps as more and more package authors adopt type annotations and bump up against their limitations, attitudes will soften somewhat. But I did wonder about the statement "If the 677 proposed syntax had been expanded to include more def features instead of being conservative I think it would've been an even easier rejection for many of us". My understanding is the PEP was essentially syntactic sugar to provide a more elegant way of writing Callables, but did not address the current *expressive* limitations of Callables. Perhaps if there had been more emphasis on addressing those shortcomings, instead of just providing cleaner syntax, this might have carried more weight even if it was more ambitious in scope, as it would be solving not just a convenience problem but also a type checking problem. But TBH I did not read the PEP, just saw some of the discussion here, so I may be completely wrong here. On Tue, Feb 15, 2022 at 7:34 PM Steven Troxler <steven.troxler@gmail.com> wrote:
Thanks for kicking this thread off Pradeep!
My main takaway is that syntax changes are hard. This doesn't surprise me, my impression going into this was that the Steering Council was likely to lean against syntax changes for typing, but the consensus at PyCon was that we should put a PEP forward anyway so that we could learn from the response.
I am glad we went with the simpler option in a stand-alone PEP, since I think drafting an extended syntax PEP would have required even more work. In retrospect we might have been able to cut some of the discussion short if we had decided on this sooner, I do appreciate that in the rejection thread the SC clarified that a one-shot extended syntax PEP would not have been better.
I do wish that there were an easier way to engage with python-dev for more feedback prior to a full-blown PEP - I do agree that the level of opposition once the PEP came out was a little surprising given that in October the thread was pretty encouraging.
That said, one goal of drafting a full PEP is to clarify all aspects of a proposal so that python developers can form coherent opinions in the discussion phase. So I don't blame python-dev for not pushing back until the draft was out, and I'm not sure there's a better way. The truth is that some PEPs are going to be controversial, and a lot of that feedback will come after the draft is finished.
I think one challenge is the split discussion across typing-sig and python-dev, that made managing communications quite a bit harder - particularly because the culture of typing-sig is very pro-typing, as in "let's make this feature as useful for typing as possible", whereas in python-dev the developers are rightly concerned about how a syntax change will fit into the language overall.
Perhaps in the future we can identify when a proposal affects the core language heavily, and find a way to move discussion to python-dev early in the process.
It's always disappointing to get a rejection, but I do think this PEP helped us get clear guidance from the SC about future directions.
Many thanks to Eric, Jelle, and especially Guido and Pradeep for their help getting the PEP finished.
Cheers, Steven _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: gram@geekraver.com