Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Barry Warsaw]

On Jan 17, 2016, at 07:10 PM, Brett Cannon wrote:

>Anyone object if I update PEP 7 to remove the optionality of curly braces
>in PEP 7?

+1 for requiring them everywhere, -1 for a wholesale reformatting of existing
code.  New code and significant refactoring/rewriting can adopt braces
everywhere.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Serhiy Storchaka]

On 17.01.16 21:10, Brett Cannon wrote:

While doing a review of http://bugs.python.org/review/26129/
 I asked to have curly braces put
around all `if` statement bodies. Serhiy pointed out that PEP 7 says
curly braces are optional:
https://www.python.org/dev/peps/pep-0007/#id5. I would like to change that.

My argument is to require them to prevent bugs like the one Apple made
with OpenSSL about two years ago:
https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the
curly braces is purely an aesthetic thing while leaving them out can
lead to actual bugs.

Anyone object if I update PEP 7 to remove the optionality of curly
braces in PEP 7?


I'm -0. The code without braces looks more clear. Especially if the body 
is one-line return, break, continue or goto statement. Sometimes it is 
appropriate to add an empty line after it for even larger clearness. On 
the other hand, there is no a precedence of bugs like the one Apple made 
in CPython sources. Mandatory braces *may be* will prevent hypothetical 
bug, but for sure make a lot of correct code harder to read.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[M.-A. Lemburg]

On 18.01.2016 08:00, Victor Stinner wrote:
> I like if without braces when the body is only one line, especially when
> there is no else block.

Same here.

Compilers warn about these things today, so I don't think
we need to go paranoid ;-)

> Victor
> 
> 
> Le dimanche 17 janvier 2016, Brett Cannon  a écrit :
> 
>> While doing a review of http://bugs.python.org/review/26129/ I asked to
>> have curly braces put around all `if` statement bodies. Serhiy pointed out
>> that PEP 7 says curly braces are optional:
>> https://www.python.org/dev/peps/pep-0007/#id5. I would like to change
>> that.
>>
>> My argument is to require them to prevent bugs like the one Apple made
>> with OpenSSL about two years ago:
>> https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the
>> curly braces is purely an aesthetic thing while leaving them out can lead
>> to actual bugs.
>>
>> Anyone object if I update PEP 7 to remove the optionality of curly braces
>> in PEP 7?


-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 18 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Andrew Barnert via Python-Dev]

On Jan 17, 2016, at 11:10, Brett Cannon  wrote:
> 
> While doing a review of http://bugs.python.org/review/26129/ I asked to have 
> curly braces put around all `if` statement bodies. Serhiy pointed out that 
> PEP 7 says curly braces are optional: 
> https://www.python.org/dev/peps/pep-0007/#id5. I would like to change that.
> 
> My argument is to require them to prevent bugs like the one Apple made with 
> OpenSSL about two years ago: 
> https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the curly 
> braces is purely an aesthetic thing while leaving them out can lead to actual 
> bugs.
> 
> Anyone object if I update PEP 7 to remove the optionality of curly braces in 
> PEP 7?

There are two ways you could do that.

The first is to just change "braces may be omitted where C permits, but when 
present, they should be formatted as follows" to something like "braces must 
not be omitted, and should be formatted as follows", changing one-liner tests 
into this:

if (!obj) {
return -1;
}

Alternatively, it could say something like "braces must not be omitted; when 
other C styles would use a braceless one-liner, a one-liner with braces should 
be used instead; otherwise, they should be formatted as follows", changing the 
same tests into:

if (!obj) { return -1; }

The first one is obviously a much bigger change in the formatting of actual 
code, even if it's a simpler change to the PEP. Is that what was intended?___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Nick Coghlan]

