I've suggesting seeing 8 as a name only briefly, temporary gestalt
switch, then go back to seeing it as a literal, kind of like a name
in that you can do dot notation on it, i.e. there's an underlying
object that's responsive to these triggers (like 8 .__add__(5)
instead of just 8 + 5). But is the underlying object "anonymous"?
It has a memory location:
>>> id(8)
12015636
>>> id('8')
13259744
And I'm able to refer to it. I didn't make up a name for it, like
eight, because I didn't need to, it's already permanently
accessible through 8.
It's more like an already assigned global in that it'll never go
out of scope.
It's available as a literal and is in that sense a spoken-for,
pre-named name, but we call it a literal, leaving name to
mean what the programmer makes up, following those
rules you mention (and so "variable" in the sense of being
a user-defined alphanumeric string, not in the sense of
being "a container of varied contents some of which is
dumb data like 8" -- 8 is not dumb, and assignment is
assignment, sharing accessibility to objects in memory).
What I'm working against is the C picture of 8 as "dumb data"
(objects not yet invented, though struct is the prototype for
a class definition, evolves to C++, with C# more deriving from
Java in a lot of ways -- which in turn learns from C++ no?
-- so I tend to include Java when I say "C family").
When I look at x = 8 and go "x is a variable and 8 is data"
then I'm working against Python's "everything is an object"
paradigm. By momentarily seeing 8 as a kind of name, you
get the sense that x = 8 and x = Rod(color="orange") aren't
two different kinds of assignment, are both passing (cloning)
a sticky note that points to an object.
Kirby
On Thu, May 8, 2008 at 10:08 PM, John Posner <[EMAIL PROTECTED]> wrote:
>
>> Partly why it's misleading to speak of names as variables is
>> that shoptalk tends to prevent us from seeing 8 as the *name*
>> of an immutable object, one for which the name is hardwired
>> (but feel free to bind, or assign, other not-spoken-for names
>> to the same object).
>
> I don't see the advantage of thinking of "8" as a name. It's just some
> syntax that creates an unnamed object. In that sense, all of these are
> similar:
>
> 8
> 8 + 3
> Rod(length = 9, color = 'blue')
>
> In all these cases, the resulting object gets a name only if it's the RHS of
> an assignment. If not, the object disappears (from the user's viewpoint,
> anyway) as soon as the containing statement/expression is executed.
>
> Also, what do you say to the student who points out that "8 is a name"
> violates the rule that Python names must begin with a letter or underscore?
>
> -John
>
>
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
