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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