On 18 January 2016 at 05:10, Brett Cannon  wrote:
> While doing a review of http://bugs.python.org/review/26129/ I asked to have
> curly braces put around all `if` statement bodies. Serhiy pointed out that
> PEP 7 says curly braces are optional:
> https://www.python.org/dev/peps/pep-0007/#id5. I would like to change that.
>
> My argument is to require them to prevent bugs like the one Apple made with
> OpenSSL about two years ago:
> https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the curly
> braces is purely an aesthetic thing while leaving them out can lead to
> actual bugs.
>
> Anyone object if I update PEP 7 to remove the optionality of curly braces in
> PEP 7?

+1 from me, as I usually add them to code I'm editing anyway (I find
it too hard to read otherwise, especially when there's a long series
of them).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Larry Hastings]

On 01/17/2016 11:10 AM, Brett Cannon wrote:
Anyone object if I update PEP 7 to remove the optionality of curly 
braces in PEP 7?


I'm -1.  I don't like being forced to add the curly braces when the code 
is perfectly clear without them.  If this was a frequent problem then 
I'd put up with it, but I can't recall ever making this particular 
mistake myself or seeing it in CPython source.  It seems to me like a 
fix for a problem we don't have.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Maciej Szulik]

On Mon, Jan 18, 2016 at 9:59 AM, Larry Hastings  wrote:

>
>
> On 01/17/2016 11:10 AM, Brett Cannon wrote:
>
> Anyone object if I update PEP 7 to remove the optionality of curly braces
> in PEP 7?
>
>
> I'm -1.  I don't like being forced to add the curly braces when the code
> is perfectly clear without them.  If this was a frequent problem then I'd
> put up with it, but I can't recall ever making this particular mistake
> myself or seeing it in CPython source.  It seems to me like a fix for a
> problem we don't have.
>
>
I'm +1. We don't have that problem yet and the idea Brett brought up is for
future changes that will happen.
We'll be soon moving to github, which should simplify the process of
submitting PRs from other developers
interested in making our beautiful language even more awesome. I'm quite
positive that with current review
process that kind of bug should not happen, but you never know. Having this
as a requirement is rather to
minimize the risk of potentially having such bugs. I've switched to this
style myself good couple years ago
and I find it very readable atm.

Maciej


*/arry*
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/soltysh%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Serhiy Storchaka]

On 18.01.16 13:42, Maciej Szulik wrote:

We'll be soon moving to github, which should simplify the process of
submitting PRs from other developers
interested in making our beautiful language even more awesome. I'm quite
positive that with current review
process that kind of bug should not happen, but you never know.


If moving to GitHub will decrease the quality of source code, it is bad 
idea.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Chris Angelico]

On Mon, Jan 18, 2016 at 10:42 PM, Maciej Szulik  wrote:
> On Mon, Jan 18, 2016 at 9:59 AM, Larry Hastings  wrote:
>>
>>
>>
>> On 01/17/2016 11:10 AM, Brett Cannon wrote:
>>
>> Anyone object if I update PEP 7 to remove the optionality of curly braces
>> in PEP 7?
>>
>>
>> I'm -1.  I don't like being forced to add the curly braces when the code
>> is perfectly clear without them.  If this was a frequent problem then I'd
>> put up with it, but I can't recall ever making this particular mistake
>> myself or seeing it in CPython source.  It seems to me like a fix for a
>> problem we don't have.
>>
>
> I'm +1. We don't have that problem yet and the idea Brett brought up is for
> future changes that will happen.
> We'll be soon moving to github, which should simplify the process of
> submitting PRs from other developers
> interested in making our beautiful language even more awesome. I'm quite
> positive that with current review
> process that kind of bug should not happen, but you never know. Having this
> as a requirement is rather to
> minimize the risk of potentially having such bugs. I've switched to this
> style myself good couple years ago
> and I find it very readable atm.

Rather than forcing people to use braces, wouldn't it be easier to
just add a linter to the toolchain that will detect those kinds of
problems and reject the commit? Which might be as simple as telling a
compiler to treat this warning as an error, and then always use that
compiler at some point before committing. (I don't know how many
compilers can check this.) I'm -1 on forcing people to use a
particular style when a script could do the same job more reliably.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Chris Angelico]

