[Python-ideas] Re: Compound statement colon (Re: Re: Improve SyntaxError for obvious issue:)
On 2020-01-16 21:08, Rob Cliffe via Python-ideas wrote: On 16/01/2020 18:14:18, Random832 wrote: On Tue, Jan 14, 2020, at 18:15, David Mertz wrote: For what it's worth, after 20+ years of using Python, forgetting the colon for blocks remains the most common error I make by a fairly wide margin. Of course, once I see the error message—even being not all that descriptive of the real issue—I immediately know what to fix too. I don't know about "most common" but I do it fairly frequently. What if the colon were made optional, with an eye to perhaps eventually no longer using it as the preferred style for new code? We had a post a while ago about the possibility of using the lack of a colon as an implicit line continuation (like with parentheses, e.g. "if a\nand b:", and this was (reasonably) rejected. But if a line beginning as a compound statement and ending without a colon is *never* going to have a valid meaning as something else... what's the point of the colon, otherwise? Seems like just grit on the screen. +1 FWIW, I've hardly ever forgotten the colon, even when Python was new to me. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T2B542GZ2ZLE7NOMIWJXNPGLS4UEMGN4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Compound statement colon (Re: Re: Improve SyntaxError for obvious issue:)
On 16/01/2020 18:14:18, Random832 wrote: On Tue, Jan 14, 2020, at 18:15, David Mertz wrote: For what it's worth, after 20+ years of using Python, forgetting the colon for blocks remains the most common error I make by a fairly wide margin. Of course, once I see the error message—even being not all that descriptive of the real issue—I immediately know what to fix too. I don't know about "most common" but I do it fairly frequently. What if the colon were made optional, with an eye to perhaps eventually no longer using it as the preferred style for new code? We had a post a while ago about the possibility of using the lack of a colon as an implicit line continuation (like with parentheses, e.g. "if a\nand b:", and this was (reasonably) rejected. But if a line beginning as a compound statement and ending without a colon is *never* going to have a valid meaning as something else... what's the point of the colon, otherwise? Seems like just grit on the screen. +1 Rob Cliffe ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZXQIHPZBREOSGIAEZRTKN4YLYZSQA4XB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: "and if" and "or if" for trailing if statements - including explicit fallthrough
On 21/12/2019 23:59:27, Chris Angelico wrote:
On Sun, Dec 22, 2019 at 10:46 AM Greg Ewing wrote:
On 22/12/19 9:04 am, Soni L. wrote:
switch (op) {
[...]
case OP_TAILCALL: {
adjust_regs();
some_other_stuff();
/* fallthrough */
}
case OP_CALL: {
make_the_call_happen();
break;
}
}
Relying on fall-through in a switch is a micro-optimisation that
may help make things go faster in C, but not so much in Python,
so trying to find a literal translation is probably wrongheaded.
I would be inclined to separate it into two independent cases:
if op == OP_TAILCALL:
adjust_regs()
some_other_stuff()
elif op == OP_CALL:
adjust_regs()
some_other_stuff()
make_the_call_happen()
If the parts being duplicated are more than just one or two
calls as above, I would factor them out into a separate function.
(You have the translation backwards here; a tail call should do three
things while a non-tail call should do one.)
Or, if you want the two cases to continue to share code (which might be
desirable if the shared code was (a lot) longer than one line):
if op == OP_TAILCALL or op == OP_CALL:
if op == OP_TAILCALL:
adjust_regs()
some_other_stuff()
make_the_call_happen()
While there is a repeated test which might offend purists, IMO the
intent is clearer than the original "switch" version
where it is easy to overlook that execution is supposed to fall through.
IMO it is also clearer than "or if", though we wouldn't know for sure
until/unless "or if"
was adopted in Python and we had had time to get used to it.
Rob Cliffe
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GNZM326BHAENXVZYKFJ2S3DEMOLYWFCD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Is the deployment standard for WSGI ready?
The PEP index can be found at https://www.python.org/dev/peps/ and there isn't any PEP on this. But honestly, I don't think this sort of thing should be a PEP. Look at ASGI and how that isn't a PEP and still manages to exist. Since this isn't a language-related or package-related thing I don't think it really needs to go through the PEP process. On Mon, Jan 27, 2020 at 8:07 PM Jesús Gómez wrote: > In the PEP-[1] they say the following: > > """ > After a sufficient number of servers and frameworks have implemented WSGI > to provide field experience with varying deployment requirements, it may > make sense to create another PEP, describing a deployment standard for WSGI > servers and application frameworks. > """ > > Did this happen already? Will this happen anytime? > > [1] https://www.python.org/dev/peps/pep-/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/SMT3VZKF6KVHJDRVD2OVPN5EMPN4RDCT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NAZB76QHU367T6Z63DMFI3Y3YATARNKJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Is the deployment standard for WSGI ready?
It's worth noting that I was discouraged from making ASGI a PEP by several Python core developers, which is why I have not been pursuing that process any further. I'm not sure I share this view, so I may come back to it in the future, but there's a reason it's not in the process right now. As for the deployment format - I feel like the presence of Docker and other deployment formats that are not Python specific has aged that part of the original PEP somewhat. I'm not sure we would even be able to back one. Andrew On Tue, Jan 28, 2020 at 12:18 PM M.-A. Lemburg wrote: > WSGI and ASGI are similar to the Python DB-API, in the sense that they > define a standard Python API. The DB-API uses > > Type: Informational > > for this purpose; and yes, it doesn't go through the standard > PEP process, but instead is discussed and finalized by a SIG. > > Since WSGI and (probably soon) ASGI are very common API standards > in Python land, they deserve to go into the PEP index as well, IMO. > > > On 28.01.2020 19:45, Brett Cannon wrote: > > The PEP index can be found at https://www.python.org/dev/peps/ and there > > isn't any PEP on this. > > > > But honestly, I don't think this sort of thing should be a PEP. Look at > > ASGI and how that isn't a PEP and still manages to exist. Since this > isn't > > a language-related or package-related thing I don't think it really needs > > to go through the PEP process. > > > > On Mon, Jan 27, 2020 at 8:07 PM Jesús Gómez wrote: > > > >> In the PEP-[1] they say the following: > >> > >> """ > >> After a sufficient number of servers and frameworks have implemented > WSGI > >> to provide field experience with varying deployment requirements, it may > >> make sense to create another PEP, describing a deployment standard for > WSGI > >> servers and application frameworks. > >> """ > >> > >> Did this happen already? Will this happen anytime? > >> > >> [1] https://www.python.org/dev/peps/pep-/ > >> ___ > >> Python-ideas mailing list -- python-ideas@python.org > >> To unsubscribe send an email to python-ideas-le...@python.org > >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ > >> Message archived at > >> > https://mail.python.org/archives/list/python-ideas@python.org/message/SMT3VZKF6KVHJDRVD2OVPN5EMPN4RDCT/ > >> Code of Conduct: http://python.org/psf/codeofconduct/ > >> > > > > > > > > ___ > > Python-ideas mailing list -- python-ideas@python.org > > To unsubscribe send an email to python-ideas-le...@python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/NAZB76QHU367T6Z63DMFI3Y3YATARNKJ/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Jan 28 2020) > >>> Python Projects, Coaching and Support ...https://www.egenix.com/ > >>> Python Product Development ...https://consulting.egenix.com/ > > > ::: We implement business ideas - efficiently in both time and costs ::: > >eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >Registered at Amtsgericht Duesseldorf: HRB 46611 >https://www.egenix.com/company/contact/ > https://www.malemburg.com/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/UG72RPTHF7MHT3VGOKSBV3BUP7XAY6OY/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KUVMWNGI6ZLIWLIYESP6IY6VJKX5EZCB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Is the deployment standard for WSGI ready?
WSGI and ASGI are similar to the Python DB-API, in the sense that they define a standard Python API. The DB-API uses Type: Informational for this purpose; and yes, it doesn't go through the standard PEP process, but instead is discussed and finalized by a SIG. Since WSGI and (probably soon) ASGI are very common API standards in Python land, they deserve to go into the PEP index as well, IMO. On 28.01.2020 19:45, Brett Cannon wrote: > The PEP index can be found at https://www.python.org/dev/peps/ and there > isn't any PEP on this. > > But honestly, I don't think this sort of thing should be a PEP. Look at > ASGI and how that isn't a PEP and still manages to exist. Since this isn't > a language-related or package-related thing I don't think it really needs > to go through the PEP process. > > On Mon, Jan 27, 2020 at 8:07 PM Jesús Gómez wrote: > >> In the PEP-[1] they say the following: >> >> """ >> After a sufficient number of servers and frameworks have implemented WSGI >> to provide field experience with varying deployment requirements, it may >> make sense to create another PEP, describing a deployment standard for WSGI >> servers and application frameworks. >> """ >> >> Did this happen already? Will this happen anytime? >> >> [1] https://www.python.org/dev/peps/pep-/ >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/SMT3VZKF6KVHJDRVD2OVPN5EMPN4RDCT/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/NAZB76QHU367T6Z63DMFI3Y3YATARNKJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 28 2020) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UG72RPTHF7MHT3VGOKSBV3BUP7XAY6OY/ Code of Conduct: http://python.org/psf/codeofconduct/
