Marko Rauhamaa wrote:
> What's the inherent difference between an attribute and a key.
Here is my bucket. The handle of the bucket is part of the bucket:
bucket.handle
The pieces of coal I carry in the bucket is part of its content:
bucket['coal']
Of course, we can blur the distinction between part of the object and the
object's content, if we so choose. As Lewis Carroll might have written
in "Through the Looking Glass" had he been a programmer:
‘When I use syntax,’ Humpty Dumpty said in rather a scornful tone,
‘it means just what I choose it to mean — neither more nor less.’
’The question is,’ said Alice, ‘whether you can make syntax mean so
many different things.’
’The question is,’ said Humpty Dumpty, ‘which is to be master —
that’s all.’
If anyone wants a language where the same syntax means radically different
things, or radically different syntax means the same thing, then you know
where to find Perl, PHP and Javascript *wink*.
But more seriously, as Humpty might have said, of course the designer is the
master (and there are good masters and bad masters...), and sometimes there
is good reason to use attribute syntax for content. Sometimes it isn't
clear what counts as part of the object and what counts as part of the
contents, e.g. record or struct like objects exist in that grey area. In
that case, it may be a reasonable design choice to use attribute notation,
as namedtuple does, for example. But you'll note the cost: namedtuple is
forced to use leading underscore method names as *public* parts of the API,
so that they don't clash with field names.
If Guido was more like Perl's designer, Larry Wall, Python might have grown
a "short cut" notation for keys, say mydict$key, but the proliferation
of "many ways to do it" (to paraphrase the Perl motto) has costs of its
own. It's harder to learn, read and understand Perl code than Python code,
simply because there's more syntax to learn, and more special cases to
understand.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