On Mon, Jan 18, 2016 at 11:02 PM, Larry Hastings  wrote:
> On 01/18/2016 03:57 AM, Chris Angelico wrote:
>
> Rather than forcing people to use braces, wouldn't it be easier to
> just add a linter to the toolchain that will detect those kinds of
> problems and reject the commit?
>
>
> I don't understand your suggestion.  If we automatically reject commits that
> lack this style of braces, then surely we are "forcing people to use
> [them]"?

Only in the exact situation that this is trying to prevent, where
indentation implies something that braces don't stipulate. From the
original Apple bug link:

if ((err = SSLHashSHA1.update(, )) != 0)
goto fail;
goto fail;

Since there are two indented lines after the if and no braces, this
should be flagged as an error. If there's only one indented line,
braces are optional.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Stefan Krah]

Brett Cannon  python.org> writes:
> Anyone object if I update PEP 7 to remove the optionality of curly braces
in PEP 7?

I strongly prefer braces everywhere, but I'm -1 on enforcing it.



Stefan Krah

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Larry Hastings]

On 01/18/2016 03:57 AM, Chris Angelico wrote:

Rather than forcing people to use braces, wouldn't it be easier to
just add a linter to the toolchain that will detect those kinds of
problems and reject the commit?


I don't understand your suggestion.  If we automatically reject commits 
that lack this style of braces, then surely we are "forcing people to 
use [them]"?



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

On Mon, 18 Jan 2016 at 04:05 Serhiy Storchaka  wrote:

> On 18.01.16 13:42, Maciej Szulik wrote:
> > We'll be soon moving to github, which should simplify the process of
> > submitting PRs from other developers
> > interested in making our beautiful language even more awesome. I'm quite
> > positive that with current review
> > process that kind of bug should not happen, but you never know.
>
> If moving to GitHub will decrease the quality of source code, it is bad
> idea.
>

It's not going to decrease code quality.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Yury Selivanov]

I'm usually fine with code like this:

if ( ... )
return

But when there is a multi-line 'else' clause, I just want to use braces 
for both 'if' and its 'else'.  So, for consistency, I'm +1 for 
recommending to use braces everywhere.


And +1 for requiring to use braces if one of the clauses of the 'if' 
statement is multi-line.


Yury

On 2016-01-17 2:10 PM, Brett Cannon wrote:
While doing a review of http://bugs.python.org/review/26129/ I asked 
to have curly braces put around all `if` statement bodies. Serhiy 
pointed out that PEP 7 says curly braces are optional: 
https://www.python.org/dev/peps/pep-0007/#id5. I would like to change 
that.


My argument is to require them to prevent bugs like the one Apple made 
with OpenSSL about two years ago: 
https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the 
curly braces is purely an aesthetic thing while leaving them out can 
lead to actual bugs.


Anyone object if I update PEP 7 to remove the optionality of curly 
braces in PEP 7?



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Terry Reedy]

On 1/18/2016 6:20 PM, Brett Cannon wrote:



On Sun, 17 Jan 2016 at 11:10 Brett Cannon > wrote:

While doing a review of http://bugs.python.org/review/26129/ I asked
to have curly braces put around all `if` statement bodies. Serhiy
pointed out that PEP 7 says curly braces are optional:
https://www.python.org/dev/peps/pep-0007/#id5. I would like to
change that.

My argument is to require them to prevent bugs like the one Apple
made with OpenSSL about two years ago:
https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping
the curly braces is purely an aesthetic thing while leaving them out
can lead to actual bugs.

Anyone object if I update PEP 7 to remove the optionality of curly
braces in PEP 7?


Currently this thread stands at:

+1
   Brett
   Ethan
   Robert
   Georg
   Nick
   Maciej Szulik
+0
   Guido
