[Skip]
I use it all the time. For example, to build up (what I consider to be) readable SQL queries:
rows = self.executesql("select cities.city, state, country" " from cities, venues, events, addresses" " where cities.city like %s" " and events.active = 1" " and venues.address = addresses.id" " and addresses.city = cities.id" " and events.venue = venues.id", (city,))
I find that style hard to maintain. What is the advantage over multi-line strings? rows = self.executesql(''' select cities.city, state, country from cities, venues, events, addresses where cities.city like %s and events.active = 1 and venues.address = addresses.id and addresses.city = cities.id and events.venue = venues.id ''', (city,)) Raymond
Raymond> [Skip] >> I use it all the time. For example, to build up (what I consider to be) >> readable SQL queries: >> >> rows = self.executesql("select cities.city, state, country" >> " from cities, venues, events, addresses" >> " where cities.city like %s" >> " and events.active = 1" >> " and venues.address = addresses.id" >> " and addresses.city = cities.id" >> " and events.venue = venues.id", >> (city,)) Raymond> I find that style hard to maintain. What is the advantage over Raymond> multi-line strings? Raymond> rows = self.executesql(''' Raymond> select cities.city, state, country Raymond> from cities, venues, events, addresses Raymond> where cities.city like %s Raymond> and events.active = 1 Raymond> and venues.address = addresses.id Raymond> and addresses.city = cities.id Raymond> and events.venue = venues.id Raymond> ''', Raymond> (city,)) Maybe it's just a quirk of how python-mode in Emacs treats multiline strings that caused me to start doing things this way (I've been doing my embedded SQL statements this way for several years now), but when I hit LF in an open multiline string a newline is inserted and the cursor is lined up under the "r" of "rows", not under the opening quote of the multiline string, and not where you chose to indent your example. When I use individual strings the parameters line up where I want them to (the way I lined things up in my example). At any rate, it's what I'm used to now. Skip
Raymond> I find that style hard to maintain. What is the advantage over Raymond> multi-line strings?
Raymond> rows = self.executesql(''' Raymond> select cities.city, state, country Raymond> from cities, venues, events, addresses Raymond> where cities.city like %s Raymond> and events.active = 1 Raymond> and venues.address = addresses.id Raymond> and addresses.city = cities.id Raymond> and events.venue = venues.id Raymond> ''', Raymond> (city,))
[Skip]
Maybe it's just a quirk of how python-mode in Emacs treats multiline strings that caused me to start doing things this way (I've been doing my embedded SQL statements this way for several years now), but when I hit LF in an open multiline string a newline is inserted and the cursor is lined up under the "r" of "rows", not under the opening quote of the multiline string, and not where you chose to indent your example. When I use individual strings the parameters line up where I want them to (the way I lined things up in my example). At any rate, it's what I'm used to now.
I completely understand. Almost any simplification or feature elimination proposal is going to bump-up against, "what we're used to now". Py3k may be our last chance to simplify the language. We have so many special little rules that even advanced users can't keep them all in their head. Certainly, every feature has someone who uses it. But, there is some value to reducing the number of rules, especially if those rules are non-essential (i.e. implicit string concatenation has simple, clear alternatives with multi-line strings or with the plus-operator). Another way to look at it is to ask whether we would consider adding implicit string concatenation if we didn't already have it. I think there would be a chorus of emails against it -- arguing against language bloat and noting that we already have triple-quoted strings, raw-strings, a verbose flag for regexs, backslashes inside multiline strings, the explicit plus-operator, and multi-line expressions delimited by parentheses or brackets. Collectively, that is A LOT of ways to do it. I'm asking this group to give up a minor habit so that we can achieve at least a few simplifications on the way to Py3.0 -- basically, our last chance. Similar thoughts apply to the octal literal PEP. I'm -1 on introducing yet another way to write the literal (and a non-standard one at that). My proposal was simply to eliminate it. The use cases are few and far between (translating C headers and setting unix file permissions). In either case, writing int('0777', 8) suffices. In the latter case, we've already provided clear symbolic alternatives. This simplification of the language would be a freebie (impacting very little code, simplifying the lexer, eliminating a special rule, and eliminating a source of confusion for the young amoung us who do not know about such things). Raymond
Raymond Hettinger wrote:
Raymond> I find that style hard to maintain. What is the advantage over Raymond> multi-line strings?
Raymond> rows = self.executesql(''' Raymond> select cities.city, state, country Raymond> from cities, venues, events, addresses Raymond> where cities.city like %s Raymond> and events.active = 1 Raymond> and venues.address = addresses.id Raymond> and addresses.city = cities.id Raymond> and events.venue = venues.id Raymond> ''', Raymond> (city,))
[Skip]
Maybe it's just a quirk of how python-mode in Emacs treats multiline strings that caused me to start doing things this way (I've been doing my embedded SQL statements this way for several years now), but when I hit LF in an open multiline string a newline is inserted and the cursor is lined up under the "r" of "rows", not under the opening quote of the multiline string, and not where you chose to indent your example. When I use individual strings the parameters line up where I want them to (the way I lined things up in my example). At any rate, it's what I'm used to now.
I completely understand. Almost any simplification or feature elimination proposal is going to bump-up against, "what we're used to now". Py3k may be our last chance to simplify the language. We have so many special little rules that even advanced users can't keep them all in their head. Certainly, every feature has someone who uses it. But, there is some value to reducing the number of rules, especially if those rules are non-essential (i.e. implicit string concatenation has simple, clear alternatives with multi-line strings or with the plus-operator).
Another way to look at it is to ask whether we would consider adding implicit string concatenation if we didn't already have it. I think there would be a chorus of emails against it -- arguing against language bloat and noting that we already have triple-quoted strings, raw-strings, a verbose flag for regexs, backslashes inside multiline strings, the explicit plus-operator, and multi-line expressions delimited by parentheses or brackets. Collectively, that is A LOT of ways to do it.
I'm asking this group to give up a minor habit so that we can achieve at least a few simplifications on the way to Py3.0 -- basically, our last chance.
Similar thoughts apply to the octal literal PEP. I'm -1 on introducing yet another way to write the literal (and a non-standard one at that). My proposal was simply to eliminate it. The use cases are few and far between (translating C headers and setting unix file permissions). In either case, writing int('0777', 8) suffices. In the latter case, we've already provided clear symbolic alternatives. This simplification of the language would be a freebie (impacting very little code, simplifying the lexer, eliminating a special rule, and eliminating a source of confusion for the young amoung us who do not know about such things).
My counter argument is that these simplifications aren't simplifying much - that is, the removals don't cascade and cause other simplifications. The grammar file, for example, won't look dramatically different if these changes are made. The simplification argument seems weak to me because the change in overall language complexity is very small, whereas the inconvenience caused, while not huge, is at least significant. That being said, line continuation is the only one I really care about. And I would happily give up backslashes in exchange for a more sane method of continuing lines. Either way avoids "spurious" grouping operators which IMHO don't make for easier-to-read code. -- Talin
Raymond> Another way to look at it is to ask whether we would consider Raymond> adding implicit string concatenation if we didn't already have Raymond> it. As I recall it was a "relatively recent" addition. Maybe 2.0 or 2.1? It certainly hasn't been there from the beginning. Skip
"skip" == skip <skip@pobox.com> writes:
Raymond> Another way to look at it is to ask whether we would consider Raymond> adding implicit string concatenation if we didn't already have Raymond> it. skip> As I recall it was a "relatively recent" addition. Maybe 2.0 or skip> 2.1? It certainly hasn't been there from the beginning. Misc/HISTORY suggests this feature was added in 1.0.2 (May 1994). Apologies for my bad memory. Skip
On Wed, May 02, 2007 at 10:23:39PM -0700, Raymond Hettinger wrote:
Another way to look at it is to ask whether we would consider adding implicit string concatenation if we didn't already have it. I think there would be a chorus of emails against it
Personally, I would have been irritated if it wasn't there. I'm used to it from other languages, and it would seem like a gratuitous incompatability if it wasn't supported. I'm definitely against this proposal in its entirety.
skip@pobox.com wrote:
when I hit LF in an open multiline string a newline is inserted and the cursor is lined up under the "r" of "rows", not under the opening quote of the multiline string, and not where you chose to indent your example.
Seems to me that Python actually benefits from an editor which doesn't try to be too clever about auto-formatting. I'm doing most of my Python editing at the moment using BBEdit Lite, which knows nothing at all about Python code -- but it works very well. -- Greg
participants (5)
-
Greg Ewing -
Jon Ribbens -
Raymond Hettinger -
skip＠pobox.com -
Talin