On 24/10/2019 11:33, Steven D'Aprano wrote:
On Wed, Oct 23, 2019 at 06:01:06PM +0100, Rhodri James wrote:
The proposed:
%w[red green blue]
says that this is something, good luck figuring out what.
You don't need *luck* to figure out what it does, you need five seconds in the REPL.
One of the most annoying tendencies on this mailing list is for people who dislike a feature to play dumb.
Sigh. You may have noticed that I was being slightly flip in all my descriptions, mostly to point up the different levels of cognitive load imposed by them. The fact is, %w[...] doesn't look like anything else Python does, and it's seeking to replace an absolutely bog-standard literal.
I prefer to let my editor do the work, actually. [...] and then write a quick editor macro to add the quotes and comma
Great. And how about those who cannot just "write a quick editor macro" which works perfectly first time?
If writing out a list of words in Python source code is so painful that you prefer to write a macro, that's a fantastic argument in favour of this new syntax!
Honestly, it's not that painful. You were the one contending that it was painful, I was demonstrating a method of avoiding the pain (that I use more out of laziness) that didn't put the load on the compiler every single time I run the script. People who can't just write editor macros have a few choices. Obviously they can learn how to write macros for their editor (and honestly, Emacs keyboard macros are pretty literally "monkey see, monkey do"). They can write the quotes and commas themselves, which isn't much more boring that writing the text in between the quotes. Or they can write a long string escaping any spaces perfectly first time, and split it. I think the strongest argument against both this proposal and the habit of using split() is that everyone looking at your example string of colours, including you and me, missed "forest green" the first time round. -- Rhodri James *-* Kynesim Ltd