-0
   Serhiy
   MAL
-1
   Victor (maybe; didn't specifically vote)
   Larry
   Stefan


Though I don't write C anymore, I occasionally read our C sources.  I 
dislike mixed bracketing in a multiple clause if/else statement,  and 
would strongly recommend against that.  On the other hand, to my 
Python-trained eye, brackets for one line clauses are just noise.  +-0.


If coverity's scan does not flag the sort of misleading bug bait 
formatting that at least partly prompted this thread


if (a):
   b;
   c;

then I think we should find or write something that does and run it over 
existing code as well as patches.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

On Sun, 17 Jan 2016 at 11:10 Brett Cannon  wrote:

> While doing a review of http://bugs.python.org/review/26129/ I asked to
> have curly braces put around all `if` statement bodies. Serhiy pointed out
> that PEP 7 says curly braces are optional:
> https://www.python.org/dev/peps/pep-0007/#id5. I would like to change
> that.
>
> My argument is to require them to prevent bugs like the one Apple made
> with OpenSSL about two years ago:
> https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the
> curly braces is purely an aesthetic thing while leaving them out can lead
> to actual bugs.
>
> Anyone object if I update PEP 7 to remove the optionality of curly braces
> in PEP 7?
>

Currently this thread stands at:

+1
  Brett
  Ethan
  Robert
  Georg
  Nick
  Maciej Szulik
+0
  Guido
-0
  Serhiy
  MAL
-1
  Victor (maybe; didn't specifically vote)
  Larry
  Stefan
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Brett Cannon]

On Mon, 18 Jan 2016 at 00:59 Larry Hastings  wrote:

>
>
> On 01/17/2016 11:10 AM, Brett Cannon wrote:
>
> Anyone object if I update PEP 7 to remove the optionality of curly braces
> in PEP 7?
>
>
> I'm -1.  I don't like being forced to add the curly braces when the code
> is perfectly clear without them.
>

I'm going to assume you mean it is clearer without them, else I don't hear
an argument against beyond "I don't wanna".

For me, I don't see how::

  int x = do_something();
  if (x != 10)
return NULL;
  do_some_more();

is any clearer or more readable than::

  int x = do_something();
  if (x != 10) {
return NULL;
  }
  do_some_more();



> If this was a frequent problem then I'd put up with it, but I can't recall
> ever making this particular mistake myself or seeing it in CPython source.
> It seems to me like a fix for a problem we don't have.
>

I personally have come close to screwing up like this, but I caught it
before I put up a patch.

I honestly also prefer the consistency of just always using braces rather
than the sometimes rule we have. It isn't like C is a pretty, safe language
to begin with, so I would rather be consistent and avoid potential errors.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[MRAB]

On 2016-01-19 00:18:08, "Terry Reedy"  wrote:


On 1/18/2016 6:20 PM, Brett Cannon wrote:


On Sun, 17 Jan 2016 at 11:10 Brett Cannon > wrote:

While doing a review of http://bugs.python.org/review/26129/ I 
asked

to have curly braces put around all `if` statement bodies. Serhiy
pointed out that PEP 7 says curly braces are optional:
https://www.python.org/dev/peps/pep-0007/#id5. I would like to
change that.

My argument is to require them to prevent bugs like the one Apple
made with OpenSSL about two years ago:
https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping
the curly braces is purely an aesthetic thing while leaving them 
out

can lead to actual bugs.

Anyone object if I update PEP 7 to remove the optionality of curly
braces in PEP 7?


Currently this thread stands at:

+1
   Brett
   Ethan
   Robert
   Georg
   Nick
   Maciej Szulik
+0
   Guido
-0
   Serhiy
   MAL
-1
   Victor (maybe; didn't specifically vote)
   Larry
   Stefan


Though I don't write C anymore, I occasionally read our C sources.  I 
dislike mixed bracketing in a multiple clause if/else statement,  and 
would strongly recommend against that.  On the other hand, to my 
Python-trained eye, brackets for one line clauses are just noise.  +-0.


If coverity's scan does not flag the sort of misleading bug bait 
formatting that at least partly prompted this thread


if (a):
   b;
   c;

then I think we should find or write something that does and run it 
over existing code as well as patches.



I agree.

After all, how hard could it be? :-)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Greg Ewing]

Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical to 
oppose always using brackets for the development of *python*


