Python vs. Perl

[Tim Peters]

[Alex Martelli]
> ...
> Ah, the keys in a dictionary (hash) display are taken as literal
> and the values aren't?  How quaint.  I used to know Perl pretty
> well and wrote tens thousands of lines in it -- I'm so glad I am
> at last forgetting its gyrations!-)  Is it a stropping issue?  Why
> are the quotes needed after the '=>'s -- or, ARE they?

TMTOWTDI.  Behold:

C:\Perl\bin>type hash.pl
%a = (a, b, c, d);
for $key (keys %a) {
    print "$key $a{$key}\n";
}

C:\Perl\bin>perl -w hash.pl
Unquoted string "a" may clash with future reserved word at hash.pl line 1.
Unquoted string "b" may clash with future reserved word at hash.pl line 1.
Unquoted string "c" may clash with future reserved word at hash.pl line 1.
Unquoted string "d" may clash with future reserved word at hash.pl line 1.
a b
c d

C:\Perl\bin>type hash2.pl
%a = (a=>b, c=>d);
for $key (keys %a) {
    print "$key $a{$key}\n";
}

C:\Perl\bin>perl -w hash2.pl
Unquoted string "b" may clash with future reserved word at hash2.pl line 1.
Unquoted string "d" may clash with future reserved word at hash2.pl line 1.
a b
c d

C:\Perl\bin>

So you can use barewords in both positions, and then use "," or "=>",
depending on how many warnings you want to get <wink>.  The
bareword=>"string" form appears current best practive, though (and there are
no warnings then).

Note that John Skaller's Vyper dialect of Python allows a similar trick:

    {x='y', y='z'}

in Vyper is equivalent to

    {'x': 'y', 'y': 'z'}

There's just no accounting for tastes <wink>.

at-least-it-wasn't-{x>>"y",y>>"z"}-ly y'rs  - tim