Environment vars

[dn]

On 26/11/2020 08:43, Chris Angelico wrote:
> 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.

That's the dichotomy: as soon as we aim for 'flexibility', we risk 
ambiguity.

Sometimes it might be better to go with the Zen of Python: "There should 
be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch."*

Sadly, whilst we coders can reasonably be encouraged "In the face of 
ambiguity, refuse the temptation to guess.", it will never appear in 
(many) user's manifestos - possibly an 'age' thing, more likely a "don't 
think" thing...


* I'm amused (not offended) by this casual racism, but wonder how it 
continues to be allowed given the Python Foundation's diversity principles.


That said, Python/PSL enables differences between OpSys to be 
'abstracted away', eg using / or \ as separator in a file/dir's path. 
Where applicable, use!


> 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

Well, as debated earlier, Steve Krug suggests that users 
aren't/shouldn't be thinking. So, fallacies abound!


> 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.

Hey, they're the Australian Royal Family too, aren't they?
(cue Republicanism sentiment)

How often does Prince Charles (the rest is "title" not name, BTW - thus 
"Charles Windsor" or even "Charles Wales") visit your web site/use your 
app?

Wouldn't you expect to cater less to princes and more to frogs?


> 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.

Yes, the issue lies with, and starts with, the combination. Referencing 
@Eryk's post, even users with knowledge of their OpSys will come to the 
problem with a different set of assumptions (hopes, fears, ...)

Accordingly, it may be appropriate to eschew free-form lists entirely. Thus:

MYPATH=Z:\Spam
MYPATH=foo
MYPATH=bar

... but then sit-back and wait for the first help-call from a user 
worrying that the first/last is the only specification that will be applied.

Are we likely to 'win' any-time soon?


Clearly, what might be appropriate or usable in one 'solution', should 
be out-right rejected in another situation.


>> 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.

Or... how about the form requesting an email address, which is rejected 
- presumably because the RegEx/library-routine has restrictions which 
don't include certain 'new' TLDs?

Well excuse me, but if I am responding to *your* email-message, which 
*you* sent to my email-address, surely the address has been proven and 
MUST be 'legal'!?
(and why am I entering it manually, when the email-message's link could 
have included same?)


Welcome to the wonderful world of UX!

We (computer people) have long been encouraged to 'make things 
idiot-proof'. The trouble with this injunction, is that the harder we 
try to achieve such, the faster 'the world' comes up with a better class 
of idiot!


By which I don't mean to imply that it is not worth trying. I spend 
quite a bit of time and effort 'in UX' - simply because there is often 
no-one else doing it (proper Agile teams aside).

Why? There's plenty of 'hard' and anecdotal research which confirms that 
if users find a tool 'difficult', 'awkward', or even 'different' (from 
what they expect), then it will be dropped!
-- 
Regards =dn