If we were being *really* pythonic, we would write all
the C code without any braces at all, and feed it through
a filter that adds them based on indentation. End of
argument. :-)

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/18/2016 23:27, Greg Ewing wrote:

Brett Cannon wrote:

For me, I don't see how::

  if (x != 10)
return NULL;
  do_some_more();

is any clearer or more readable than::

  if (x != 10) {
return NULL;
  }
  do_some_more();


Maybe not for that piece of code on its own, but the version
with braces takes up one more line. Put a few of those together,
and you can't fit as much code on the screen. If it makes the
difference between being able to see e.g. the whole of a loop
at once vs. having to scroll up and down, it could make the
code as a whole harder to read.

When someone trying to make this argument in #python for Python code... 
the response is newlines are free.  Almost this entire thread has me 
confused - the arguments against are kind of hypocritical; You are 
developing a language with a built in design ethic, and ignoring those 
ethics while building the implementation itself.


Newlines are free, use them

Explicit > Implicit - Explicitly scope everything.

I am not a core developer, but I just kind of feel its hypocritical to 
oppose always using brackets for the development of *python*

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Greg Ewing]

Alexander Walters wrote:
When someone trying to make this argument in #python for Python code... 
the response is newlines are free.


Well, I disagree. I very rarely put blank lines in a function
in any language, because it makes it hard to scan the code
visually and pick out the beginnings of functions. So while
they may help readability locally, they hurt it globally.

If I find myself needing to put blank lines in a function in
order to make it readable, I take it as a sign that the
function ought to be split up into smaller functions.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Greg Ewing]

Brett Cannon wrote:

For me, I don't see how::

  if (x != 10)
return NULL;
  do_some_more();

is any clearer or more readable than::

  if (x != 10) {
return NULL;
  }
  do_some_more();


Maybe not for that piece of code on its own, but the version
with braces takes up one more line. Put a few of those together,
and you can't fit as much code on the screen. If it makes the
difference between being able to see e.g. the whole of a loop
at once vs. having to scroll up and down, it could make the
code as a whole harder to read.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Nick Coghlan]

On 19 January 2016 at 14:40, Alexander Walters  wrote:
>
>
> On 1/18/2016 23:27, Greg Ewing wrote:
>>
>> Brett Cannon wrote:
>>>
>>> For me, I don't see how::
>>>
>>>   if (x != 10)
>>> return NULL;
>>>   do_some_more();
>>>
>>> is any clearer or more readable than::
>>>
>>>   if (x != 10) {
>>> return NULL;
>>>   }
>>>   do_some_more();
>>
>>
>> Maybe not for that piece of code on its own, but the version
>> with braces takes up one more line. Put a few of those together,
>> and you can't fit as much code on the screen. If it makes the
>> difference between being able to see e.g. the whole of a loop
>> at once vs. having to scroll up and down, it could make the
>> code as a whole harder to read.
>>
> When someone trying to make this argument in #python for Python code... the
> response is newlines are free.  Almost this entire thread has me confused -
> the arguments against are kind of hypocritical; You are developing a
> language with a built in design ethic, and ignoring those ethics while
> building the implementation itself.

There are two conflicting code aesthetics at work here, and the
relevant one for the folks that prefer to avoid braces in C where they
can is:

>>> from __future__ import braces
  File "", line 1
SyntaxError: not a chance

So if we bring *Python* into the comparison, we can see it splits the
difference between the two C variants by omitting the closing brace
and replacing the opening brace with ":":

  x = do_something()
  if (x != 10):
