More random python observations from a perl programmer

Neil Schemenauer nascheme at
Sat Aug 21 14:50:26 EDT 1999

I think you misunderstand the intention of my post.  I am not
trying to defend Python on point.  Python is not perfect.  I am
trying to give some information of why things are the way they
are and am trying to help a new user of the language understand

Is it really productive to keep repeating that length one tuples
in Python are weird?

Tom Christiansen <tchrist at> wrote:
>In comp.lang.python, 
>    nascheme at (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.

I don't deny that this is a gotcha.

> Why can python copy sequences of chars (1-byte strings)
>    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.

You are still confused.  Python does not copy anything
implicitly.  Read my other post about this.  Maybe the id()
function will help:

    >>> a = 'hello'
    >>> id(a)
    >>> b = a
    >>> id(b)

[on perl copying objects]
>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".

What happends when you have a large array and pass it to a
function?  This seems pretty inefficient.  If the array is not
copied then why are they so many rules about when something is
copied and when it is not.

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

Sorry, I didn't read you problem close enough.

[on del as a statement]
>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.

That undef() must be an interesting function to be able to modify
the binding of its caller.  You don't see a conceptual problem
with this?  Can user written functions do this too?


More information about the Python-list mailing list