Re: [Python-ideas] Python reviewed
Thanks for the feedback guys. A few quick comments: Re: Colons. I'm sure I've seen that FAQ before. I may be arrogant but I can't take it seriously. Being "slightly" easier to read is hardly a reason for a mandatory structure. Re: PEP249. I thought I'd detailed quite a bit of what I thought should be possible. Is there a forum for advancing this? Re: do-while - that a is a loop construct that executes once before evaluating the condition. Supported by most languages. Re: Counters starting at zero vs one, Fortran has a neat solution to this for arrays if not strings - allow the programmer to select the starting index. I've seen -1 and 1000, for example. I can't say I'm convinced by Dijkstra's argument but it is somewhat esoteric because it isn't changing. When I've programmed for loops in C, sometimes you want zero based and sometimes one based, while most times you don't really care. To make it readable I would wherever possible write either: for (i=0;i<j;i++) for (i=1;i<=j;i++) // In both cases always executing j times Rgds
On Mon, Jan 9, 2017 at 8:12 PM, Simon Lovell <simon58500@bigpond.com> wrote:
"Readability counts." Did you notice that you placed a redundant ":"s in every comment of yours after "Re"? I don't think your message would look better without them. Another advantage of having : is that it allows smart editors to detect and highlight errors sooner and to better perform auto-indentation.
On Mon, Jan 9, 2017 at 5:12 PM, Simon Lovell <simon58500@bigpond.com> wrote:
I liked that back in the day, but I think it's really better if it's always the same. and see my other note for why the zero-based and open ended slicing is fabulous -- indexing really needs to match slicing. ONe more: since you mentioned Fortran -- it's a common use-case for an array to model some sort of regular spaced grid, so: x = start_x + i*delta_x really easy and logical math for figuring out where you are on a grid (and the reverse calculation) -- this is a pain with 1-based indexing.... (of course, C does this for pointer math for the same reason...) When I've programmed for loops in C, sometimes you want zero based and
in pyton, you never right that code anyway. most of the time, it's for item in sequence: no indexes at all. or: for i in range(N): ... indexes, but you dont care or for i, item in enumerate(seq): ... or for item1, item2 in zip(sequence): ... i.e you almost never care what the starting index is! -CHB
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Also in Python you can use: for x in range (1,j+1): to loop j times. Although it does read as though it is looping j+1 times to those not familiar. One more comment I wanted to make about end blocks, is that a respectable editor will add them for you, together with the indentation of the next line. EditPlus 2 did it best in my experience although I think I just haven't seen a well configured alternative. I very rarely forget the block closer but I do sometimes forget the colon. Regarding the logical inconsistency of my argument, well I am saying that I would prefer my redundancy at the end of the loop rather than the beginning. To say that the status quo is better is to say that you prefer your redundancy at the beginning. Fair enough, I'm happy to respect your opinion there. I still struggle to see why it should be mandatory though? For those who prefer to have the block closing delimiters this way, is the need for a keyword (could be a command line option) really the objection? I'll have a detailed look at your colon link a bit later. On 10/01/17 09:26, Chris Barker wrote:
On 1/9/17 8:44 PM, Simon Lovell wrote:
Can you clarify something for us? Are you proposing to add end-block syntax? You've said you prefer it, and that you miss it. But you haven't said, "I am proposing that Python should change." This list is about proposing changes to Python. Are you proposing that Python change in this way? You understand that this is a significant shift from a syntax that has been in place for a quarter century? Perhaps you should give yourself time to get used to Python as Python is. --Ned.
On Tue, Jan 10, 2017 at 12:44 PM, Simon Lovell <simon58500@bigpond.com> wrote:
Actually, Python does have a way to enable optional block closing directives. They're a little more compact than "endfor" and "endwhile" etc, and they're optional, so the compiler won't require you to use them (that would break heaps of libraries), but try this: -- cut -- import sys for arg in sys.argv: if arg == "hello": print("Hello, sir/madam") #if #for -- cut -- Okay, okay, that's a bit of a cheat, but still, if you really truly want "endfor", all you have to do is spell it "#for" and it'll be accepted. Don't expect experienced Python programmers to accept this at code review though. (And if you insist on a command line option, "python3 -X hashblockend" will do that for you. It won't actually DO anything though.) ChrisA
On 10/01/17 01:44, Simon Lovell wrote:
It's not really that one prefers redundancy anywhere. It's more a question of: a) Does the redundancy have any (however small) benefit? b) How "expensive" is the redundancy (in this case, that equates to mandatory characters typed and subsequent screen noise when reading the code). I don't understand how a "redundancy" of a trailing colon in any statement that will introduce a new level of indentation is worse than having to remember to type "end<statement>" when a dedent (which is zero characters) does that. Trailing colon "cost": 1 * (0.n) Block end "cost": (len("end") + len(statement_text)) * 1.0
I still struggle to see why it should be mandatory though?
That looks like a statement, but you've ended it with a question mark. Are you asking if you still struggle? I can't tell. Perhaps it's just the correct use of punctuation that you're objecting to ;)
One more comment I wanted to make about end blocks, is that a respectable editor will add them for you,
You are now asking me to write code with what you describe as a "respectable" editor. I use vim, which is very respectable, thank you. You'd like me to use "EditPlus 2" or equivalent. I struggle to see why that should be mandatory. Thanks for starting an entertaining thread, though ;) E.
On Tue, Jan 10, 2017 at 09:44:31AM +0800, Simon Lovell wrote:
*shrug* To those "not familiar", most language features are mysterious and it is easy to guess wrong. What's the difference between foo[x+1] and foo(x+1)? In Python, the first is a key or index lookup and the second is a function call; but in Mathematica, the first is a function call and the second is foo multiplied by x+1. Python prides itself in having a much easier learning curve than many languages, with syntax that is close to "executable pseudo-code", but that doesn't mean that there is *nothing* to learn.
One more comment I wanted to make about end blocks, [...]
If I never have to see code like: end end end end end end again, it will be too soon.
It's not mandatory -- there are dozens of other languages you can use that will satisfy your urge for a redundant "end" block marker. But for *Python*, it is mandatory because it is Guido's language, not yours. When you design your own language, you can design it to be as complicated or simple, as baroque or plain as you like. Think about what you are asking for: a command-line option that controls whether or not the interpreter requires "end" after each block. Now every single library module needs to be written twice, once with "end", once without. Otherwise, it won't even compile for half the users. If all you care about is something physically at the end of the block, without the compiler enforcing it, then Python already supports this, using your choice of keyword: with open(filename) as f: for line in f: if condition: while something: spam(line) #end #finish #done #conclusion Problem solved. -- Steve
On Mon, Jan 9, 2017 at 8:12 PM, Simon Lovell <simon58500@bigpond.com> wrote:
"Readability counts." Did you notice that you placed a redundant ":"s in every comment of yours after "Re"? I don't think your message would look better without them. Another advantage of having : is that it allows smart editors to detect and highlight errors sooner and to better perform auto-indentation.
On Mon, Jan 9, 2017 at 5:12 PM, Simon Lovell <simon58500@bigpond.com> wrote:
I liked that back in the day, but I think it's really better if it's always the same. and see my other note for why the zero-based and open ended slicing is fabulous -- indexing really needs to match slicing. ONe more: since you mentioned Fortran -- it's a common use-case for an array to model some sort of regular spaced grid, so: x = start_x + i*delta_x really easy and logical math for figuring out where you are on a grid (and the reverse calculation) -- this is a pain with 1-based indexing.... (of course, C does this for pointer math for the same reason...) When I've programmed for loops in C, sometimes you want zero based and
in pyton, you never right that code anyway. most of the time, it's for item in sequence: no indexes at all. or: for i in range(N): ... indexes, but you dont care or for i, item in enumerate(seq): ... or for item1, item2 in zip(sequence): ... i.e you almost never care what the starting index is! -CHB
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Also in Python you can use: for x in range (1,j+1): to loop j times. Although it does read as though it is looping j+1 times to those not familiar. One more comment I wanted to make about end blocks, is that a respectable editor will add them for you, together with the indentation of the next line. EditPlus 2 did it best in my experience although I think I just haven't seen a well configured alternative. I very rarely forget the block closer but I do sometimes forget the colon. Regarding the logical inconsistency of my argument, well I am saying that I would prefer my redundancy at the end of the loop rather than the beginning. To say that the status quo is better is to say that you prefer your redundancy at the beginning. Fair enough, I'm happy to respect your opinion there. I still struggle to see why it should be mandatory though? For those who prefer to have the block closing delimiters this way, is the need for a keyword (could be a command line option) really the objection? I'll have a detailed look at your colon link a bit later. On 10/01/17 09:26, Chris Barker wrote:
On 1/9/17 8:44 PM, Simon Lovell wrote:
Can you clarify something for us? Are you proposing to add end-block syntax? You've said you prefer it, and that you miss it. But you haven't said, "I am proposing that Python should change." This list is about proposing changes to Python. Are you proposing that Python change in this way? You understand that this is a significant shift from a syntax that has been in place for a quarter century? Perhaps you should give yourself time to get used to Python as Python is. --Ned.
On Tue, Jan 10, 2017 at 12:44 PM, Simon Lovell <simon58500@bigpond.com> wrote:
Actually, Python does have a way to enable optional block closing directives. They're a little more compact than "endfor" and "endwhile" etc, and they're optional, so the compiler won't require you to use them (that would break heaps of libraries), but try this: -- cut -- import sys for arg in sys.argv: if arg == "hello": print("Hello, sir/madam") #if #for -- cut -- Okay, okay, that's a bit of a cheat, but still, if you really truly want "endfor", all you have to do is spell it "#for" and it'll be accepted. Don't expect experienced Python programmers to accept this at code review though. (And if you insist on a command line option, "python3 -X hashblockend" will do that for you. It won't actually DO anything though.) ChrisA
On 10/01/17 01:44, Simon Lovell wrote:
It's not really that one prefers redundancy anywhere. It's more a question of: a) Does the redundancy have any (however small) benefit? b) How "expensive" is the redundancy (in this case, that equates to mandatory characters typed and subsequent screen noise when reading the code). I don't understand how a "redundancy" of a trailing colon in any statement that will introduce a new level of indentation is worse than having to remember to type "end<statement>" when a dedent (which is zero characters) does that. Trailing colon "cost": 1 * (0.n) Block end "cost": (len("end") + len(statement_text)) * 1.0
I still struggle to see why it should be mandatory though?
That looks like a statement, but you've ended it with a question mark. Are you asking if you still struggle? I can't tell. Perhaps it's just the correct use of punctuation that you're objecting to ;)
One more comment I wanted to make about end blocks, is that a respectable editor will add them for you,
You are now asking me to write code with what you describe as a "respectable" editor. I use vim, which is very respectable, thank you. You'd like me to use "EditPlus 2" or equivalent. I struggle to see why that should be mandatory. Thanks for starting an entertaining thread, though ;) E.
On Tue, Jan 10, 2017 at 09:44:31AM +0800, Simon Lovell wrote:
*shrug* To those "not familiar", most language features are mysterious and it is easy to guess wrong. What's the difference between foo[x+1] and foo(x+1)? In Python, the first is a key or index lookup and the second is a function call; but in Mathematica, the first is a function call and the second is foo multiplied by x+1. Python prides itself in having a much easier learning curve than many languages, with syntax that is close to "executable pseudo-code", but that doesn't mean that there is *nothing* to learn.
One more comment I wanted to make about end blocks, [...]
If I never have to see code like: end end end end end end again, it will be too soon.
It's not mandatory -- there are dozens of other languages you can use that will satisfy your urge for a redundant "end" block marker. But for *Python*, it is mandatory because it is Guido's language, not yours. When you design your own language, you can design it to be as complicated or simple, as baroque or plain as you like. Think about what you are asking for: a command-line option that controls whether or not the interpreter requires "end" after each block. Now every single library module needs to be written twice, once with "end", once without. Otherwise, it won't even compile for half the users. If all you care about is something physically at the end of the block, without the compiler enforcing it, then Python already supports this, using your choice of keyword: with open(filename) as f: for line in f: if condition: while something: spam(line) #end #finish #done #conclusion Problem solved. -- Steve
participants (7)
-
Alexander Belopolsky -
Chris Angelico -
Chris Barker -
Erik -
Ned Batchelder -
Simon Lovell -
Steven D'Aprano