return None
  do_some_more()

The additional "cost" of mandatory braces in C is thus more lines
containing only a single "}", while the benefit is simply not having
to think about the braceless variant as a possible alternative
spelling.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/19/2016 02:21, Larry Hastings wrote:


On 01/18/2016 08:40 PM, Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical 
to oppose always using brackets for the development of *python*


CPython isn't written in Python, it's written in C.  So we use C 
idioms, which naturally are different from Python idioms.




Yes, and always using brackets is an accepted C idiom (one of two, the 
other being only use brackets when you must).  Always using them is  
more in line with the spirit of python.



//arry/


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/19/2016 00:09, Greg Ewing wrote:

Alexander Walters wrote:
When someone trying to make this argument in #python for Python 
code... the response is newlines are free.


Well, I disagree. I very rarely put blank lines in a function
in any language, because it makes it hard to scan the code
visually and pick out the beginnings of functions. So while
they may help readability locally, they hurt it globally.

I find the opposite to be true when I work in C


If I find myself needing to put blank lines in a function in
order to make it readable, I take it as a sign that the
function ought to be split up into smaller functions.

 Well, maybe I should change my position based on this.  Any excuse 
to break code out into more functions... is usually the right idea.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Glenn Linderman]

On 1/18/2016 9:16 PM, Greg Ewing wrote:

Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical 
to oppose always using brackets for the development of *python*


If we were being *really* pythonic, we would write all
the C code without any braces at all, and feed it through
a filter that adds them based on indentation. End of
argument. :-)



No argument, an extension:  If we were being *really* pythonic, we would 
re-implement CPython in Python, with a Python-to-C option (Cython?), and 
then we wouldn't need to worry about using braces for block delimiters.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/19/2016 01:04, Glenn Linderman wrote:

On 1/18/2016 9:16 PM, Greg Ewing wrote:

Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical 
to oppose always using brackets for the development of *python*


If we were being *really* pythonic, we would write all
the C code without any braces at all, and feed it through
a filter that adds them based on indentation. End of
argument. :-)



No argument, an extension:  If we were being *really* pythonic, we 
would re-implement CPython in Python, with a Python-to-C option 
(Cython?), and then we wouldn't need to worry about using braces for 
block delimiters.

So what I can take away from this is pypy is the pythonic python.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Peter Ludemann via Python-Dev]

On 18 January 2016 at 23:25, Alexander Walters 
wrote:

>
>
> On 1/19/2016 02:21, Larry Hastings wrote:
>
>
> On 01/18/2016 08:40 PM, Alexander Walters wrote:
>
> I am not a core developer, but I just kind of feel its hypocritical to
> oppose always using brackets for the development of *python*
>
>
> CPython isn't written in Python, it's written in C.  So we use C idioms,
> which naturally are different from Python idioms.
>
>
> Yes, and always using brackets is an accepted C idiom (one of two, the
> other being only use brackets when you must).  Always using them is  more
> in line with the spirit of python.
>

​And in the spirit of safety, which I think is Brett's concern.
Yes, there are tools that could catch the Apple bug
, by catching
incorrect indentation. But if the rule is to *always* use braces, that just
feels safer. Even if it offends some people's ability to read everything at
one glance (my suggestion: use a smaller font or a larger screen; or
refactor the code so it isn't as big a chunk).

There's a fairly exhaustive list of styles here:
https://en.wikipedia.org/wiki/Indent_style
I'm sure that some of these have not been advocated in this thread.​



>
> */arry*
>
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/pludemann%40google.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Larry Hastings]

On 01/18/2016 08:40 PM, Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical to 
oppose always using brackets for the development of *python*


CPython isn't written in Python, it's written in C.  So we use C idioms, 
which naturally are different from Python idioms.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Georg Brandl]

On 01/19/2016 01:18 AM, Terry Reedy wrote:

