I have to say that I'm really surprised that this idea is gaining this much traction. And this is why:

Shorthand for a list of stings, whether this proposal, or the "list of strings".split() "hack" -- is useful primarily for what I"d call "scripting",rather than "software development".

There is not clear distinction, of course, but in (my definition of) scripting, the write:read ratio (and the write:everything-else ratio: e.g. runinng, testing, debugging, reviewing) is much higher, and it is a lot more common to have a bunch of literals. I know I often put a pile of literals a the top of a script, whereas a program would use a config file, or command line arguments, or pull data from a database or web service, or .....

So why am I surprised? Because Python, over the years, has become more of a "programming language", and a bit less of a scripting language.

print x => print(x) is a prime example -- but there are many others.

I'd say f-strings are the only exception I can think of of a feature that is probably more useful to "scripting" than "programming". But less so than this proposal.

On to this one -- despite the fact that I do a fair bit of quicky scripting, I don't think this is worth it -- it's really only useful for a particular subset of lists of strings -- once you add escapoing whitepace and all that (and what do you do with quotes?, it isn't a good general solution. Sure it's a common use case, but then, the "a bunch of words".split() solution is fine in that case.

As for "one obvious way to do it" -- that is aspirational -- there simply can't be one obvious way to do everything. And sometimes "it" is not one thing. I'd say:

if you need to build a quick list of simple single words that isn't likely to get more complex, then use .split(), if you need to build a list of strings that are not simple words, and/or may get more complex, then use the full set of quotation marks.

Final point: ideally, we all have editors that help with the quotes, so it's not *quite* as much extra typing.

TL;DR -- not a really wide use case, and makes the language that much more "PERL-like".


On Wed, Oct 23, 2019 at 8:00 AM Steven D'Aprano <steve@pearwood.info> wrote:
On Wed, Oct 23, 2019 at 10:09:41AM -0400, David Mertz wrote:

> One big problem with the current obvious way would be shared by the
> proposal. This hits me fairly often.
> colors1 = "red green blue".split()  # happy
> Later
> colors2 = "cyan   forest green  burnt umber".split()
> # oops, not what I wanted, quote each separately

It isn't shared by the proposal.

  colors2 = %w[cyan   forest green  burnt\x20umber]

Escaping the space ``\ `` might be nicer, but escaping an invisible
character is problematic (see the problems with the explict line
continuation character ``\``) and we may not be able to add any new
escape characters to the language. However a hex escape will do the

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TCIWZCAPCIQJA2LMAKK6H4TWQNBJPUU7/
Code of Conduct: http://python.org/psf/codeofconduct/

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython