More random python observations from a perl programmer

[Tom Christiansen]

     [courtesy cc of this posting mailed to cited author]

In comp.lang.python, 
    nascheme at ucalgary.ca (Neil Schemenauer) writes:
:It is not too hard to remember what is mutable and what is not.

I'm not sure that this maps well to the way people think, considering
that everyone keeps telling me that it's "just something you have to
learn and/or get used to", which means it's not intuitive at first.
And that was my point of listing it as a gotcha.

:>    You can't use "in" on dicts.  Instead, you must use 
:In the Python philosophy, every expression should have an obvious
:meaning.  "in" in this case does not.  Perl has a different
:philosophy here.

To me it would be clear that it's a wasteful linear search of the
values, just as in a list it's a wasteful linear search of the elements.
The point wasn't a request for a feature, just an observation of a
conterintuitive point in something that would otherwise seem to be a
natural effect.

:The rule for determining if something is local is quite simple.
:If a variable is bound anywhere in a function then it is local
:unless declared global by the "global" statement.  

I understand.  But it's well, surprising that it's all context-dependent.
Not fun to look for.

:>    I feel that this hides the real test condition in a place
:>    it doesn't belong.
:
:On the up side, because assignment is a statement you can bind
:multiple names at once:
:
:	x = y = z = 0.0

That's not a side-effect of this.  You can do that in most languages,
including C and Perl and the like.  

:Again the semantics of such statements is not immediately obvious
:so Python avoids them.  They may be eventually added to the
:language though.

People keep saying this, but I've never understood why 

    a += b

isn't immediately obvious as

    a = a + b

:
:As I mentioned earlier, everything is a reference.  You just have
:to know what is mutable and what is not.  Lists, obviously from
:your example, are.

Alas, I'm pretty sure that this isn't how people think unless
they're trained to do so.  There's a reason that in Perl most
people still use 

    @a = (1,2,3);

not

    $a = [1,2,3];

It's because @a is a first-class array, and $a merely a reference
thereto.  Copying things not producing a copy is well, not what
non-serious programmers immediately think of.  Why can python copy
sequences of chars (1-byte strings) trivially:

    s = "this stuff"
    t = s

But as soon as you have a sequence of, oh, integers for example, you
can't use the same set-up.  Very odd.

:>    Often Python's error messages leave something to be desired.
:>    I don't know whether 
:
:I don't find them too bad.  I guess I don't use Perl much so I
:don't know what I am missing.  At least they are better than
:SEGV. :)

See my longer response to Tim Peters about this elsewhere in the group.
It's not exactly about this, but demos what I mean.

:>GOTCHA: (medium)
:>    All ranges are up to but *not including* that point.  So range(3)
:>    is the list [0,1,2].  This is also true in slices, which is the
:>    real gotcha part.  A slide t[2:5] does not include t[5] in it.
:
:This is explained quite well in the tutorial.  It makes a lot of
:sense once you get used to it.

As before, "once you get used to it" is the key point here.

:I think you are a bit confused by tuples.  In the first example
:you are looping over a tuple of length two.  In the second case
:you are looping over a string.  A length one tuple must end with
:a comma.  This is weird but necessary for the parser to tell the
:difference between a tuple and a parenthesized expression.

You said it yourself: this is weird.

:Again with the references. :)  Don't think references.

You can't avoid it.
:Does Perl really make a copy of a list every time you assign it
:to another variable?  How about other things like instances?

Yes, with 1st-class arrays (you say lists) and hashes (you say
dictoinaries).  But not with instances, which are always by definition
references, and suffer the same confusion.  That's why base types
are easier to use for many "accidental programmers".

:>    Slices in Python must be contiguous ranges of a sequence.
:>    In Perl, there's no such restriction.  
:Use a dictionary if you want this.

Huh?  How would I use a dictionary (don't you get tired of such a long
and non-intuitive word?) to do this:

    @a[3,7,4] = ("red", "blue", "green")
or
    @a[3,7,4] = @a[2,9,10];

:>    You can't slice dictionaries at all in Python.  In Perl, it's
:>    easy to slice a hash, and just as sensible.
:
:The semantics of this are not immediately clear.

Sure they are.  

    @hash{"red","blue","green"} = ("rojo", "azul", "verde")

is the same as 

    ($hash{"red"}, $hash{"blue"}, $hash{"green"}) =
	("rojo", "azul", "verde")

which is the same as:

    $hash{"red"}   = "rojo";
    $hash{"blue"}  = "azul";
    $hash{"green"} = "verde";


I'm only fibbing a little.  Assignments of slices look for overlap, just
like

    ($a, $b) = ($b, $a)

does.

:del is a statement.  It has to be so it can remove variable
:bindings.  

I *really* don't undertsand this. Why does Python have so many
"statements" compared with C or Perl?  What does this actually buy you?
I can remove variable bindings just fine with the undef() or delete()
functions in Perl, without needing to sacrifice an entire *statement*
in the grammar for this!  There must be something important that I'm
not understanding here, and I'd like to.

Oops, time's up.   Off to teach OO Perl at the Monterey conference. :-)

--tom
-- 
You know, by the time you get done with all this, the "Swiss Army
Chainsaw" is going to be more like a Swiss Army Tactical Nuke....  :-)
    --Brandon Allbery on perl in <1991Feb21.002412.20045 at NCoast.ORG>