> Though I don't write C anymore, I occasionally read our C sources.  I 
> dislike mixed bracketing in a multiple clause if/else statement,  and 
> would strongly recommend against that.  On the other hand, to my 
> Python-trained eye, brackets for one line clauses are just noise.  +-0.
> 
> If coverity's scan does not flag the sort of misleading bug bait 
> formatting that at least partly prompted this thread
> 
> if (a):
> b;
> c;
> 
> then I think we should find or write something that does and run it over 
> existing code as well as patches.

I don't know if static checkers care about whitespace and indentation in C;
it might be a very obvious thing to do for Python programmers, but maybe not
for C static checker developers :)

And probably with good reason, since whitespace isn't a consideration except
for nicely readable code, which many people (not talking about CPython here)
apparently don't care about, you'd have tons of spurious checker messages.

In many cases (especially error handling ones like "goto fail"), I expect the
checker to flag the error anyway, but for semantic reasons, not because of
whitespace.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] _PyThreadState_Current

[Maciej Fijalkowski]

seems to work thanks.

That said, I would love to have PyThreadState_Get equivalent that
would let me handle the NULL.

On Mon, Jan 18, 2016 at 9:31 PM, Maciej Fijalkowski  wrote:
> Good point
>
> On Mon, Jan 18, 2016 at 9:25 PM, Victor Stinner
>  wrote:
>> Hum, you can try to lie and define Py_BUILD_CORE?
>>
>> Victor
>>
>> 2016-01-18 21:18 GMT+01:00 Maciej Fijalkowski :
>>> Hi
>>>
>>> change in between 3.5.0 and 3.5.1 (hiding _PyThreadState_Current and
>>> pyatomic.h) broke vmprof. The problem is that as a profile, vmprof can
>>> really encounter _PyThreadState_Current being null, while crashing an
>>> interpreter is a bit not ideal in this case.
>>>
>>> Any chance, a) _PyThreadState_Current can be restored in visibility?
>>> b) can I get a better API to get it in case it can be NULL, but also
>>> in 3.5 (since it works in 3.5.0 and breaks in 3.5.1)
>>>
>>> Cheers,
>>> fijal
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: 
>>> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Victor Stinner]

Is someone opposed to this PEP 509?

The main complain was the change on the public Python API, but the PEP
doesn't change the Python API anymore.

I'm not aware of any remaining issue on this PEP.

Victor

