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

Ben Wolfson rumjuggler at cryptarchy.org
Fri Jul 28 00:15:24 EDT 2000


On Fri, 28 Jul 2000 03:29:06 GMT, grey at despair.rpglink.com (Steve Lamb)
wrote:

>
>    Just playing around try this some time:
>
>a = None
>list(a)
>a = 1 
>list(a)
>a = 123
>list(a)
>a = "abc"
>list(a)
>
>    To me all of those could be converted into lists yet only the last one is.
>Why do I say that?  
>
>    None could be converted into an empty list.  None is nothing.  I fail to
>see how you can't populate a list with a single nothing.
>
>    1 is a single value.  I fail to see why that cannot be converted to [1]
>which is allowed, btw. 
>a = [1]
>a
>
>    123 is a single value.  I fail to see why that cannot be converted to
>[123] which, again, is allowed.  See above.

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.

>    "abc" could either be a single value or a sequence.  It is converted as
>["a", "b", "c"].  Of course, the same /could/ be said for the above.  However,
>let's play around with this one since it is the only one that works somewhat
>as expected in conversion.

_any_ sequence can be either a single value or a sequence.  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

>>> tuple(list(a))

to return ([(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.

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:

>>> some_variable = [X]

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

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?"

>a = "abc"
>a
>a = list(a)
>a = str(a)
>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 would be very surprised if I were appending  values to a
list, and, in the process of debugging, printed its contents to see what it
contained, and got one long undifferentiated string.

If you want concatenation, you can use reduce(), string.join(), or a
string's join() method (post 1.5.2).

-- 
Barnabas T. Rumjuggler

God will forgive me; that's his job.
 -- Heinrich Heine




More information about the Python-list mailing list