Hmm, Thanks Chris. I thought I was posting this to the correct place. I've never seen that "for line in open ..." after googling it many times! Why is this question so often asked then? Re:Indentation making end block markers not needed; well yes they aren't /needed/. However, they are useful for readability purposes. Perhaps if I use it some more I'll see that they aren't but I doubt it. Re:PEP249 & SQL, I thought I was proposing something like that but it can't be tacked on later I don't think - needs to be an inate part of Python to work as cleanly as 4gl languages. Re: your named tuple suggestion, wouldn't that mean that the naming is divorced from the result column names - that is part of what shouldn't be. Re:Everything being true of false. I don't see the value of that. Only boolean data should be valid in boolean contexts. I don't really see how that can be argued. On 09/01/17 21:31, python-ideas-request@python.org wrote:
On Mon, Jan 9, 2017 at 2:50 PM, Simon Lovell <simon58500@bigpond.com> wrote:
The distinction and the explanation of this is the first result of the google search "Python process file line by line" http://stackoverflow.com/questions/11130312/line-by-line-file-processing-for... You probably haven't came across that because you think and search using C terms. Once you get used to context managers they are incredibly useful. I would advise to watch talks like "Beyond Pep 8" [1], comparing the same program in Python and Java.
I use to like end markers. Though not having them make the code quite shorted. When you have 1 line condition, or context manager or loop, it literally adds 50% more line to your condition/loop/contextmanager. As the next line is anyway de-indented, you see your block anyway.
Things are true-ish or false-ish, if you prefer. This allows idioms like if mycontainer: process_my_container(mycontainer) And you can process it only if you have items and it is not none. Your own object can raise if they get casted to bools, so if you really like your object to not behave like a bool, you can. It's not because they are truthy or falsy that they compare equal:
Also Boolean in Python are singletons (like None) , so you will see comparison by identity `... is None` ( `... is False`, `... is True` rarely) if you really care about only being in boolean context you can. Also Python is "ducktyped", if it quack and walks like a duck , then it's a duck. If an object defines how to behave as a bool then that's great. You can then use your own object that are truthy-falsy and carry more information by still using other libraries. if not allowed: raise OhNoooe('You can't because', allowed.reason) -- M [1]:https://www.youtube.com/watch?v=wf-BqAjZb8M Sorry Simon for double Mail, I forgot to reply-all.
Simon Lovell writes:
Hmm, Thanks Chris. I thought I was posting this to the correct place.
Well, you didn't actually make any specific suggestions, and you describe it as a "review" rather than an RFE.
I've never seen that "for line in open ..." after googling it many times! Why is this question so often asked then?
Lot of C programmers out there, I guess. It's in all the textbooks and references I have, and in the tutorial: https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects
You should take a look at SQLAlchemy and other Python database managers. I don't know what your "untackable it" is so I can't be more specific. Note that PEP 249 is not intended to provide an API for ordinary Python programmers' use. It was expected that convenient management modules would be provided on top of the DBAPI. PEP 249 is intended to provide an API between the backend drivers and the database manager modules, so that any manager could easily interface with any driver.
There's only a point in arguing it if you think that data types are fundamentally mutually exclusive. But they're not in object-oriented languages like Python. Something can be object, boolean, and str all at the same time. (The presence of a type called boolean is a red herring here. True and False are merely the representative boolean values, a convenience for programmers who want them.) In Python, all data is boolean, unambiguously being interpreted as "true" or "false" in boolean contexts. As far as boolean contexts are concerned, there are an infinite number of objects equivalent to True and another bunch (currently not infinite) equivalent to False. It could be argued that this leads to programmers making bugs, but I personally haven't found it so, in Python or Lisp, and I find the lack of it very annoying when I'm writing Scheme since it's so similar to Lisp.
I seem to recall that this has to do with an implementation requirement, that the syntax be parseable with an LL parser.
It could, but won't. That's a pragma, and Guido hates pragmas. It's certainly not worth a keyword.
Aside: I really find those suite terminators gratuitous; if I need something "stronger" than a dedent, an empty line is much prettier than they are IMO. Actually the accepted loop-and-a-half idiom is f = open(file) line = f.readline() while line: process(line) line = f.readline() "for line in f" makes that unnecessary in this case, but there do remain cases where loop-and-a-half is needed because of the lack of an assignment expression.
Keywords are expensive in that every Python programmer needs to know all of them to avoid using one as an identifier. So it is a general design principle of Python to avoid adding new ones where possible. It turns out that for ... else is rarely used even by experts, and the main use case is extremely idiomatic, so probably no harm is done.
Changing print from a statement to a function in Python 3 adds no positive value that I can see
It eliminates a keyword, makes it possible to experiment with different implementations, and allows printing in the middle of expressions (although since print() always returns None, that's not as useful as it could be).
Upper delimiters being exclusive while lower delimiters are inclusive. This is very counter intuitive.
If you say so. But it is convenient because list == list[:n] + list[n:].
I seem to recall that ?: was out because Guido at the time was adamantly against use of ? as syntax in Python, so we were kinda stuck with keywords. He didn't want to have non-unary expressions start with keywords (would have caused ugliness in the parser, I guess) and he did want to reuse keywords. "<condition> then <true-value> else <false-value>" was suggested but most who posted thought it less readable than the syntax chosen. YMMV, of course.
There were at least four reasons for this in C, in fact, and none have anything to do with the inability to add a Boolean type to a programming language: (0) that's the way the hardware works (1) the idiom "if (ptr)" (2) the idiom "while (i--)" (3) the idiom "while (*dest++ = *src++)" all of which compiled[1] nicely to efficient machine code without an optimization pass, and some take advantage of useful characteristics of the Unix OS. Today one might argue that these are an attractive nuisance and too cute to be allowed to live, but at that time not so much was known about the kind of mistakes programmers like to make. Footnotes: [1] On modern machines (3) is handled more efficiently by specialized instructions.
not even sure why Im engaging, but.... Note 1) Many of these issues have been widely discussed all over the internet -- I don't think I've seen anything new here. So it would have been nice to do some more research before posting. Now into the fray!
Re:Everything being true of false. I don't see the value of
that. Only boolean data should be valid in boolean contexts.
I actually agree with that -- but there are a lot of nice conveniences from Python's idea of "truthiness", too.
I don't so -- but I DO think that this was a usability issue that was investigated early in PYthon's development. (Or maybe even ABC's development) -- in fact, I suspect is is one of the few programming language syntax decisions (in any language) that went through any kind of formal usability testing. I didn't bring it up -- so I'll leave the googling to others.
Actually the accepted loop-and-a-half idiom is
I used to write that style, but I've never liked it, so went with: f = open(file) while True: line = f.readline() if not f: break process(line) the while True and check for a break is kinda ugly, but I think less ugly than two separate calls to readline() and, of course, we now have: for line in f: process(line) which is cleaner an easier than anything I've seen in any other language -- so WHAT exactly was the original complaint???
I've kinda wanted an "do-until" loop of some sort sometimes, but frankly, not that badly :-)
Changing print from a statement to a function in Python 3 adds no positive value that I can see
yeah, yeah yeah -- PLEASE go read an number of py3 justifications and rants! This is really a dead horse.
Upper delimiters being exclusive while lower delimiters are inclusive. This is very counter intuitive.
but SO much better than the alternative! This was also tested som, I think maybe by Dijkstra of C++ fame. but these identities are REALLY, REALLY useful: s[:n] + s[n:] == s len(s[:n]) == n len(s[:-n]) == n len(s[n:i]) == i - n (maybe a few others?) These prevent a HUGE number of off by one errors and ecta code adding and subtracting one all over the place -- this is almost as important to Pythons' usability as the significant indentation :-)
Ha Ha Ha Ha!!! I could read and understand Python's version the first time I saw it -- I still have to look up the C version (not much of C programmer). maybe you think it's wordy -- but it's very readable. -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
On Mon, Jan 9, 2017 at 8:19 PM, Chris Barker <chris.barker@noaa.gov> wrote:
I think maybe by Dijkstra of C++ fame.
Dijkstra is famous for many things, but C++ is another Dutchman's fault. Dijkstra's famous works include "GOTO Considered Harmful" [1] and "How do we tell truths that might hurt?" [2]. [1]: http://wiki.c2.com/?GotoConsideredHarmful [2]: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html
On Mon, Jan 9, 2017 at 2:50 PM, Simon Lovell <simon58500@bigpond.com> wrote:
The distinction and the explanation of this is the first result of the google search "Python process file line by line" http://stackoverflow.com/questions/11130312/line-by-line-file-processing-for... You probably haven't came across that because you think and search using C terms. Once you get used to context managers they are incredibly useful. I would advise to watch talks like "Beyond Pep 8" [1], comparing the same program in Python and Java.
I use to like end markers. Though not having them make the code quite shorted. When you have 1 line condition, or context manager or loop, it literally adds 50% more line to your condition/loop/contextmanager. As the next line is anyway de-indented, you see your block anyway.
Things are true-ish or false-ish, if you prefer. This allows idioms like if mycontainer: process_my_container(mycontainer) And you can process it only if you have items and it is not none. Your own object can raise if they get casted to bools, so if you really like your object to not behave like a bool, you can. It's not because they are truthy or falsy that they compare equal:
Also Boolean in Python are singletons (like None) , so you will see comparison by identity `... is None` ( `... is False`, `... is True` rarely) if you really care about only being in boolean context you can. Also Python is "ducktyped", if it quack and walks like a duck , then it's a duck. If an object defines how to behave as a bool then that's great. You can then use your own object that are truthy-falsy and carry more information by still using other libraries. if not allowed: raise OhNoooe('You can't because', allowed.reason) -- M [1]:https://www.youtube.com/watch?v=wf-BqAjZb8M Sorry Simon for double Mail, I forgot to reply-all.
Simon Lovell writes:
Hmm, Thanks Chris. I thought I was posting this to the correct place.
Well, you didn't actually make any specific suggestions, and you describe it as a "review" rather than an RFE.
I've never seen that "for line in open ..." after googling it many times! Why is this question so often asked then?
Lot of C programmers out there, I guess. It's in all the textbooks and references I have, and in the tutorial: https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects
You should take a look at SQLAlchemy and other Python database managers. I don't know what your "untackable it" is so I can't be more specific. Note that PEP 249 is not intended to provide an API for ordinary Python programmers' use. It was expected that convenient management modules would be provided on top of the DBAPI. PEP 249 is intended to provide an API between the backend drivers and the database manager modules, so that any manager could easily interface with any driver.
There's only a point in arguing it if you think that data types are fundamentally mutually exclusive. But they're not in object-oriented languages like Python. Something can be object, boolean, and str all at the same time. (The presence of a type called boolean is a red herring here. True and False are merely the representative boolean values, a convenience for programmers who want them.) In Python, all data is boolean, unambiguously being interpreted as "true" or "false" in boolean contexts. As far as boolean contexts are concerned, there are an infinite number of objects equivalent to True and another bunch (currently not infinite) equivalent to False. It could be argued that this leads to programmers making bugs, but I personally haven't found it so, in Python or Lisp, and I find the lack of it very annoying when I'm writing Scheme since it's so similar to Lisp.
I seem to recall that this has to do with an implementation requirement, that the syntax be parseable with an LL parser.
It could, but won't. That's a pragma, and Guido hates pragmas. It's certainly not worth a keyword.
Aside: I really find those suite terminators gratuitous; if I need something "stronger" than a dedent, an empty line is much prettier than they are IMO. Actually the accepted loop-and-a-half idiom is f = open(file) line = f.readline() while line: process(line) line = f.readline() "for line in f" makes that unnecessary in this case, but there do remain cases where loop-and-a-half is needed because of the lack of an assignment expression.
Keywords are expensive in that every Python programmer needs to know all of them to avoid using one as an identifier. So it is a general design principle of Python to avoid adding new ones where possible. It turns out that for ... else is rarely used even by experts, and the main use case is extremely idiomatic, so probably no harm is done.
Changing print from a statement to a function in Python 3 adds no positive value that I can see
It eliminates a keyword, makes it possible to experiment with different implementations, and allows printing in the middle of expressions (although since print() always returns None, that's not as useful as it could be).
Upper delimiters being exclusive while lower delimiters are inclusive. This is very counter intuitive.
If you say so. But it is convenient because list == list[:n] + list[n:].
I seem to recall that ?: was out because Guido at the time was adamantly against use of ? as syntax in Python, so we were kinda stuck with keywords. He didn't want to have non-unary expressions start with keywords (would have caused ugliness in the parser, I guess) and he did want to reuse keywords. "<condition> then <true-value> else <false-value>" was suggested but most who posted thought it less readable than the syntax chosen. YMMV, of course.
There were at least four reasons for this in C, in fact, and none have anything to do with the inability to add a Boolean type to a programming language: (0) that's the way the hardware works (1) the idiom "if (ptr)" (2) the idiom "while (i--)" (3) the idiom "while (*dest++ = *src++)" all of which compiled[1] nicely to efficient machine code without an optimization pass, and some take advantage of useful characteristics of the Unix OS. Today one might argue that these are an attractive nuisance and too cute to be allowed to live, but at that time not so much was known about the kind of mistakes programmers like to make. Footnotes: [1] On modern machines (3) is handled more efficiently by specialized instructions.
not even sure why Im engaging, but.... Note 1) Many of these issues have been widely discussed all over the internet -- I don't think I've seen anything new here. So it would have been nice to do some more research before posting. Now into the fray!
Re:Everything being true of false. I don't see the value of
that. Only boolean data should be valid in boolean contexts.
I actually agree with that -- but there are a lot of nice conveniences from Python's idea of "truthiness", too.
I don't so -- but I DO think that this was a usability issue that was investigated early in PYthon's development. (Or maybe even ABC's development) -- in fact, I suspect is is one of the few programming language syntax decisions (in any language) that went through any kind of formal usability testing. I didn't bring it up -- so I'll leave the googling to others.
Actually the accepted loop-and-a-half idiom is
I used to write that style, but I've never liked it, so went with: f = open(file) while True: line = f.readline() if not f: break process(line) the while True and check for a break is kinda ugly, but I think less ugly than two separate calls to readline() and, of course, we now have: for line in f: process(line) which is cleaner an easier than anything I've seen in any other language -- so WHAT exactly was the original complaint???
I've kinda wanted an "do-until" loop of some sort sometimes, but frankly, not that badly :-)
Changing print from a statement to a function in Python 3 adds no positive value that I can see
yeah, yeah yeah -- PLEASE go read an number of py3 justifications and rants! This is really a dead horse.
Upper delimiters being exclusive while lower delimiters are inclusive. This is very counter intuitive.
but SO much better than the alternative! This was also tested som, I think maybe by Dijkstra of C++ fame. but these identities are REALLY, REALLY useful: s[:n] + s[n:] == s len(s[:n]) == n len(s[:-n]) == n len(s[n:i]) == i - n (maybe a few others?) These prevent a HUGE number of off by one errors and ecta code adding and subtracting one all over the place -- this is almost as important to Pythons' usability as the significant indentation :-)
Ha Ha Ha Ha!!! I could read and understand Python's version the first time I saw it -- I still have to look up the C version (not much of C programmer). maybe you think it's wordy -- but it's very readable. -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
On Mon, Jan 9, 2017 at 8:19 PM, Chris Barker <chris.barker@noaa.gov> wrote:
I think maybe by Dijkstra of C++ fame.
Dijkstra is famous for many things, but C++ is another Dutchman's fault. Dijkstra's famous works include "GOTO Considered Harmful" [1] and "How do we tell truths that might hurt?" [2]. [1]: http://wiki.c2.com/?GotoConsideredHarmful [2]: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html
participants (5)
-
Alexander Belopolsky -
Chris Barker -
Matthias Bussonnier -
Simon Lovell -
Stephen J. Turnbull