2016-01-11 17:49 GMT+01:00 Victor Stinner :
> Hi,
>
> After a first round on python-ideas, here is the second version of my
> PEP. The main changes since the first version are that the dictionary
> version is no more exposed at the Python level and the field type now
> also has a size of 64-bit on 32-bit platforms.
>
> The PEP is part of a serie of 3 PEP adding an API to implement a
> static Python optimizer specializing functions with guards. The second
> PEP is currently discussed on python-ideas and I'm still working on
> the third PEP.
>
> Thanks to Red Hat for giving me time to experiment on this.
>
>
> HTML version:
> https://www.python.org/dev/peps/pep-0509/
>
>
> PEP: 509
> Title: Add a private version to dict
> Version: $Revision$
> Last-Modified: $Date$
> Author: Victor Stinner 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 4-January-2016
> Python-Version: 3.6
>
>
> Abstract
> 
>
> Add a new private version to builtin ``dict`` type, incremented at each
> change, to implement fast guards on namespaces.
>
>
> Rationale
> =
>
> In Python, the builtin ``dict`` type is used by many instructions. For
> example, the ``LOAD_GLOBAL`` instruction searchs for a variable in the
> global namespace, or in the builtins namespace (two dict lookups).
> Python uses ``dict`` for the builtins namespace, globals namespace, type
> namespaces, instance namespaces, etc. The local namespace (namespace of
> a function) is usually optimized to an array, but it can be a dict too.
>
> Python is hard to optimize because almost everything is mutable: builtin
> functions, function code, global variables, local variables, ... can be
> modified at runtime. Implementing optimizations respecting the Python
> semantics requires to detect when "something changes": we will call
> these checks "guards".
>
> The speedup of optimizations depends on the speed of guard checks. This
> PEP proposes to add a version to dictionaries to implement fast guards
> on namespaces.
>
> Dictionary lookups can be skipped if the version does not change which
> is the common case for most namespaces. The performance of a guard does
> not depend on the number of watched dictionary entries, complexity of
> O(1), if the dictionary version does not change.
>
> Example of optimization: copy the value of a global variable to function
> constants.  This optimization requires a guard on the global variable to
> check if it was modified. If the variable is modified, the variable must
> be loaded at runtime when the function is called, instead of using the
> constant.
>
> See the `PEP 510 -- Specialized functions with guards
> `_ for the concrete usage of
> guards to specialize functions and for the rationale on Python static
> optimizers.
>
>
> Guard example
> =
>
> Pseudo-code of an fast guard to check if a dictionary entry was modified
> (created, updated or deleted) using an hypothetical
> ``dict_get_version(dict)`` function::
>
> UNSET = object()
>
> class GuardDictKey:
> def __init__(self, dict, key):
> self.dict = dict
> self.key = key
> self.value = dict.get(key, UNSET)
> self.version = dict_get_version(dict)
>
> def check(self):
> """Return True if the dictionary entry did not changed."""
>
> # read the version field of the dict structure
> version = dict_get_version(self.dict)
> if version == self.version:
> # Fast-path: dictionary lookup avoided
> return True
>
> # lookup in the dictionary
> value = self.dict.get(self.key, UNSET)
> if value is self.value:
> # another key was modified:
> # cache the new dictionary version
> self.version = version
> return True
>
> # the key was modified
> return False
>
>
> Usage of the dict version
> =
>
> Specialized functions using guards
> --
>
> The `PEP 510 -- Specialized functions with guards
> `_ proposes an API to support
> specialized functions with guards. It allows to implement static
> optimizers for Python without breaking the Python semantics.
>
> Example of a static Python optimizer: the astoptimizer of the `FAT
> Python `_ project
> implements many optimizations which require guards on namespaces.
> Examples:
>
> * Call pure builtins: to replace ``len("abc")`` with ``3``, guards on
>   ``builtins.__dict__['len']`` and 

Re: [Python-Dev] _PyThreadState_Current

[Maciej Fijalkowski]

Good point

On Mon, Jan 18, 2016 at 9:25 PM, Victor Stinner
 wrote:
> Hum, you can try to lie and define Py_BUILD_CORE?
>
> Victor
>
> 2016-01-18 21:18 GMT+01:00 Maciej Fijalkowski :
>> Hi
>>
>> change in between 3.5.0 and 3.5.1 (hiding _PyThreadState_Current and
>> pyatomic.h) broke vmprof. The problem is that as a profile, vmprof can
>> really encounter _PyThreadState_Current being null, while crashing an
>> interpreter is a bit not ideal in this case.
>>
>> Any chance, a) _PyThreadState_Current can be restored in visibility?
>> b) can I get a better API to get it in case it can be NULL, but also
>> in 3.5 (since it works in 3.5.0 and breaks in 3.5.1)
>>
>> Cheers,
>> fijal
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 509: Add a private version to dict

[Barry Warsaw]

On Jan 18, 2016, at 11:43 PM, Victor Stinner wrote:

>Is someone opposed to this PEP 509?
>
>The main complain was the change on the public Python API, but the PEP
>doesn't change the Python API anymore.
>
>I'm not aware of any remaining issue on this PEP.

Have you done any performance analysis for a wide range of Python
applications?  Did you address my suggestion on python-ideas to make the new C
API optionally compiled in?

I still think this is maintenance and potential performance overhead we don't
want to commit to long term unless it enables significant optimization.  Since
you probably can't prove that without some experimentation, this API should be
provisional.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com