Perl is worse!

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8o397m.3ok.grey at teleute.rpglink.com...
    [snip]
> @names = ("Bob","Bob","Bob","Robert Paulson");
> @occupation = ("Uncle","Uncle","Uncle","Mayhem");
> $index = 0;
> foreach $name (@names){
>   $done = 0;
>   $x = 0;
>   while (!$done){
>     if ($members{$name.$x}){
>       $x++
>       next;
>     }
>     else{
>       $members{$name.$x} = $occupation[$index];
>     }
>   }
> }
>
>     Your argument completely ignores cases like the above, doesn't it?
Where
> you want to have a counter incremented (math function) but need to use it
in a
> string constantly.  Simplistic example, yes, but a valid one.  Why force
the
> programmer to do constant switching to do such a simple thing?

You have not been very explicit about the structure of '%members', but it
seems to be a hash indexed by a string, which in turn is made up of a name
which is concatenated with digits to make it unique.  (There also seems to
be some problems with $index, which is never incremented, and $done,
which is never set -- not clear what parts you have omitted).  But, back to
%members...:
Why organize it like that, rather than just index it directly with a
(name,number)
pair?  Presumably, because Perl cannot use a pair as an index, but wants a
scalar?  But that's no problem in Python, so (guessing at your snipped
parts):

members = {}
names = ["Bob","Bob","Bob","Robert Paulson"]
occupation = ["Uncle","Uncle","Uncle","Mayhem"]
for name, occ in zip(names,occupation):
    x=0
    while members.has_key((name,x)):
        x=x+1
    members[(name,x)] = occ

Making members into a dictionary _of lists_ seems another quite plausible
organization, changing the loop's body to:
    if members.has_key(name):
        members[name].append(occ)
    else:
        members[name]=[occ]
or (a matter of style):
    try:
        members[name].append(occ)
    except KeyError:
        members[name]=[occ]

But, assuming the use of the original data organization is externally
mandated, it's not too bad anyway, e.g.:
    x=0
    while members.has_key("%s%d"%(name,x)):
        x=x+1
    members["%s%d"%(name,x)] = occ

i.e., basically the same structure as if we were (more directly) using
the (name,x) pair as the index, except that, as per external mandate,
we turn that pair into a single string by using
    "%s%d" % (name,x)
wherever, in a more natural organization, we would instead use
    (name,x)
directly.

There are, of course, other ways to turn a string and a number into
a single string, but the % operator has the advantage of being
easily tailorable -- if whatever external agent is currently imposing
the strange "%s%d" format changes its mind and imposes an
even stranger "_%d_%s" or whatever, you're maximally prepared:
just the formatting-string itself changes, exactly as it should be
(in fact, you can take the formatting-string as an argument, &c).

You appear to focus on
    name+str(x)
as the canonical way to do what you're after, and it may be more
readable than format%(name,x), though never quite as much as
just the
    (name,x)
pair itself.  OK, whatever.  But surely having to match an externally
mandated format, if it's a frequent occurrence in your application
domain, happens with all sorts of oddball formats, not just the
simple "%s%d" one, no?  And there are no substantial cases, that
I can think of, to need this specific ability (apply the specific
"%s%d" format), in enough numbers to warrant special-casing.
Absent externally mandated formats, you'll be using the pair in
a most direct way (or imply it by moving to a more natural data
organization, such as a dictionary containing lists).


>     Exactly my point.  I don't like it but I'm not asking for it to be
> changed.  I'm just a little tired, in all of what, two days, of people
putting
> down another language for doing something which /they/ consider wrong.  I

Two days?  It must be _at least_ 20 years that people on Usenet are
putting down other languages (and operating systems, applications,
computers, etc) for what they consider wrong.  Would you have us put
them down for what we consider _right_?-)

You're the one that claims that Perl's concept of 'scalar' &c is OK because
that's the way human beings think.  Well, I have news for you: human beings
just love to squabble about anything and everything; we *ARE* primates,
after all, and why should we be any less quarrelsome than any baboon
troop...?!-)

> consider it wrong in Python not because I'd like to see different, but
because
> I was told Python doesn't have that ambiguity when it does, that it
doesn't do
> conversion, when it does, that it doesn't do things "automagically" when
it
> does.  I'm pointing out that it is just as ambiguious in its own way and
that
> I personally consider it wrong but, as I stated in one message, I will
learn
> to use that.

I think most responders strove to show that there is no ambiguity, no
(implicit or silent) conversion, no automagic, where you are deeply
convinced that there is each of these.  Your being convinced or otherwise,
of course, makes no difference to anything except yourself, and, in fact,
it *IS* true that very specific cases have been identified where some
conversion can happen AND lose significant information (I was the one
pointing out the long interger -> float case).

That Python has this specific wart does not mean that a language that
has analogous and worse ones in a thousand places is just the same,
of course:-).


Alex