On 06/06/2017 05:30 PM, Barry Warsaw wrote:
On Jun 05, 2017, at 08:19 AM, Ethan Furman wrote:
I would format that as:
if (PyErr_WarnFormat(
PyExc_DeprecationWarning,
1,
"invalid escape sequence '\\%c'",
*first_i
On 07/06/2017 01:30, Barry Warsaw wrote:
On Jun 05, 2017, at 08:41 AM, Serhiy Storchaka wrote:
the example above), and the following code is enough readable:
if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,
"invalid escape sequence '\\%c'",
On Jun 05, 2017, at 07:00 AM, Skip Montanaro wrote:
>Wow, this discussion takes me back. Glad I don't have to check out
>comp.lang.c to get my brace placement fix.
Life is better without braces!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
On Jun 05, 2017, at 08:41 AM, Serhiy Storchaka wrote:
>the example above), and the following code is enough readable:
>
> if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,
> "invalid escape sequence '\\%c'",
> *first_invalid_escape)
On 2017-06-05 13:00, Skip Montanaro wrote:
On Mon, Jun 5, 2017 at 12:41 AM, Serhiy Storchaka wrote:
Barry and Victor prefer moving a brace on a new line in all multiline
conditional cases. I think that it should be done only when the condition
continuation lines and the following block of the c
if (PyErr_WarnFormat(PyExc_DeprecationWarning, 1,
"invalid escape sequence '\\%c'",
*first_invalid_escape) < 0) {
Py_DECREF(result);
return NULL;
}
What other core developers think about this?
On Mon, Jun 5, 2017 at 12:41 AM, Serhiy Storchaka wrote:
> Barry and Victor prefer moving a brace on a new line in all multiline
> conditional cases. I think that it should be done only when the condition
> continuation lines and the following block of the code have the same
> indentation (as in t
Serhiy Storchaka schrieb am 03.06.2017 um 18:25:
> Yet about braces. PEP 7 implicitly forbids breaking the line before an
> opening brace. An opening brace should stay at the end the line of the
> outer compound statement.
>
> if (mro != NULL) {
> ...
> }
> else {
> ...
03.06.17 23:30, Barry Warsaw пише:
On Jun 03, 2017, at 07:25 PM, Serhiy Storchaka wrote:
But the latter example continuation lines are intended at the same level as
the following block of code. I propose to make exception for that case and
allow moving an open brace to the start of the next lin
On Jun 03, 2017, at 07:25 PM, Serhiy Storchaka wrote:
>But the latter example continuation lines are intended at the same level as
>the following block of code. I propose to make exception for that case and
>allow moving an open brace to the start of the next line.
>
> if (type->tp_dictoffset
Yet about braces. PEP 7 implicitly forbids breaking the line before an
opening brace. An opening brace should stay at the end the line of the
outer compound statement.
if (mro != NULL) {
...
}
else {
...
}
if (type->tp_dictoffset != 0 && base->tp_dictoffset
https://github.com/python/peps/pull/280/files
On Jun 01, 2017, at 09:08 PM, Brett Cannon wrote:
>If you create an issue at github.com/python/peps and assign it to me I will
>get to it someday. :)
pgpqhM6HQldC5.pgp
Description: OpenPGP digital signature
__
If you create an issue at github.com/python/peps and assign it to me I will
get to it someday. :)
On Thu, 1 Jun 2017 at 00:19 Victor Stinner wrote:
> 2017-05-31 19:27 GMT+02:00 Guido van Rossum :
> > I interpret the PEP (...)
>
> Right, the phrasing requires to "interpret" it :-)
>
> > (...) as
2017-05-31 19:27 GMT+02:00 Guido van Rossum :
> I interpret the PEP (...)
Right, the phrasing requires to "interpret" it :-)
> (...) as saying that you should use braces everywhere but not
> to add them in code that you're not modifying otherwise. (I.e. don't go on a
> brace-adding rampage.) If a
01.06.17 09:36, Benjamin Peterson пише:
Modern GCC can defend against these kinds of problems. If I introduce a
"goto fail" bug somewhere in Python, I get a nice warning:
../Objects/abstract.c: In function ‘PyObject_Type’:
../Objects/abstract.c:35:5: warning: this ‘if’ clause does not guard...
[-
31.05.17 20:27, Guido van Rossum пише:
I interpret the PEP as saying that you should use braces everywhere but
not to add them in code that you're not modifying otherwise. (I.e. don't
go on a brace-adding rampage.) If author and reviewer of a PR disagree I
would go with "add braces" since that'
Modern GCC can defend against these kinds of problems. If I introduce a
"goto fail" bug somewhere in Python, I get a nice warning:
../Objects/abstract.c: In function ‘PyObject_Type’:
../Objects/abstract.c:35:5: warning: this ‘if’ clause does not guard...
[-Wmisleading-indentation]
if (o == NUL
Seems like a good idea to tighten it up.
If a style guide is going to say "you can either do X or
not do X", it might as well not mention X at all. :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
I interpret the PEP as saying that you should use braces everywhere but not
to add them in code that you're not modifying otherwise. (I.e. don't go on
a brace-adding rampage.) If author and reviewer of a PR disagree I would go
with "add braces" since that's clearly the PEP's preference. This is C
c
31.05.17 17:11, Victor Stinner пише:
I have a question on the CPython coding code for C code, the PEP 7:
https://www.python.org/dev/peps/pep-0007/
"""
Code structure: (...); braces are strongly preferred but may be
omitted where C permits, and they should be formatted as shown:
if (mro != NULL)
the 'goto fail' bug is a somewhat extreme reminder for why such braces are
a good idea (as Victor said) -
https://www.imperialviolet.org/2014/02/22/applebug.html
On Wed, May 31, 2017 at 6:25 PM Paul Moore wrote:
> On 31 May 2017 at 15:11, Victor Stinner wrote:
> > So I would suggest to modify t
On 31 May 2017 at 15:11, Victor Stinner wrote:
> So I would suggest to modify the PEP 7 to *always* require braces for if.
>
> I would also suggest to require braces on "for(...) { ... }" and
> "while(...) { ... }". But only if the code has to be modified, not
> only to update the coding style.
>
On May 31, 2017, at 04:13 PM, Victor Stinner wrote:
>Previous discussion which added "strongly preferred" to the PEP 7, January
>2016: https://mail.python.org/pipermail/python-dev/2016-January/142746.html
I had to go back to make sure I wouldn't contradict myself. +1 then, +1
now for requiring b
Previous discussion which added "strongly preferred" to the PEP 7, January 2016:
https://mail.python.org/pipermail/python-dev/2016-January/142746.html
Victor
2017-05-31 16:11 GMT+02:00 Victor Stinner :
> Hi,
>
> I have a question on the CPython coding code for C code, the PEP 7:
> https://www.pyt
Hi,
I have a question on the CPython coding code for C code, the PEP 7:
https://www.python.org/dev/peps/pep-0007/
"""
Code structure: (...); braces are strongly preferred but may be
omitted where C permits, and they should be formatted as shown:
if (mro != NULL) {
...
}
else {
...
}
"""
25 matches
Mail list logo
