Perl is worse! (was: Python is Wierd!)

[Steve Lamb]

On Fri, 28 Jul 2000 04:15:24 GMT, Ben Wolfson <rumjuggler at cryptarchy.org> wrote:
>I would never, personally, have expected list(123) to return a list
>containing only the element 123.  After all, that isn't how it works with
>_any_ other data type.

    Well, considering it doesn't work with most other data types, that isn't
unexpected, isn't it?  

>_any_ sequence can be either a single value or a sequence.

    Right, any sequence.  You said it, remember it, I'll get back to that.

>The fact that list() (and tuple()) only work on objects that actually have a
>sequence mapping makes a lot of sense and, to me, resolves the ambiguity in
>precisely the way I would expect.

>>>> a = (1,3,'5')

>a is a single value.  It's a tuple.  If list() took single values and made
>them into single-element lists, and tuple() worked accordingly, I would
>expect

    No, a is a pointer to a tuple and the tuple contains three values.  A
tuple is just an immutable list.  I'm not sure why anyone would want that, but
hey, I'm sure there's a reason along there somewhere.  I see three valies, 1,
3 & 5.

>To have list() and tuple() behave one way when given non-sequence
>arguments, and another when given sequence arguments, rather odd for two
>reasons.

    I never said that.

>Firstly, it's unnecessary.  If I have a single value in X, and I want to
>make it a single-element list, there's a way to do that:

    Really?

>>>> some_variable = [X]

    Seems counter intuative, doesn't it, list() could take that single value
and make it a single item in a list.  I mean, c'mon, why have list when you
could just construct a for loop to use an append method?

>That is how you construct single-element lists.  list(), as its docstring
>clearly states, creates a list from a sequence.

    You're right.  It does. 
   
>Secondly, it's counterintuitive.  You say "all of those can be converted
>into lists"; I look at 1 and think, "what is the list equivalent of an
>integer?"

    That is because you're thinking in terms of types and not just data.  It
is a single element, nothing more.

    Ah, but getting back to that point I said to remember.

foo = "a"
foo = list(foo)

    foo is not ['a'].  It took a single element and made it a list.  So we now
know that a single element has a sequence.  Here is another sequence of a
single element.

foo = 1
foo = list(foo)

    Error.  Single element sequence.  Remember, any sequence can either be a
single value or a sequence.  Yet here we have a single value denied.  Quirks
abound.

>>    a is now "['a', 'b', 'c']".  Which means we split a string up when
>>converting to list but don't concatinate on the way back. 

>Why should str(['a','b','c']) == str(['abc']) == str(['ab','c']), etc?  The
>str() function doesn't know that its argument was originally constructed
>from a string.

    I never said that, did I?  No.  Didn't I go on to state that I wouldn't
expect it to work because going down the scale from structures down to simple
data is hard.  It would be like trying to stuff a directory into a list.  
Going from more complex to something simpler is always going to have some
problems in implementation.  I was just pointing out that, as with anything, 
there are quirks in the language that one must learn.

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------