Perl is worse!

[gbreed at cix.compulink.co.uk]

In article <slrn8o25nr.e7.grey at teleute.rpglink.com>, 
grey at despair.rpglink.com (Steve Lamb) wrote:

>     Define a variable to get the name space in there but you don't know 
> how it
> is going to be used later on.  a = None.  Now make it a list in a 
> concise
> manner.  
> 
> for x in range(10):
>   a.append(x)
> 
>     Whoops, can't do it.  It isn't a list.  So make it a list.
> 
> list(a)
> for x in range(10):
>   a.append(x)
> 
>     Whoops, can't do it.  None can't be transformed into a list.

No, and besides list() doesn't alter its arguments.  If you want an empty 
list, why not

a = []

?  You said it was only declared to "get the name space in there".

> for x in range(10):
>   if a:
>     a.append(x)
>   else
>     a = [x]
> 
>    All that because of type checking?  Jumping through 3 hoops just to 
> get
> done what should be a trivial matter.

No, it's trivial:

a = range(10)

Or, if a is already a list,

a = a + range(10)

And no, not because of type checking.  You said before:

"""
    Simply stated, main reason I don't do C, don't do Java, and dropped 
Pascal
so long ago, the frustration of not being able to take data of one "type" 
and
use it in a different context without jumping through 20 different loops
depending on the particular case.  To me it isn't char, int, longint, 
unsigned
or signed, strings or whatever, it is data.  Lists and hashes (and in 
Python,
tuples) are just structures of data.  What "type" that data is is 
completely
subjective and based on the context of the operation.  To me, a language 
that
understands that has the feature, not the language that refuses to.
"""

Well, we're not talking about the "type" of the data here.  We're talking 
about its structure.  None and [] have different structures, as do 1 and 
[1], [1,2,3] and [1,[2,3]].  All languages differentiate structures, and 
the very thought of not doing so gives me the willies.

So, we're talking about coercion of structures, not types.  The types have 
to be there to differentiate structures.  So, firstly, you think the list 
function should coerce a non-sequence into a list with a single entry.  
Well, you could do that in Python:

def list(var):
  try:
    return __builtins__.list(var)
  except:
    return [var]

But it doesn't happen by default.  So you use the list constructor, [], 
instead.  What's the problem?  There are some structures for which both 
operations are possible

>>> data = (1,2,3)
>>> list(data)
[1, 2, 3]
>>> [data]
[(1, 2, 3)]
>>> text = "abc"
>>> list(text)
['a', 'b', 'c']
>>> [text]
['abc']

In each case, [] changes the structure, list() doesn't.  In Python, 
changing "11" into 11 would also change the structure.  So it doesn't 
happen unless you want it to.  You have either

x = "11"
y = 22
z = int(x)+y # 33

or

x = "11"
y = 22
z = x+str(y) # 1122

Simply

x = "11"
y = 22
z = x+y

is ambiguous.  Different languages define it different ways.  That's fine, 
as far as the machine's concerned.  But a poor human being could misread 
it.  In fact, before this thread came up, I assumed Python coerced the int 
to a string, like Java and Visual Basic do.  You assumed it should do the 
opposite.  I think it's nice that the language doesn't let either of us be 
right, so that when we get it wrong we find out because an expection gets 
thrown, not because the data get corrupted.  You think otherwise, that's 
fair enough, but if the biggest objection to the language is that you have 
to use the occasional int() or [], well...

You could also define a new operator for string concatenation.  Different 
operators for differently typed results.  Oops, types again!

Yes, Python is also conservative about type conversions that don't change 
structure.  It would be nice for

(1,2,3)+[4,5,6]

to work.  It doesn't, that's what list() is for, I can live with it.


       Graham