This is a definite tangent. Trailing commas are great for reducing git diffs, not making errors when moving things around (missing commas, which e.g. in strings causes concatenation) but I have often wondered whether the same could be extended to (some?) logical or arithmetic operators, in particular:
Currently one has to write a logical expression as (using Django Q objects): ( Q(user=user) | Q(is_deleted=True) ) and then removing/adding clauses is difficult, whereas if "trailing operators" where allowed, there would be no such issue: ( Q(user=user) | Q(is_deleted=True) | ) Just like with trailing commas, the "additional" operator would be ignored. I guess (technically) it won't have to match the previous operator, it could just be any operator with no argument after it. Unlike with trailing comma, I think an operator on its own would not be allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context dependent (e.g. in this example, the correct answer is a Q() object). I am happy to flesh this out more, but as this discussion was ongoing, I thought I would throw it out here and see what people think? Are there potential problems with this e.g. with parsing it? On Fri, 12 Mar 2021 at 14:28, Paul Bryan <pbr...@anode.ca> wrote: > It seems your proposal is intended to address an aesthetic concern. Is > there a case where using a leading comma would make something > actually easier or more intuitive to express over the use of trailing comma? > > On Fri, 2021-03-12 at 10:34 +0000, roland.puntaier--- via Python-ideas > wrote: > > I had posted this as https://github.com/python/peps/issues/1867 > The discussion so far is below. > > Please make some arguments. > > The major point to me is, that the symmetry is broken, > which leads to extra editing actions, like removing the comma in the first > line. > I guess, this was the reason to allow the comma after the last line/entry: > `[1,2,]`. > ``[,1,2]`` should also be allowed, too. > > The best argument is one that says: less or more effort in this or that > situation. > For example, with `[1,2,]`, in line-wise formatting, > one can do without special action at the last line (removing the comma > there). > > All code from previous versions of Python would still work > after a `[,1,2]` syntax allowance were introduced. > > > > ================================================================================= > rpuntaie wrote: > > ================================================================================= > > Allow initial comma > =================== > > Final comma works: > > t = ( > 1, > 2, > ) > x = [ > 1, > 2, > ] > y = { > 1, > 2, > } > z = { > 1:11, > 2:22, > } > def fun( > a, > b, > ): > pass > > Initial comma does not work: > > t = ( > , 1 > , 2 > ) > x = [ > , 1 > , 2 > ] > y = { > , 1 > , 2 > } > z = { > , 1:11 > , 2:22 > } > def fun( > , a > , b > ): > pass > > > To make the syntax symmetric in this regard\ > gives more freedom to format the code. > > I occasionally found the restriction an unnecessary nuisance. > > Before writing a PEP, I would like to discuss, > > - whether something like that has been proposed already? > - what counter-arguments there could be? > > > ================================================================================= > pxeger wrote: > > ================================================================================= > > This is not the appropriate place to propose language changes. > Try the [python-ideas]( > https://mail.python.org/mailman3/lists/python-ideas.python.org/) > mailing list. However, I don't think you'll get anyone to agree. > > What kind of code style are you using where you want to put commas at > the start of the line? That is totally non-standard > (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and > confusing. > > Arbitrary symmetry is not a good reason for changing the language. We > don't have a `tnirp` function just for the sake of symmetry with > `print` because it would be pointless and add extra complication > > > > ================================================================================= > rpuntaie wrote: > > ================================================================================= > > I surely agree, that not ignoring the sequence is essential. Else one > would loose identifier space and thus information. I would never have > the idea to make all permutations of `p.r.i.n.t` point to the same > function. Therefore you just made a bad example. > > But the comma is just a separator. Why did they allow to have the > comma before a closing bracket/parenthesis/brace? Because of symmetry > between lines, is my guess. > > Occasionally one sees many spaces just the have the final comma > aligned vertically. That could be avoided by placing the comma at the > beginning. > > I personally also have a macro in the editor that evaluates a line in > the parameter list, but drops an initial comma before doing that. > Therefore this is my preferred formatting. > > I don't think that [PEP](https://www.python.org/dev/peps/pep-0008) > is wrong. I just don't want to be restricted by unnecessary rules. > Rules need to have a reason beyond someone dictating them. If that is > the case, I follow them, because I see the reason, but not because > someone dictates them. > > I'll go to > [Python Ide as]( > https://mail.python.org/mailman3/lists/python-ideas.python.org/), > then. Thanks. > _______________________________________________ > 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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/ > 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/2QJC6ASRWGWIFT7GKDAOTZHFTO5GGMLE/ > 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/25CCMH44AERGVPU3VJBMNFZXT4J6TYMB/ Code of Conduct: http://python.org/psf/codeofconduct/