Antoon Pardon wrote:
> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
(snip)
>>>>It can only take you so far. Now it's time you know the truth: there are
>>>>*no* 'variables' in Python (hence the term 'binding').
>>>
>>>
>>>That depends on what you want to mean with the term. IMO 'variables'
>>>in python behave sufficiently similar as in other languages
>>
>>Which ones ? C ? or Lisp ? Or Haskell ?
>
>
> Whatever, if both C and Lisp can both talk about variables, I don't
> see why python can't
Guess where the term "binding" comes from.
>
>>>to use
>>>the term.
>>
>>IYO.
>
>
> So? The statement that python doesn't has variables is just your opinion.
The statement that "Python doesn't has variables" is meant to emphasis
the very difference between C-like variables and Python bindings.
>
>>>>What you really have is (somewhat simplified, of course) a dict with
>>>>names as keys and objects references (think of 'smart' pointers) as
>>>>values.
>>>
>>>
>>>That is just an implementation issue.
yes, your favourite argument ever.
>>> Nothing prevents variables to
>>>be associated with an index in a list.
>>
>>Do you understand what "somewhat simplified" means ?
>
>
> Not the difference between a list and a dictionary.
You don't understand the difference between a list and a dict ?
FWIW, the module and the classes namespaces are really implemented with
dicts. Functions namespaces are not IIRC, but I can't find the link no more.
>
>>>>So the name doesn't 'hold' anything - it's really nothing more
>>>>than a name.
>>>
>>>
>>>In a language like C the name doesn't hold anything either.
>>
>>Yes : it holds type and storage class informations too.
>
>
> If you want so. But that is totally irrelevant for considering
> something as a variable or not.
This is relevant when talking about the difference between C variables
and Python bindings.
> If someone would wish to extend
> python with a type system,
In case you don't know, it already has one.
>
>>>The name is just a way for refering to a memory space which
>>>will hold something.
>>
>>The name is a symbolic name for a memory address in which bits will be
>>stored (and the type information is used to know how to interpret the
>>bits at this address - I leave storage class problems aside). There's a
>>direct translation from symbolic name to memory address to bits.
>
> That doesn't need to be. A C-implementation could use directories.
"could", yes. But I'm not talking about language grammar.
>>Indeed. Now could you tell us what was your point, exactly ?
>
> Just showing that the object not knowing which identifiers
> it is bound to is irrelevant.
Someone in this thread used a 'post-it' metaphor that more or less
implied that the name was 'post-it'ed' on the object. Which is not the
case. Hence my precision on this.
And I still fail to get the whole point of your post.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
