Environment vars

[Chris Angelico]

On Thu, Nov 26, 2020 at 6:19 AM dn via Python-list
<python-list at python.org> wrote:
>
> >> I've got a program which accepts an optional env variable listing a single
> >> or multiple directory for the app to use. I've done a bit of a search and
> >> see both a comma and semicolon being used/suggested as a path separator.
> >> Any consensus on which is better?
> ...
> > The one thing I really would *not* recommend is a DWIM arrangement of
> > having it guess at which delimiter to use. :)
>
>
> Interesting description. Historically I've always quoted "Postel's Law":
> ...
> In psychology the jargon is "satisficing" - being happy with whichever
> works when we try it: Why look [for a label]? I'll just push the door
> away from me - and if that doesn't work, then I'll pull on the handle
> (but if it's locked, my frustration will result in words being said...)
> How quickly does something 'easy' move from 'who cares' to 'almost anger'?
>
> So, if some users are likely to assume commas, but others [semi-]colons,
> perhaps the best service is to enable either/both! (hint: str.translate() )

That's absolutely fine IF and ONLY IF you can guarantee that all those
forms of punctuation cannot occur within the elements. I do this kind
of thing all the time when it's unambiguous; for instance, a multiline
input saying "enter Twitch channel names" takes the user input and
splits it on comma, semicolon, newline, or space, and then trims
individual entries with "http%*[s]://twitch.tv/%s%*[?/]" to get to
just the channel name. That works really well, because there's no way
that a channel name can contain that sort of punctuation.

It's completely NOT okay if you're working with something that might
contain anything - especially if your users aren't thinking about the
different separators. You might get away with using a comma to
separate names of people, happily working with lists like "Fred,
Barney, Wilma" and "Elsa, Anna, Kristoff, Sven" and "Steve, Steven,
Stephen, Stefan, Stephanie", but then along comes "Charles, Prince of
Wales" and suddenly your system breaks. But far worse than simply
using commas as separators is magically deciding to do so on the basis
of what someone's given you to parse. If someone tries to use "Fred;
Barney; Wilma" and "Elsa; Anna; Kristoff; Sven" and it works fine,
then they might expect that it'd be safe to list the British royal
family with semicolons between their names - but your code suddenly
decides to use commas, and now everything's broken.

The worst part of a DWIM system is that it's hard - often impossible -
to correct its errors. You end up fighting with it to interpret your
input correctly. With a simpler system, it might be bizarre and arcane
(seriously, look at bash's argument splitting and interpolation
rules!), but at least you don't have to fight it, and what works with
one set of data will definitely work with another.

> Conversely, consider the level of frustration faced by a user who
> expects one thing but is *restricted* to something else, eg sites which
> ask one to register a password, but don't advise up-front that they
> require some arcane combination/mix of characters - until after you've
> entered your [ignorant] choice - twice. Grrr!

Ohh I hear you on that. Especially when they think they need more
security than everyone else, so they say "have to have two uppercase,
two lowercase, one digit, and two symbols". And then they reject
password after password because, apparently, "!" isn't one of their
list of symbols. Or something. And of course, they never permit long
passwords. Oh no, that would be way too helpful, not to mention that
it'd actually be more secure. Sigh.

ChrisA