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 <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-ideas mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/2QJC6ASRWGWIFT7GKDAOTZHFTO5GGMLE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/25CCMH44AERGVPU3VJBMNFZXT4J6TYMB/
Code of Conduct: http://python.org/psf/codeofconduct/
