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

[Ben Wolfson]

On Fri, 28 Jul 2000 05:00:16 GMT, grey at despair.rpglink.com (Steve Lamb)
wrote:

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

Not explicitly.  But asking for list(1) to give [1], and list((1,3)) to
give [1,3] is equivalent.  Depending on how you look at it, in the first
case it takes a single element and returns it into a single-element list,
and in the second it takes a single element returns it with its type
changed to list, or in the first case it takes a non-sequence and returns
it a single-element sequence, and in the second it takes a sequence and
returns the list-equivalent of that sequence.

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

Yes, it does.  List returns the list-equivalent of the sequence passed as
its argument.  1 is not a sequence; it doesn't have a list equivalent.

>I mean, c'mon, why have list when you
>could just construct a for loop to use an append method?

You could, but that would be less efficient.

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

As has already been stated, "a" is a single-element sequence, as are [1]
and (1,).

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

Any _sequence_ can be a single element or sequence.
Any _single element_ can't be a single element or sequence.

all A is B != all B is A.

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

True, but to me, this isn't quirky at all, but precisely what I would
expect and entirely logical.

-- 
Barnabas T. Rumjuggler

In Xanadu did Ozymandias a stately edict once decree: "look upon my
Pleasure Dome, ye mighty, and despair!"
 -- David Zacuto