On Wed, Apr 17, 2019 at 8:27 PM Victor Stinner wrote:
>
> AIX is somehow supported and uses xlc compiler: does xlc support this
> C11 feature?
I find Language Reference for v11.1 (2010/4/13)
https://www-01.ibm.com/support/docview.wss?uid=swg27017991
I find "anonymous union" in p73.
I can not fi
AIX is somehow supported and uses xlc compiler: does xlc support this
C11 feature?
Do you want to use it in Python 3.8 and newer only?
Victor
Le mer. 17 avr. 2019 à 13:14, Inada Naoki a écrit :
>
> Hi, all.
>
> PEP 7 includes some C99 features.
> I propose to add include anonymous union and str
Hi, all.
PEP 7 includes some C99 features.
I propose to add include anonymous union and struct to the list.
https://www.geeksforgeeks.org/g-fact-38-anonymous-union-and-structure/
Anonymous union and struct are C11 feature, not C99.
But gcc and MSVC supported it as language extension from before C
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 {
...
}
"""
https://github.com/python/peps/issues/176 is tracking the need to update
the PEP.
On Tue, 10 Jan 2017 at 23:45 Benjamin Peterson wrote:
> Your assumption is correct. Perhaps the PEP 7 should be partitioned into
> "< 3.6" and "3.6" sections where applicable.
>
> On Mon, Jan 9, 2017, at 12:50, Bre
Your assumption is correct. Perhaps the PEP 7 should be partitioned into
"< 3.6" and "3.6" sections where applicable.
On Mon, Jan 9, 2017, at 12:50, Brett Cannon wrote:
> https://bugs.python.org/issue29215 noticed that PEP 7 says "C++-style
> line
> comments" are allowed, but then later says "Neve
https://bugs.python.org/issue29215 noticed that PEP 7 says "C++-style line
comments" are allowed, but then later says "Never use C++ style // one-line
comments." I'm assuming we are sticking with allowing C++-style comments
and the "never" link just needs an addendum to say that only applies to
cod
On Fri, Mar 20, 2015 at 10:57 PM, Guido van Rossum wrote:
> Neil, you have no idea. Please back off.
I wouldn't go that far. Wanting a quality code base certainly isn't a
bad thing, but there's a lot more progress to be made by working with
what's there and being as mindful as possible of the gui
Neil, you have no idea. Please back off.
On Fri, Mar 20, 2015 at 8:02 PM, Neil Girdhar wrote:
> The code reviews I got asked me to revert PEP 7 changes. I can understand
> that, but then logically someone should go ahead and clean up the code.
> It's not "high risk" if you just check for whites
On Fri, Mar 20, 2015 at 10:02 PM, Neil Girdhar wrote:
> The code reviews I got asked me to revert PEP 7 changes. I can understand
> that, but then logically someone should go ahead and clean up the code.
> It's not "high risk" if you just check for whitespace equivalence of the
> source code and
The code reviews I got asked me to revert PEP 7 changes. I can understand
that, but then logically someone should go ahead and clean up the code.
It's not "high risk" if you just check for whitespace equivalence of the
source code and binary equivalence of the compiled code. The value is for
peop
On Fri, Mar 20, 2015 at 7:54 PM, Neil Girdhar wrote:
> If ever someone wants to clean up the repository to conform to PEP 7, I
> wrote a program that catches a couple hundred PEP 7 violations in ./Python
> alone (1400 in the whole codebase):
>
> import os
> import re
>
> def grep(path, regex):
>
If ever someone wants to clean up the repository to conform to PEP 7, I
wrote a program that catches a couple hundred PEP 7 violations in ./Python
alone (1400 in the whole codebase):
import os
import re
def grep(path, regex):
reg_obj = re.compile(regex, re.M)
res = []
for root, dirs,
On Wed, Jan 4, 2012 at 00:30, Stephen J. Turnbull wrote:
> Benjamin Peterson writes:
>
> > My goodness, I was trying to make a ridiculous-sounding proposition.
>
> In this kind of discussion, that's in the same class as "be careful
> what you wish for -- because you might just get it."
I wish we
Benjamin Peterson writes:
> My goodness, I was trying to make a ridiculous-sounding proposition.
In this kind of discussion, that's in the same class as "be careful
what you wish for -- because you might just get it."
___
Python-Dev mailing list
Python
2012/1/3 Stephen J. Turnbull :
> Benjamin Peterson writes:
> > Ethan Furman stoneleaf.us> writes:
> > >
> > > Readability also includes more than just the source code; as has already
> > > been stated:
>
> [diffs elided]
>
> > > I find the diff version that already had braces in place much mo
Benjamin Peterson writes:
> Ethan Furman stoneleaf.us> writes:
> >
> > Readability also includes more than just the source code; as has already
> > been stated:
[diffs elided]
> > I find the diff version that already had braces in place much more
> > readable.
>
> There are much larg
Ethan Furman stoneleaf.us> writes:
>
> Readability also includes more than just the source code; as has already
> been stated:
>
> if(cond) {
> stmt1;
> + stmt2;
> }
>
> vs.
>
> -if(cond)
> +if(cond) {
> stmt1;
> + stmt2;
> +}
>
> I find the diff version that already had braces
> Readability also includes more than just the source code; as has already
> been stated:
>
> if(cond) {
>stmt1;
> + stmt2;
> }
>
> vs.
>
> -if(cond)
> +if(cond) {
>stmt1;
> + stmt2;
> +}
>
> I find the diff version that already had braces in place much more
> readable.
Is it reall
"Stephen J. Turnbull" writes:
> Matt Joiner writes:
>
> > Readability is the highest concern, and this should be at the
> > discretion of the contributor.
>
> That's quite backwards. "Readability" is community property, and has
> as much, if not more, to do with common convention as with some
Stephen J. Turnbull wrote:
Matt Joiner writes:
> Readability is the highest concern, and this should be at the
> discretion of the contributor.
That's quite backwards. "Readability" is community property, and has
as much, if not more, to do with common convention as with some
absolute metric
Matt Joiner writes:
> Readability is the highest concern, and this should be at the
> discretion of the contributor.
That's quite backwards. "Readability" is community property, and has
as much, if not more, to do with common convention as with some
absolute metric. The "contributor's discret
FWIW I'm against forcing braces to be used. Readability is the highest
concern, and this should be at the discretion of the contributor. A
code formatting tool, or compiler extension is the only proper handle
this, and neither are in use or available.
On Tue, Jan 3, 2012 at 7:44 PM, "Martin v. Löw
> He keeps leaving them out, I occasionally tell him they should always
> be included (most recently this came up when we gave conflicting
> advice to a patch contributor). He says what he's doing is OK, because
> he doesn't consider the example in PEP 7 as explicitly disallowing it,
> I think it's
On Jan 02, 2012, at 02:08 PM, Guido van Rossum wrote:
>The irony is that style guides exist to *avoid* debates like this. Yes, the
>choices are arbitrary. Yes, tastes differ. Yes, there are exceptions to the
>rules. But still, once a style rule has been set, the idea is to stop
>debating and just
On Mon, Jan 2, 2012 at 4:27 PM, Nick Coghlan wrote:
> On Tue, Jan 3, 2012 at 8:32 AM, Raymond Hettinger
> wrote:
> > Running ``grep -B1 else Objects/*c`` shows that we've happily lived
> with a
> > mixture of styles for a very long time.
> > ISTM, our committers have had good instincts about wh
On 3 January 2012 09:55, Raymond Hettinger wrote:
>
> On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
>
> I'd also point out that if you're expecting braces, not having them can
> make the code less readable.
>
>
> If a programmer's mind explodes when they look at the simple and beautiful
> example
On Jan 2, 2012, at 4:27 PM, Nick Coghlan wrote:
> With my perception of the status quo corrected, I can stop worrying
> about preserving a non-existent consistency.
+1 QOTD
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
On Tue, Jan 3, 2012 at 8:32 AM, Raymond Hettinger
wrote:
> Running ``grep -B1 else Objects/*c`` shows that we've happily lived with a
> mixture of styles for a very long time.
> ISTM, our committers have had good instincts about when braces add clarity
> and when they add clutter.
> If Nick pushe
On Tue, Jan 3, 2012 at 12:54 AM, Benjamin Peterson wrote:
> I think it's fine Nick raised this. PEP 7 is not very explicit about
> braces at all.
I actually discovered in this thread that I've been misreading PEP 7
for going on 7 years now - I thought the brace usage example *did* use
"} else {"
On 1/2/2012 5:32 PM, Raymond Hettinger wrote:
Running ``grep -B1 else Objects/*c`` shows that we've happily lived
with a mixture of styles for a very long time.
ISTM, our committers have had good instincts about when braces add
clarity and when they add clutter.
If Nick pushes through an alwa
On Jan 2, 2012, at 2:09 PM, Tim Delaney wrote:
> I'd also point out that if you're expecting braces, not having them can make
> the code less readable.
If a programmer's mind explodes when they look at the simple and beautiful
examples in K&R's The C Programming Language, then they've got pro
On Jan 2, 2012, at 12:31 PM, Benjamin Peterson wrote:
> I might add that assuming you have braces, PEP 7 would want you to format it
> as
>
> if (cond) {
>statement;
> }
> else {
>more_stuff;
> }
>
Running ``grep -B1 else Objects/*c`` shows that we've happily lived with a
mixture o
On 3 January 2012 08:50, Larry Hastings wrote:
> On 01/02/2012 12:47 AM, Raymond Hettinger wrote:
>
>> Really? Do we need to have a brace war?
>> People have different preferences.
>> The standard library includes some of both styles
>> depending on what the maintainer thought was cleanest to th
On Mon, Jan 2, 2012 at 1:50 PM, Larry Hastings wrote:
> On 01/02/2012 12:47 AM, Raymond Hettinger wrote:
>
>> Really? Do we need to have a brace war?
>> People have different preferences.
>> The standard library includes some of both styles
>> depending on what the maintainer thought was cleanes
On 01/02/2012 12:47 AM, Raymond Hettinger wrote:
Really? Do we need to have a brace war?
People have different preferences.
The standard library includes some of both styles
depending on what the maintainer thought was cleanest to their eyes in a given
context.
I'm with Raymond. Code should
2012/1/1 Nick Coghlan :
>
> if (cond) {
> statement;
> } else {
> statement;
> }
I might add that assuming you have braces, PEP 7 would want you to format it as
if (cond) {
statement;
}
else {
more_stuff;
}
--
Regards,
Benjamin
___
P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/02/2012 01:02 AM, Nick Coghlan wrote:
> On Mon, Jan 2, 2012 at 3:04 PM, Scott Dial
> wrote:
>> On 1/1/2012 11:44 PM, Nick Coghlan wrote:
>>> I think it's a recipe for future maintenance hassles when someone
>>> adds a second statement to one of
2012/1/1 Nick Coghlan :
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
Python's C code has been dropping braces long before I ever arrived.
See this beautiful example in dictobject.c, for example:
if (numfree < PyDict_MAXFREELIST && Py_TYPE
On 1/1/2012 11:44 PM, Nick Coghlan wrote:
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
He keeps leaving them out, I occas
Antoine Pitrou wrote:
> I don't like having the else on the same line as the closing brace,
> and prefer:
>
>if (cond) {
>statement;
>}
>else {
>statement;
>}
And this is how it's written in PEP-7. It seems to me that PEP-7
doesn't require braces. But it explicitly
On Mon, 2 Jan 2012 14:44:49 +1000
Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
> statement;
> else
> statement;
>
> vs.
>
> if (cond) {
> statement;
> } else {
> statement;
> }
Go
On Mon, Jan 2, 2012 at 6:47 PM, Raymond Hettinger
wrote:
> Really? Do we need to have a brace war?
> People have different preferences.
> The standard library includes some of both styles
> depending on what the maintainer thought was cleanest to their eyes in a
> given context.
If the answer i
On Jan 1, 2012, at 8:44 PM, Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
>statement;
> else
>statement;
>
> vs.
>
> if (cond) {
>statement;
> } else {
>statement;
> }
Really? Do we
On Mon, Jan 2, 2012 at 4:22 PM, Ron Adam wrote:
> The problem is only when an additional statement is added to the last
> block, not the preceding ones, as the compiler will complain about
> those. So I don't know how the 4 line example without braces is any
> worse than a 2 line if without brace
On Mon, 2012-01-02 at 14:44 +1000, Nick Coghlan wrote:
> I've been having an occasional argument with Benjamin regarding braces
> in 4-line if statements:
>
> if (cond)
> statement;
> else
> statement;
>
> vs.
>
> if (cond) {
> statement;
> } else {
> statement;
> }
>
On Mon, Jan 2, 2012 at 3:04 PM, Scott Dial
wrote:
> On 1/1/2012 11:44 PM, Nick Coghlan wrote:
>> I think it's a recipe for future maintenance hassles when someone adds
>> a second statement to one of the clauses but doesn't add the braces.
>> (The only time I consider it reasonable to leave out th
On 1/1/2012 11:44 PM, Nick Coghlan wrote:
> I think it's a recipe for future maintenance hassles when someone adds
> a second statement to one of the clauses but doesn't add the braces.
> (The only time I consider it reasonable to leave out the braces is for
> one liner if statements, where there's
Nick Coghlan writes:
> He keeps leaving [braces] out [when the block is a single statement],
> I occasionally tell him they should always be included (most recently
> this came up when we gave conflicting advice to a patch contributor).
As someone who has maintained his fair share of C code, I a
I've been having an occasional argument with Benjamin regarding braces
in 4-line if statements:
if (cond)
statement;
else
statement;
vs.
if (cond) {
statement;
} else {
statement;
}
He keeps leaving them out, I occasionally tell him they should always
be included (most
Feel free to look at Misc/Vim/python.vim and see if this works better
than what is already there.
On Wed, May 12, 2010 at 20:47, Trent Nelson wrote:
>
>> Does anyone know of a way to teach vim that C sources in a python checkout
>> should have 4-space indents without changing the defaults for oth
Does anyone know of a way to teach vim that C sources in a python checkout
should have 4-space indents without changing the defaults for other C files?
I use this in my vimrc:
""
" indentation: use detectindent plugi
Le mardi 11 mai 2010 à 16:44 -0700, Sridhar Ratnakumar a écrit :
> Nor did it break any of our ActivePython 2.7 (Python trunk) builds ...
> though I had to hand-edit the patches to use 4 spaces now. Will this
> untabification change be made to the `release2.6-maint` branch too?
It has already been
Nor did it break any of our ActivePython 2.7 (Python trunk) builds ... though I
had to hand-edit the patches to use 4 spaces now. Will this untabification
change be made to the `release2.6-maint` branch too?
-srid
On 2010-05-09, at 11:33 AM, Antoine Pitrou wrote:
>
> Hello,
>
> The untabific
On Mon, May 10, 2010 at 07:09, Ronald Oussoren wrote:
>
> On 9 May, 2010, at 20:33, Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > The untabification of C files didn't produce any noticeable problem on
> > the buildbots. I've updated PEP 7 with the mention that all C files
> > should be 4-space i
On 9 May, 2010, at 20:33, Antoine Pitrou wrote:
>
> Hello,
>
> The untabification of C files didn't produce any noticeable problem on
> the buildbots. I've updated PEP 7 with the mention that all C files
> should be 4-space indented, and removed the obsolete wording about
> some files being in
Hello,
The untabification of C files didn't produce any noticeable problem on
the buildbots. I've updated PEP 7 with the mention that all C files
should be 4-space indented, and removed the obsolete wording about
some files being indented with tabs.
Regards
Antoine.
_
81 matches
Mail list logo
