This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Fix a+b to a + b
Type: Stage:
Components: Documentation Versions: Python 3.0, Python 2.5.3, Python 3.1, Python 2.7, Python 2.6, Python 2.5
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: LambertDW, Retro, georg.brandl, gvanrossum, loewis, rhettinger
Priority: normal Keywords:

Created on 2008-12-13 00:53 by Retro, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg77705 - (view) Author: Boštjan Mejak (Retro) Date: 2008-12-13 00:53

Please visit the above link and see line 6 in the example code.

...         a, b = b, a+b

should be fixed to

...         a, b = b, a + b

because PEP 8 recommends to

- Use spaces around arithmetic operators:
        i = i + 1
msg77706 - (view) Author: Boštjan Mejak (Retro) Date: 2008-12-13 01:00
And please fix the code example mentioned in issue4648.

Line 4 has a little fix to be made:

...             print(n, 'equals', x, '*', n//x)

...             print(n, 'equals', x, '*', n // x)
msg77708 - (view) Author: David W. Lambert (LambertDW) Date: 2008-12-13 01:44
I do think your interpretation of PEP8 is overly strict.  Here's the 
source code of the first j interpreter.  (Ken Iverson)

typedef char C;typedef long I;
typedef struct a{I t,r,d[3],p[2];}*A;
#define P printf
#define R return
#define V1(f) A f(w)A w;
#define V2(f) A f(a,w)A a,w;
#define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
I *ma(n){R(I*)malloc(n*4);}mv(d,s,n)I *d,*s;{DO(n,d[i]=s[i]);}
tr(r,d)I *d;{I z=1;DO(r,z=z*d[i]);R z;}
A ga(t,r,d)I *d;{A z=(A)ma(5+tr(r,d));z->t=t,z->r=r,mv(z->d,d,r);
 R z;}
V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;}
V2(plus){I r=w->r,*d=w->d,n=tr(r,d);A z=ga(0,r,d);
 DO(n,z->p[i]=a->p[i]+w->p[i]);R z;}
V2(from){I r=w->r-1,*d=w->d+1,n=tr(r,d);
 A z=ga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;}
V1(box){A z=ga(1,0,0);*z->p=(I)w;R z;}
V2(cat){I an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn;
 A z=ga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;}
V2(rsh){I r=a->r?*a->d:1,n=tr(r,a->p),wn=tr(w->r,w->d);
 A z=ga(w->t,r,a->p);mv(z->p,w->p,wn=n>wn?wn:n);
 if(n-=wn)mv(z->p+wn,z->p,n);R z;}
V1(sha){A z=ga(0,1,&w->r);mv(z->p,w->d,w->r);R z;}
V1(id){R w;}V1(size){A z=ga(0,0,0);*z->p=w->r?*w->d:1;R z;}
pi(i){P("%d ",i);}nl(){P("\n");}
pr(w)A w;{I r=w->r,*d=w->d,n=tr(r,d);DO(r,pi(d[i]));nl();
 if(w->t)DO(n,P("< ");pr(w->p[i]))else DO(n,pi(w->p[i]));nl();}

C vt[]="+{~<#,";
I st[26]; qp(a){R  a>='a'&&a<='z';}qv(a){R a<'a';}
A ex(e)I *e;{I a=*e;
 if(qp(a)){if(e[1]=='=')R st[a-'a']=ex(e+2);a= st[ a-'a'];}
 R qv(a)?(*vm[a])(ex(e+1)):e[1]?(*vd[e[1]])(a,ex(e+2)):(A)a;}
noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);*z->p=c-'0';R z;}
verb(c){I i=0;for(;vt[i];)if(vt[i++]==c)R i;R 0;}
I *wd(s)C *s;{I a,n=strlen(s),*e=ma(n+1);C c;
 DO(n,e[i]=(a=noun(c=s[i]))?a:(a=verb(c))?a:c);e[n]=0;R e;}

