Simple solution for trailing | is put False on the next line.
> On Mar 12, 2021, at 12:07 PM, Henk-Jaap Wagenaar <wagenaarhenkj...@gmail.com> > wrote: > > > 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/
_______________________________________________ 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/BXGAJM4N73EHMIOV3BFEKEJ3ZEZNC3AZ/ Code of Conduct: http://python.org/psf/codeofconduct/
