[Python-Dev] Re: PEP 622 railroaded through?
On 2020-07-08 02:20, Greg Ewing wrote:
On 8/07/20 12:48 pm, Chris Angelico wrote:
"for x[0] in iter:" uses
x[0] as an assignment target,
You're right, there are some others, but I think they're
equally clear -- all the ones I can think of are directly
after a keyword ("for", "as", "import", etc.)
But in match statements, they can be arbitrarily
intermingled with other expression-like stuff.
You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.
It looks like the only thing they're doing is dropping
the *leading* dot case -- without providing any replacement
for it. That only addresses one small part of my concern,
since I think the non-leading dot is nearly as subtle.
Maybe even more so, since at least the leading dot was
obviously something different.
Also I don't like the idea of being *forced* to use
a namespace for my constants, regardless of how good an
idea the PEP authors think it is.
Prefixing values with "==" might be the clearest, an idea that, I think,
Ethan came up with. It might not look elegant, but...
___
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/UXPHME2CTQ3KMBA3QC2ZXPHDHWZAMEBS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On 8/07/20 12:48 pm, Chris Angelico wrote:
"for x[0] in iter:" uses
x[0] as an assignment target,
You're right, there are some others, but I think they're
equally clear -- all the ones I can think of are directly
after a keyword ("for", "as", "import", etc.)
But in match statements, they can be arbitrarily
intermingled with other expression-like stuff.
You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.
It looks like the only thing they're doing is dropping
the *leading* dot case -- without providing any replacement
for it. That only addresses one small part of my concern,
since I think the non-leading dot is nearly as subtle.
Maybe even more so, since at least the leading dot was
obviously something different.
Also I don't like the idea of being *forced* to use
a namespace for my constants, regardless of how good an
idea the PEP authors think it is.
--
Greg
___
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/2A2NCXMJUFBF542M2VCEQ7ZDKICYJQHK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Wed, Jul 8, 2020 at 10:45 AM Greg Ewing wrote: > > On 8/07/20 12:24 pm, Daniel Moisset wrote: > > Many people in this thread have argued that the double meaning in the > > PEP might be confusing, but Python already has a double meaning in other > > places. > > But assignment targets have always been clearly separated by > being on the left of an assignment operator, either = or :=. > The PEP proposes to intermingle them, with only very subtle clues, > such as the presence or absence of dots, to distinguish them. > Part of the point of the post you responded to is that assignment targets can be found in other contexts too - "for x[0] in iter:" uses x[0] as an assignment target, and there's no equals sign to be seen. You're right about the presence/absence of a dot being very subtle, but hang tight, wait for the next publication of the PEP; its authors are working on that exact problem. ChrisA ___ 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/N4DJC5LOZH6T5NIJ32CDDSPQAAC4K24G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On 8/07/20 12:24 pm, Daniel Moisset wrote: Many people in this thread have argued that the double meaning in the PEP might be confusing, but Python already has a double meaning in other places. But assignment targets have always been clearly separated by being on the left of an assignment operator, either = or :=. The PEP proposes to intermingle them, with only very subtle clues, such as the presence or absence of dots, to distinguish them. -- Greg ___ 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/XNM3CF4AXGZPI3DVYCV4HLOSJFZQRKNZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Tue, 7 Jul 2020 at 15:07, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > (...) Nor am I keen on "expressions" being interpreted > differently after 'case' than elsewhere in Python. Python already has "expressions" (intentional quotes) that are interpreted differently depending on the context. `x` may mean "the value bound to x" in code like `print(x)`, or "the name x inside some scope" when doing `x = 3`. `x[0]` may mean "calling `__getitem__(x, 0)` in the type of x" , or it may mean a call to `__setitem__(x, 0, something)` instead if you do `for x[0] in some_iter`. `[a, *b]` may mean "build a list with a, and all the elements that come from iterating b" in some contexts, in other it might mean "extract one element from an iterator and bind it to a. Then build a list with the other elements of the same iterator, put them into a new list , and bind that to b" if you are doing `[a, *b] = myiter`. Many people in this thread have argued that the double meaning in the PEP might be confusing, but Python already has a double meaning in other places. It's so NOT confusing, that people even forget that exists :) It works because the two meanings are not completely unrelated, and that's what PEP622 is trying to achieve. It may be surprising the first time you read the PEP in the air. The question to answer is if it will be confusing after we've seen this statement half a dozen of times in our codebases. Best, D. > But I don't know > what syntax (where necessary) to suggest. > I'm not keen on special treatment of the '_' variable, and would > prefer to be able to use 'else:' after 'match'. > > Best wishes > Rob Cliffe > > On 03/07/2020 15:56, Chris Angelico wrote: > > > > The PEP is still a draft and has not been accepted. Don't worry, the > > normal process is still happening :) > > > > Having a reference implementation is a HUGE help, because people can > > play around with it. There's a fork running an interactive playground > > so you can go right now and get a feel for the way the syntax works. > > > > The implementation has *not* been merged into the CPython trunk. It's > > not a fait accompli - it's a tool to help people evaluate the proposal > > (and all of the different variants of the proposal as it evolves). > > > > Speaking with my PEP Editor hat on, I would be *thrilled* if more > > proposals came with ready-to-try code. Only a very few have that > > luxury, and a lot of the debating happens with nothing but theory - > > people consider what they *think* they'd do, without actually being > > able to try it out and see if it really does what they expect. Having > > a reference implementation isn't necessary, of course, but it's > > definitely a benefit and not a downside. Also, there HAVE been > > proposals with full reference implementations that have ended up > > getting rejected; it's not a guarantee that it'll end up getting > > merged. > > > > Hope that lessens your fears a bit :) > > > > ChrisA > > ___ > > 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/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > 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/NWNG5KII3ZJAUZ2J7X7SFV2MIBORIDJR/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/OAJZFHLBY6EF5RIOVQBSU4JWZ54CMIYZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
I would like to thank everyone who responded to me for their civilised and courteous replies. I actually expected to get a lot of slagging off, but was prepared to accept that for what seemed to me at the time to be a legitimate concern. If my fears were unfounded, I am delighted. If I have been unfair to Guido and the other developers (and it seems that I probably have), I apologise. Thank you. FWIW: I am not against the PEP. I do not have a personal axe to grind, in the form of my own pet idea which I want to see incorporated. I don't like the .name syntax (grit on Tim's monitor; does not suggest the meaning). Nor am I keen on "expressions" being interpreted differently after 'case' than elsewhere in Python. But I don't know what syntax (where necessary) to suggest. I'm not keen on special treatment of the '_' variable, and would prefer to be able to use 'else:' after 'match'. Best wishes Rob Cliffe On 03/07/2020 15:56, Chris Angelico wrote: The PEP is still a draft and has not been accepted. Don't worry, the normal process is still happening :) Having a reference implementation is a HUGE help, because people can play around with it. There's a fork running an interactive playground so you can go right now and get a feel for the way the syntax works. The implementation has *not* been merged into the CPython trunk. It's not a fait accompli - it's a tool to help people evaluate the proposal (and all of the different variants of the proposal as it evolves). Speaking with my PEP Editor hat on, I would be *thrilled* if more proposals came with ready-to-try code. Only a very few have that luxury, and a lot of the debating happens with nothing but theory - people consider what they *think* they'd do, without actually being able to try it out and see if it really does what they expect. Having a reference implementation isn't necessary, of course, but it's definitely a benefit and not a downside. Also, there HAVE been proposals with full reference implementations that have ended up getting rejected; it's not a guarantee that it'll end up getting merged. Hope that lessens your fears a bit :) ChrisA ___ 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/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/NWNG5KII3ZJAUZ2J7X7SFV2MIBORIDJR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
Since I took it upon myself to implement PEP 622, I just have a few thoughts to
add to the other excellent responses here. Hopefully these will help clarify
that the intent is not to "railroad" anything.
Rob Cliffe wrote:
> PEP 622 only seems to have been presented to the Python community only after
> a well-developed (if not finalised) implementation was built.
Well, thanks for the "well-developed" bit, but I promise that the
implementation is far from final. Since we first published the PEP, I've made
dozens of commits touching pretty much every new line of code several times.
Just last week we gutted the __match__ method in response to well-reasoned
calls to defer it.
> So there will inevitably be resistance from the developers to accept changes
> suggested on python-dev.
As the one who has been doing almost all of the development, I assure you this
isn't true. 80% of the PEP's authors have been almost entirely detached from
development of the reference implementation, so I would be very surprised if
they gave my existing work more weight than the opinions of the community... I
wrote the thing, and I certainly don't!
I volunteered to implement it because I thought the PEP and implementation
would be an interesting project while trapped at home this spring. I *like*
doing this stuff, so I'm not really worried about getting to do more of it. ;)
> And since the PEP has Guido's authority behind it, I think it is likely that
> it will eventually be accepted pretty much as it was originally written.
It has already changed quite substantially from how it was originally written.
Here's everything that's changed since we posted the first draft (we've been
pretty much dominating PEP repo traffic over the past week):
https://github.com/python/peps/commits/master/pep-0622.rst
Again, you'll notice that the entire __match__ protocol was deferred based on
feedback we received, and we've made an effort to describe the reasoning behind
many decisions that seemed obvious to us but weren't to others. The opening
sections are also getting a rewrite (again, based on Python-Dev feedback).
> Guido's 2nd email ("PEP 622: Structural Pattern Matching -- followup")
> already to me (YMMV) reads rather like "OK, you've had your fun, now try not
> to joggle our elbows too much while we get on with the work".
That's an extremely odd way to interpret his thread, which exists solely to
collect of all of the "unheard" critiques in one central location.
> I do think it's a pity that the Python community did not have the chance to
> supply feedback earlier down the road (when IMO it would have been taken more
> seriously).
It did. The very first thing we did was perform detailed surveys of 8 different
Python-Ideas threads (spanning 9 years), 13 other languages, and a handful of
the most popular Python packages for pattern matching. This is not at all the
first time this has been brought up by the community; I personally worked my
way through hundreds of emails and dozens of documents before writing a single
line of code (or PEP).
> While Guido and the other developers have obviously already put a huge amount
> of work into this PEP (and by now probably have a significant emotional
> investment in it), I do hope that they will take the time to consider
> seriously and on their merits most/all suggested changes, rather than being
> tempted to rush through the acceptance and implementation of the PEP.
Don't worry; I have a much stronger emotional connection to Python's continued
success and community than to a quarantine project that Guido nerd-sniped me
with a few months ago. ;)
Brandt
___
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/JB7WSMUUVBNDYSNLECJEYK75WFSJMM6X/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On 7/1/2020 4:14 PM, Rob Cliffe via Python-Dev wrote: I have an uneasy feeling about this PEP. I can understand that. AFAIK the usual procedure for adding a new feature to Python is: An idea is raised and attracts some support. Someone sufficiently motivated writes a PEP. The PEP is thoroughly discussed. Eventually a consensus (or at least an "agree to differ" stalemate) is reached. The PEP is accepted (if it is). (Then and only then) Someone works on the implementation. etc. To the extent that this is true, a big reason is that many people do not want to write code until they are somewhat sure it will be accepted. But we can almost never be sure until we know what the code is, or will be -- in detail. 'Show us some code' is common in discussion. Is the feature possible, or are we wasting out time discussing it? Will it be fast enough? Will the code be maintainable? Or too ugly to look at? The same issue comes up on bpo issues. 'Please either give a really detailed specification, or submit a PR.' 'Will it be accepted?' 'We cannot tell until we see it.' Sometimes, someone not a PEP or bpo issue author offers to contribute an implementation to move discussion along to possible acceptance. However, PEP 622 only seems to have been presented to the Python community only *after* a well-developed (if not finalised) implementation was built. A fait accompli. I would be annoyed too if I thought it were true, but I don't. AFAIK, the implementation on someone's private fork has not yet been presented as a PR ready to be committed at the press of the green button. And since the PEP has Guido's authority behind it, I think it is likely that it will eventually be accepted pretty much as it was originally written. I suspect that Guido retired from the decision council in part so that he could submit PEP level changes to it as an independent person not on the council. The new PEG parser was the first new PEP. I believe Guido was looking at PEG parsers last summer, before last fall's council election. The theoretical advantage was clear; the practical application to Python not so much. He refrained from submitting a PEP until he had a couple of collaborators to help produce an initial implementation that answered the inevitable questions that would have made discussion without an implementation moot. Is a PEG parser matching the current parser possible?, fast enough?, compact enough?, and 'will there be the needed follow through maintenance'? It is common for a reasonably complicated context free grammar to be ambiguous in the sense that a given sequence of tokens can be produced by more than one sequence of applications of the production rules. But we want machine parsing of code to a particular sequence to be unambiguious, deterministic, and fast. An LL(1) parser uses and is limited to one token lookahead and cannot unambiguously parse all context-free languages. The PEG parser cuts the ambiguity knot by ordering production rules and accepting the first match. This is the same rule proposed for match statements and is similar to the disambiguating rule for if statements in Python and many other languages (but not all): first true condition wins. (Python also does the same for expressions with side-effects with a left-to-right evaluation rule.) Each condition is implicitly augmented with 'and none of the previous conditions'. In ordered matching, each pattern has a similar implicit condition. Ordered evaluation at the expression level is not much of an issue for human readers. I think making words keywords only in certain easily read contexts, such as 'match' followed by followed by ':', is also not much of an issue. I suspect that some of the proposed match patterns require the new PEP parser and that this has something to do with people's uneasiness. Removing the LL(1) limitation lets us add grammar rules that we want, but also allows for constructions that are unneeded* or hard for humans to read. *Prior to the match proposal, Guido reported on python-ideas that he had developed a PEG grammar and resulting parser and compiler that allowed for omitting parentheses in at least some calls with arguments. He dropped the idea when the coredev reaction was neutral to negative. -- 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/WCGSM2BA7PMI6DN3Q6MJOLR4EKV5SCI5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Fri, Jul 3, 2020 at 7:39 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> Whoa!
>
> I have an uneasy feeling about this PEP.
>
> AFAIK the usual procedure for adding a new feature to Python is:
> An idea is raised and attracts some support.
> Someone sufficiently motivated writes a PEP.
> The PEP is thoroughly discussed.
> Eventually a consensus (or at least an "agree to differ" stalemate)
> is reached.
> The PEP is accepted (if it is).
> (Then and only then) Someone works on the implementation.
>
That "then and only then" part is not correct. It just happens to be
typical due to people wanting to see if their idea has any support before
putting in the effort to actually code it up. Personally I sometimes wonder
if we should require a proof-of-concept upfront for all PEPs that introduce
a code change.
> etc.
>
> However, PEP 622 only seems to have been presented to the Python
> community only *after* a well-developed (if not finalised)
> implementation was built. A fait accompli. So there will inevitably be
> resistance from the developers to accept changes suggested on
> python-dev.
Then that's on them. But it may backfire if people don't like what there
PEP is presenting.
> And since the PEP has Guido's authority behind it, I think
> it is likely that it will eventually be accepted pretty much as it was
> originally written.
>
I'm trying to not take that as an insult, but I will say the steering
council does not rubber stamp Guido's PEPs. We do debate them and consider
them like any other PEP. It's not our fault he has a good sense of design
even in retirement. 😉 So as usual, once this PEP is ready for
consideration (which it isn't as stated by the PEP authors), we will
consider it like any other PEP that tries to change the language.
> This means that most of the discussion we have seen on python-dev (and
> there has been a lot) will end up being just pissing in the wind.
Once again, it is at the PEP author's peril to not listen to people's
suggestions and risk the PEP not being accepted due to the design not
meeting standards for acceptance. And they are still required to keep the
Rejected Ideas section of the PEP up-to-date or else the PEP will not be
considered.
> (I
> don't mean to be vulgar or disrespectful; I just can't think of another
> phrase that conveys my meaning so well.)
I think you're looking for "ignored".
-Brett
> And Guido's 2nd email ("PEP
> 622: Structural Pattern Matching -- followup") already to me (YMMV)
> reads rather like "OK, you've had your fun, now try not to joggle our
> elbows too much while we get on with the work".
>
> I don't know how many of the decisions made in the PEP are right and how
> many could be improved (it is of course a subjective question anyway).
> I do think it's a pity that the Python community did not have the chance
> to supply feedback earlier down the road (when IMO it would have been
> taken more seriously).
> While Guido and the other developers have obviously already put a huge
> amount of work into this PEP (and by now probably have a significant
> emotional investment in it), I do hope that they will take the time to
> consider seriously and on their merits most/all suggested changes,
> rather than being tempted to rush through the acceptance and
> implementation of the PEP.
>
> Best wishes
> Rob Cliffe
> ___
> 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/IG4VNKZF4J7OR3L665PE26KL7L6SFQSQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/PWEGG4L4LV4GG3R5NLK7NV6NXBQJ2IQ4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Fri, Jul 3, 2020, 12:40 Eric Snow wrote: > Also, keep in mind that PEPs are a tool for the decision maker (i.e. > BDFL delegate). Effectively, everything else is convention. The process > usually involves community feedback, but has never been community-driven. > All this has become more painful for volunteers as the Python community has > grown. > > -eric > To further elaborate on that, a PEP isn't legislation to be approved by the community. Rather, it is meant to capture the proposal and discussion sufficiently that the BDFL/delegate can make a good decision. Ultimately there isn't much more to the process than that, beyond convention. The BDFL-delegate is trusted to do the right thing and the steering council is there as a backstop. It's up to the decision maker to reach a conclusion and it makes sense that they especially consider community impact. However, there is no requirement of community approval. This is not new. Over the years quite a few decisions by Guido (as BDFL) sparked controversy yet in hindsight Python is better for each of those decisions. (See PEP 20.) The main difference in recent years is the growth of the Python community, which is a happy problem even if a complex one. :) There has been a huge influx of folks without context on Python's governance but with contrary expectations and loud voices. On the downside, growth has greatly increased communications traffic and signal-to-noise, as well as somewhat shifting tone in the wrong direction. Unfortunately all this contributed to us losing our BDFL. :( Thankfully we have the steering council as a replacement. Regardless, Python is not run as a democracy nor by a representative body. Instead, this is a group of trusted volunteers that are trying their best to keep Python going and make it better. The sacrifices they make reflect how much they care about the language and the community, especially as dissenting voices increase in volume and vitriol. That negativity has a real impact. -eric > ___ 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/GTOD2OHTIJU34DQS6XH756X4K2FLL2C2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Fri, Jul 3, 2020, 09:18 Antoine Pitrou wrote: > I think what you describe as "the usual procedure" isn't as usual as > you think. > +1 Also, keep in mind that PEPs are a tool for the decision maker (i.e. BDFL delegate). Effectively, everything else is convention. The process usually involves community feedback, but has never been community-driven. All this has become more painful for volunteers as the Python community has grown. -eric > ___ 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/QUFB5NI64ASIESOCWHNPUQZPR5BEMXQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Fri, Jul 3, 2020 at 4:42 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > And since the PEP has Guido's authority behind it, I think > it is likely that it will eventually be accepted pretty much as it was > originally written. > This seems a bit unfair to Guido. He seems to put a lot of effort into taking onboard feedback and I would prefer it if the community encouraged long term contributors to keep contributing, rather than suggesting that this was somehow problematic (of course new contributors are good too, as are new-and-old contributors working together). Full disclosure: I'm not a huge fan of this PEP myself -- it seems to add a lot of new syntax to support a coding idiom that I consider an anti-pattern -- but others seem to have raised similar points to mine, so I think my point of view has already been fairly well represented in the discussion. ___ 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/YCLL5H7NYKUEEBTQHPQSRQANV5JKFAQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Wed, 1 Jul 2020 21:14:00 +0100 Rob Cliffe via Python-Dev wrote: > Whoa! > > I have an uneasy feeling about this PEP. > > AFAIK the usual procedure for adding a new feature to Python is: > An idea is raised and attracts some support. > Someone sufficiently motivated writes a PEP. > The PEP is thoroughly discussed. > Eventually a consensus (or at least an "agree to differ" stalemate) > is reached. > The PEP is accepted (if it is). > (Then and only then) Someone works on the implementation. > etc. > > However, PEP 622 only seems to have been presented to the Python > community only *after* a well-developed (if not finalised) > implementation was built. A fait accompli. I think what you describe as "the usual procedure" isn't as usual as you think. For example, when I wrote PEP 442 (Safe object finalization), I don't remember a preliminary round of raising support for the idea. I had that idea in mind after repeated frustration with the previous finalization semantics, attempted writing an implementation which ended up functional, and then wrote a PEP from it. That said, PEP 622 is a much broader PEP adding a whole new syntactical feature with unusual semantics attached to it, so it's conceivable to be more cautious with the discussion process. Regards Antoine. ___ 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/IGDMVG6N5U4I76YH6SUWGS5Q4XDE3OT6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 railroaded through?
On Sat, Jul 4, 2020 at 12:48 AM Rob Cliffe via Python-Dev wrote: > > Whoa! > > I have an uneasy feeling about this PEP. > > AFAIK the usual procedure for adding a new feature to Python is: > An idea is raised and attracts some support. > Someone sufficiently motivated writes a PEP. > The PEP is thoroughly discussed. > Eventually a consensus (or at least an "agree to differ" stalemate) > is reached. > The PEP is accepted (if it is). > (Then and only then) Someone works on the implementation. > etc. > > However, PEP 622 only seems to have been presented to the Python > community only *after* a well-developed (if not finalised) > implementation was built. A fait accompli. The PEP is still a draft and has not been accepted. Don't worry, the normal process is still happening :) Having a reference implementation is a HUGE help, because people can play around with it. There's a fork running an interactive playground so you can go right now and get a feel for the way the syntax works. The implementation has *not* been merged into the CPython trunk. It's not a fait accompli - it's a tool to help people evaluate the proposal (and all of the different variants of the proposal as it evolves). Speaking with my PEP Editor hat on, I would be *thrilled* if more proposals came with ready-to-try code. Only a very few have that luxury, and a lot of the debating happens with nothing but theory - people consider what they *think* they'd do, without actually being able to try it out and see if it really does what they expect. Having a reference implementation isn't necessary, of course, but it's definitely a benefit and not a downside. Also, there HAVE been proposals with full reference implementations that have ended up getting rejected; it's not a guarantee that it'll end up getting merged. Hope that lessens your fears a bit :) ChrisA ___ 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/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/ Code of Conduct: http://python.org/psf/codeofconduct/