main(){C s[99];while(gets(s))pr(ex(wd(s)));}
msg77710 - (view) Author: Boštjan Mejak (Retro) Date: 2008-12-13 02:11
Let's set a good example in the documentation and follow PEP 8. For
God's sake, this is the documentation of Python! Where else to set a
good example than here? Let's see some PEP 8 in action, in the
msg77711 - (view) Author: David W. Lambert (LambertDW) Date: 2008-12-13 02:34
That phrase of PEP 8 means to me "Use spaces to visually group 
expressions according to precedence."
msg77712 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-12-13 02:59
This is silly.  The current version better communicates its intended
msg77727 - (view) Author: Boštjan Mejak (Retro) Date: 2008-12-13 12:37
What is recommended in PEP 8, you are engouraged to follow that; not you
as a Python coder but you as a member of the Python community where PEP
8 is the coding style specification. Python's built-in modules have such
a lovely coding style because they all follow PEP 8. Why must the
documentation be an exception not to follow PEP 8? Is there a technical
reason? And the lack of space is not an issue. PEP 8 makes it clear to
"use spaces around arithmetic operators" and then it gives some examples
what is acceptable and what is not. Let us look at this again, shall we?

        i = i + 1

Let us convert this into our version from the example code:

        a, b = b, a + b

Only the a+b part is not written according to PEP 8. Python beginners
don't start learning the language by first reading PEP 8. They don't
even know it exists; and since they are beginners, talking about the
coding style is too soon. What they do first is read the Python tutorial
and they look at how code is written in the tutorial and get used to
that. And so if the code is badly written there, they will also write
bad code (bad as in 'with a bad coding style'). So we must set an
example for Python beginners (and also other people) to write
good-coding-style code. So my point is that people won't need to read
PEP 8 if that is applied into the documentation (especially the
tutorial); they'll just look at some example code and know how to write
code. Please fix those things like  a+b to a + b  and  n//x to n // x.

I have added mister van Rossum into this issue report, because I think
we need a BDFL opinion. What do you think, mister van Rossum, about this?
msg77751 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-12-13 16:07
Retro, you are blowing this way out of proportion.  Style guidelines are
not absolute rules that must be followed at all cost, and there are
always exceptions.  You need to have a lot of experience before you can
claim with certainty that a certain piece of code should or should not
be formatted according to the style guidelines.  (This is as opposed to
the syntax of the language, which is an absolute set of rules where
violations raise a SyntaxError.)

In this case, the PEP never meant to say that all arithmetic operators
have to be surrounded by spaces.  That would make just as little sense
as requiring no spaces.  The words in the PEP cannot possibly
approximate the set of heuristics I have in my mind for this purpose, 
and I don't think they have to.  When I wrote PEP 8 (or actually its
precursor), I was merely *suggesting* that certain uses of spaces look
better than others.  If you are interpreting this as requiring all
examples needing to follow the literal style guide, well, Im sorry, but
that's not how it was meant, and I am not willing to either change the
examples (the specific one you quote looks just fine to me) or to edit
the PEP to try and formulate a more complex rule.  In my experience, the
more baroque the rule the more arguments it elicits.
Date User Action Args
2022-04-11 14:56:42adminsetgithub: 48899
2008-12-13 16:07:33gvanrossumsetnosy: gvanrossum, loewis, georg.brandl, rhettinger, LambertDW, Retro
messages: + msg77751
2008-12-13 12:37:25Retrosetnosy: + gvanrossum
messages: + msg77727
2008-12-13 02:59:56rhettingersetstatus: open -> closed
resolution: wont fix
messages: + msg77712
2008-12-13 02:34:48LambertDWsetmessages: + msg77711
2008-12-13 02:11:08Retrosetmessages: + msg77710
2008-12-13 01:44:35LambertDWsetnosy: + LambertDW
messages: + msg77708
2008-12-13 01:00:24Retrosetmessages: + msg77706
2008-12-13 00:53:27Retrocreate