Trac coding style question
30 views
Skip to first unread message
RjOllos
May 11, 2014, 11:00:47 PM5/11/14
to trac...@googlegroups.com
I've been wondering if we had a consensus, or could reach one on the following very minor coding style issue. When a tuple is returned in a "return" or "yield" statement, the parenthesis are optional. In the Trac codebase there isn't a consistent pattern of choosing one pattern. I tend to prefer the minimal approach of omitting the parenthesis.
I was hoping to add a rule to http://trac.edgewall.org/wiki/TracDev/CodingStyle.
I was hoping to add a rule to http://trac.edgewall.org/wiki/TracDev/CodingStyle.
anatoly techtonik
May 12, 2014, 3:33:55 AM5/12/14
to trac...@googlegroups.com
How about readability for people from other languages? They will need
to Google for comma, which is hard.
> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to trac-dev+u...@googlegroups.com.
> To post to this group, send email to trac...@googlegroups.com.
> Visit this group at http://groups.google.com/group/trac-dev.
> For more options, visit https://groups.google.com/d/optout.
--
anatoly t.
to Google for comma, which is hard.
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to trac-dev+u...@googlegroups.com.
> To post to this group, send email to trac...@googlegroups.com.
> Visit this group at http://groups.google.com/group/trac-dev.
> For more options, visit https://groups.google.com/d/optout.
--
anatoly t.
Christopher Nelson
May 12, 2014, 7:47:45 AM5/12/14
to trac...@googlegroups.com
On Sun, May 11, 2014 at 11:00 PM, RjOllos <rjo...@gmail.com> wrote:
> I've been wondering if we had a consensus, or could reach one on the
> following very minor coding style issue. When a tuple is returned in a
> "return" or "yield" statement, the parenthesis are optional. In the Trac
> codebase there isn't a consistent pattern of choosing one pattern. I tend to
> prefer the minimal approach of omitting the parenthesis.
Can you show an example of each style here so we can comment on them?
> I've been wondering if we had a consensus, or could reach one on the
> following very minor coding style issue. When a tuple is returned in a
> "return" or "yield" statement, the parenthesis are optional. In the Trac
> codebase there isn't a consistent pattern of choosing one pattern. I tend to
> prefer the minimal approach of omitting the parenthesis.
Steffen Hoffmann
May 12, 2014, 2:03:47 PM5/12/14
to trac...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Consider the following:
def explicit_tuple(invalue):
# Some useless algorithm computing output.
# ...
outvalue1 = 1
outvalue1 = 2
return (outvalue1, outvalue2)
def implicit_tuple(invalue):
# Some useless algorithm computing output.
# ...
outvalue1 = 1
outvalue1 = 2
return outvalue1, outvalue2
As Ryan pointed out, the return value is a tuple in both cases.
Sincerely,
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlNxDP4ACgkQ31DJeiZFuHfUqQCgwV+SViLu9kjGALjKfZMdmYm9
oX8AoM2Whbcnh+cpjAZP4gAXE1peQDEc
=+rTk
-----END PGP SIGNATURE-----
Hash: SHA1
def explicit_tuple(invalue):
# Some useless algorithm computing output.
# ...
outvalue1 = 1
outvalue1 = 2
return (outvalue1, outvalue2)
def implicit_tuple(invalue):
# Some useless algorithm computing output.
# ...
outvalue1 = 1
outvalue1 = 2
return outvalue1, outvalue2
As Ryan pointed out, the return value is a tuple in both cases.
Sincerely,
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlNxDP4ACgkQ31DJeiZFuHfUqQCgwV+SViLu9kjGALjKfZMdmYm9
oX8AoM2Whbcnh+cpjAZP4gAXE1peQDEc
=+rTk
-----END PGP SIGNATURE-----
Christopher Nelson
May 12, 2014, 2:11:07 PM5/12/14
to trac...@googlegroups.com
On Mon, May 12, 2014 at 2:03 PM, Steffen Hoffmann <hof...@web.de> wrote:
> On 12.05.2014 13:47, Christopher Nelson wrote:
>> Can you show an example of each style here so we can comment on them?
>
> Consider the following:
>
> def explicit_tuple(invalue):
> # Some useless algorithm computing output.
> # ...
> outvalue1 = 1
> outvalue1 = 2
outvalue2 = 2?
> On 12.05.2014 13:47, Christopher Nelson wrote:
>> Can you show an example of each style here so we can comment on them?
>
> Consider the following:
>
> def explicit_tuple(invalue):
> # Some useless algorithm computing output.
> # ...
> outvalue1 = 1
> outvalue1 = 2
> return (outvalue1, outvalue2)
>
>
> def implicit_tuple(invalue):
> # Some useless algorithm computing output.
> # ...
> outvalue1 = 1
> outvalue1 = 2
> return outvalue1, outvalue2
>
> As Ryan pointed out, the return value is a tuple in both cases.
Steffen Hoffmann
May 13, 2014, 12:29:48 AM5/13/14
to trac...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On 12.05.2014 20:11, Christopher Nelson wrote:
> On Mon, May 12, 2014 at 2:03 PM, Steffen Hoffmann <hof...@web.de>
> wrote:
>> outvalue1 = 1 outvalue1 = 2
>
> outvalue2 = 2?
Sure, just a lazy copy-n-paste, sorry.
> On Mon, May 12, 2014 at 2:03 PM, Steffen Hoffmann <hof...@web.de>
> wrote:
>> outvalue1 = 1 outvalue1 = 2
>
> outvalue2 = 2?
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
dEoAn0/uW2cYp8ioDirNY1Ivubv3BL/Q
=A0BR
-----END PGP SIGNATURE-----
Steffen Hoffmann
May 14, 2014, 4:56:39 PM5/14/14
to trac...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On 12.05.2014 09:33, anatoly techtonik wrote:
> On Mon, May 12, 2014 at 6:00 AM, RjOllos <rjo...@gmail.com> wrote:
>> I've been wondering if we had a consensus, or could reach one on the
>> following very minor coding style issue. When a tuple is returned in a
>> "return" or "yield" statement, the parenthesis are optional. In the Trac
>> codebase there isn't a consistent pattern of choosing one pattern. I tend to
>> prefer the minimal approach of omitting the parenthesis.
>>
>> I was hoping to add a rule to
>> http://trac.edgewall.org/wiki/TracDev/CodingStyle.
>
> How about readability for people from other languages? They will need
> to Google for comma, which is hard.
Yes, personally I lean towards explicit rather than implicit too. I
> On Mon, May 12, 2014 at 6:00 AM, RjOllos <rjo...@gmail.com> wrote:
>> I've been wondering if we had a consensus, or could reach one on the
>> following very minor coding style issue. When a tuple is returned in a
>> "return" or "yield" statement, the parenthesis are optional. In the Trac
>> codebase there isn't a consistent pattern of choosing one pattern. I tend to
>> prefer the minimal approach of omitting the parenthesis.
>>
>> I was hoping to add a rule to
>> http://trac.edgewall.org/wiki/TracDev/CodingStyle.
>
> How about readability for people from other languages? They will need
> to Google for comma, which is hard.
remember having a hard time to understand this implicit return object
type definition on my own.
Not seen a decent documentation on in yet, but I did not look too much
for it either. Maybe due to not knowing a good keyword, what would be
further indication, that Anatoly is right with that assertion.
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
mC4AoJ8tMrQOn09985S7K9g4TUIeupHT
=BCKc
-----END PGP SIGNATURE-----
Christian Boos
May 17, 2014, 5:55:47 AM5/17/14
to trac...@googlegroups.com
Hello Ryan,
On 2014-05-12 5:00 AM, RjOllos wrote:
> I've been wondering if we had a consensus, or could reach one on the
> following very minor coding style issue. When a tuple is returned in a
> "return" or "yield" statement, the parenthesis are optional. In the Trac
> codebase there isn't a consistent pattern of choosing one pattern. I
> tend to prefer the minimal approach of omitting the parenthesis.
>
Same for me. The valid use for using parentheses in return statements
would be for dealing with line continuations, but other than that for
multiple return values I prefer to be concise and omit them, it simply
looks nicer and more idiomatic.
You also wouldn't use an explicit tuple here:
a, b, c = c, b, a
or here:
z = [x + y for x, y in pairs]
And though we're not consistent in the Trac code base, I counted 171
"return ...," vs. 64 "return (...,". And below my Python/Lib/ the ratio
was even more pronounced towards that style (4/1).
-- Christian
On 2014-05-12 5:00 AM, RjOllos wrote:
> I've been wondering if we had a consensus, or could reach one on the
> following very minor coding style issue. When a tuple is returned in a
> "return" or "yield" statement, the parenthesis are optional. In the Trac
> codebase there isn't a consistent pattern of choosing one pattern. I
> tend to prefer the minimal approach of omitting the parenthesis.
>
would be for dealing with line continuations, but other than that for
multiple return values I prefer to be concise and omit them, it simply
looks nicer and more idiomatic.
You also wouldn't use an explicit tuple here:
a, b, c = c, b, a
or here:
z = [x + y for x, y in pairs]
And though we're not consistent in the Trac code base, I counted 171
"return ...," vs. 64 "return (...,". And below my Python/Lib/ the ratio
was even more pronounced towards that style (4/1).
-- Christian
RjOllos
Dec 3, 2014, 9:46:27 AM12/3/14
to trac...@googlegroups.com
Some time ago I added a note to the CodingStyle page, but forgot to followup here:
I like that we aim to be PEP-0008 compliant and prefer idiomatic Python. With regard to the point of people coming from other languages, they should learn idiomatic Python if they'll be Trac contributors, and we'll help them improve their patches to that end ;)
Reply all
Reply to author
Forward
0 new messages