Issue4649
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.
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 | |
http://docs.python.org/3.0/tutorial/controlflow.html#defining-functions 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: Yes: i = i + 1 No: 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: from ... print(n, 'equals', x, '*', n//x) to ... 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(find){} 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[]="+{~<#,"; A(*vd[])()={0,plus,from,find,0,rsh,cat}, (*vm[])()={0,id,size,iota,box,sha,0}; 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 documentation! |
|||
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) * ![]() |
Date: 2008-12-13 02:59 | |
This is silly. The current version better communicates its intended purpose. |
|||
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? Yes: i = i + 1 No: i=i+1 Let us convert this into our version from the example code: Yes: a, b = b, a + b No: 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) * ![]() |
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. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:42 | admin | set | github: 48899 |
2008-12-13 16:07:33 | gvanrossum | set | nosy:
gvanrossum, loewis, georg.brandl, rhettinger, LambertDW, Retro messages: + msg77751 |
2008-12-13 12:37:25 | Retro | set | nosy:
+ gvanrossum messages: + msg77727 |
2008-12-13 02:59:56 | rhettinger | set | status: open -> closed resolution: wont fix messages: + msg77712 |
2008-12-13 02:34:48 | LambertDW | set | messages: + msg77711 |
2008-12-13 02:11:08 | Retro | set | messages: + msg77710 |
2008-12-13 01:44:35 | LambertDW | set | nosy:
+ LambertDW messages: + msg77708 |
2008-12-13 01:00:24 | Retro | set | messages: + msg77706 |
2008-12-13 00:53:27 | Retro | create |