I did make the following arguments about less indentation in https://github.com/gvanrossum/patma/issues/59
To recap: 1. Similarity to if/elif/else and try/except/finally statements in how code lines up 2. Less apparent complexity, since indentation is a visual signal for such 3. Smaller, more meaningful diffs when refactoring if/elif/else chains Just to be clear, I wanted to capture these as possible objections, I'm not greatly in favor of one indentation scheme or the other - there are good arguments for the indentation scheme of the current PEP (which it makes). - Jim On Fri, Jul 10, 2020 at 5:11 PM Paul Sokolovsky <pmis...@gmail.com> wrote: > Hello, > > On Sat, 11 Jul 2020 00:35:39 +0200 > Federico Salerno <salerno...@gmail.com> wrote: > > [] > > > A few emails ago I proposed something like this (and I'm probably > > only the last one to do so amongst many), but if anyone made an > > argument against it I must have missed it: > > The PEP itself in "rejected" ideas makes an argument against it: > indented stuff after a line ending with ":" must be a *statement*. It > would be totally nuts for that to be something else, e.g. an expression: > > > > > match: > > a > > case 1: > > ... > > case 2: > > ... > > else: > > ... > > > (The a on a separate line being arguable.) > > That of course leads us to the obvious idea: > > match a: > case 1: > ... > case 2: > ... > else: > ... > > > Of course, PEP smartly has an argument against that too, in the vein of > "after line ending with ':', there should be an indent suite (list of > statements)". But that's where it goes sideways. That argument is no > better than the argument "there should be no normally looking > identifiers with magic behavior", but look, very this PEP does exactly > that with the identifier "_". > > And if the above snippet looks weird to anybody, it's only because of > all the "case" business. There wouldn't be such a problem if it was > instead: > > match a: > | 1: > ... > | 2: > ... > |: > ... > > The above ML-like syntax should be perfect for almost everyone, ... > except the PEP authors, because they have it in "rejected ideas" either. > > > -- > Best regards, > Paul mailto:pmis...@gmail.com > _______________________________________________ > 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/7V7BS3ICKE5PJZD5Q2I65ALZQNXROPZU/ > 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/Y652WIGSKSHOLV7YHIIXZWRK3MJOXDID/ Code of Conduct: http://python.org/psf/codeofconduct/
