Python variables are bound to types when used?

[pranab_bajpai]

So I want to define a method that takes a "boolean" in a module, eg.

def getDBName(l2):
....

Now, in Python variables are bound to types when used, right?

Eg.
x = 10 # makes it an INT
whereas
x = "hello" # makes it a string

I take it, the parameters to a function (in the above example "l2") are
bound in the definition, rather than as invoked.

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

and if I did,

if (l2 = "hello"): # would it become string?

and what if I never used it in the definition body?

Elucidate please.

 

[Fredrik Lundh]

So I want to define a method that takes a "boolean" in a module, eg.

def getDBName(l2):
...

Now, in Python variables are bound to types when used, right?

no. variables are bound to objects, and objects have types.

Eg.
x = 10 # makes it an INT

no. that binds the name "x" to an integer object.

whereas
x = "hello" # makes it a string

no. that (re)binds the name "x" to a string object.

I take it, the parameters to a function (in the above example "l2") are
bound in the definition, rather than as invoked.

not sure what you're saying here. when you call a function, each parameter
is bound to the object represented by the corresponding argument.

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

no. that queries the object to see if it's "true".

and if I did,

if (l2 = "hello"): # would it become string?

no. that's a syntax error; if you fix that, it queries the object to see
how compares itself to the given string object.

Elucidate please.

reset your brain:

http://effbot.org/zone/python-objects.htm

</F>

 

[Grant Edwards]

So I want to define a method that takes a "boolean" in a module, eg.

def getDBName(l2):
...

Now, in Python variables are bound to types when used, right?

Python doesn't have variables.

Python has objects of various types. You can bind 0 or more
names an object.

Eg.
x = 10 # makes it an INT
whereas
x = "hello" # makes it a string

No, not really. There is no "it" that's becoming different
types.

x = 10

creates an integer object with the value 10 and binds the name
"x" to it.

x = "hello"

creates a string object containing the value "hello" and then
unbinds the name "x" from the integer object and re-binds it to
the string object. [At that point, the integer object _may_
get deleted if it's not being used any longer (it may have had
multiple names).]

I take it, the parameters to a function (in the above example "l2") are
bound in the definition, rather than as invoked.

Not sure I understand the question. The function you defined
accepts a single object as a parameter. When the function is
invoked, that object has the local name "l2" bound to it

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

That doesn't affect the type of the object with the name "l2"
at all. It checks to see if l2 has a false value or not.
Examples of basic objects with false values are an iteger 0, a
floating point 0.0, an empty string "", an empty list [], an
empty tuple (), or an empty dictionary {}.

and if I did,

if (l2 = "hello"): # would it become string?

That's not legal python. I presume you mean

if l2 == "hello":

The expression

l2 == "hello"

checks to see if the object with the name "l2" is a string with
the value "hello". If the object you passed to the function is
a string object with the value "hello", that experession will
be true. The expression will be false for any object that
isn't a string, and false for any string object that doesn't
have the value "hello".

and what if I never used it in the definition body?

Then it doesn't get used.

 

[Simon Brunning]

So I want to define a method that takes a "boolean" in a module, eg.

def getDBName(l2):
...

Now, in Python variables are bound to types when used, right?

Python doesn't really have variables as such. It has objects, which
are typed, and names, which are not.

Eg.
x = 10 # makes it an INT

The name 'x' is now bound to an int.

whereas
x = "hello" # makes it a string

Now it's bound to a string.

I take it, the parameters to a function (in the above example "l2") are
bound in the definition, rather than as invoked.

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

and if I did,

if (l2 = "hello"): # would it become string?

and what if I never used it in the definition body?

Now you've lost me. Probably my problem - serves me right for posting
from the pub.

Elucidate please.

I'll allow a true Python Zen master to do that -
<http://effbot.org/zone/python-objects.htm>.

 

[Grant Edwards]

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

That doesn't affect the type of the object with the name "l2"
at all. It checks to see if l2 has a false value or not.
Examples of basic objects with false values are an iteger 0, a
floating point 0.0, an empty string "", an empty list [], an
empty tuple (), or an empty dictionary {}.

Oh, and a bool False, obviously.

 

[Kent Johnson]

So I want to define a method that takes a "boolean" in a module, eg.

def getDBName(l2):
...

Now, in Python variables are bound to types when used, right?

Eg.
x = 10 # makes it an INT
whereas
x = "hello" # makes it a string

You don't have it quite right. In each case, the name 'x' is bound to a value. The type is a property of the value, not of the name.

I take it, the parameters to a function (in the above example "l2") are
bound in the definition, rather than as invoked.

No, the parameter values are bound to the parameter names at the time of call. Again, it is the value that is typed, not the name.

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

No, this doesn't change the type of the value bound to l2, it just evaluates the value as True or False according to the rules here:
http://docs.python.org/ref/Booleans.html#Booleans

and if I did,

if (l2 = "hello"): # would it become string?

No; assuming you mean to compare l2 == "hello", this will call a special method of the object bound to l2, passing "hello" as a parameter. The result will be evaluated as True or False. The actual method called on l2 may be __cmp__ or __eq__.
http://docs.python.org/ref/customization.html

Kent

 

[Marc 'BlackJack' Rintsch]

So I want to define a method that takes a "boolean" in a module, eg.

def getDBName(l2):
...

Is that a 12 or l2?

Now, in Python variables are bound to types when used, right?

Eg.
x = 10 # makes it an INT
whereas
x = "hello" # makes it a string

No, think of `x` as a *name*. The name has *no* type. The objects you
bind to that name have a type. So 10 is an int and "hello" is a string.

I take it, the parameters to a function (in the above example "l2") are
bound in the definition, rather than as invoked.

If you invoke the function then the parameter is bound to an object. This
object has a type.

So, if I use "l2" thus:

if (l2): # only then does it make it a boolean?

Here `l2` is treated as a boolean. If it is an integer then 0 is false,
everything else is true, if it is a list, dictionary or string then an
"empty" object is false, everything else is true. Otherwise it depends on
the existence and return value of either a `__nonzero__()` or the
`__len__()` method. See the docs for details.

and if I did,

if (l2 = "hello"): # would it become string?

It would become a syntax error. No assignement allowed there.

and what if I never used it in the definition body?

Again: The objects have types, the names not. A string that is never used
remains a string.

Ciao,
Marc 'BlackJack' Rintsch

 

[sjdevnull]

reset your brain:

http://effbot.org/zone/python-objects.htm

Neat link.

Can you expand on this:

a type (returned by type(x)) ....
You cannot change the type.

Especially what's going on here:
.... pass
........ pass
....1

It looks to me like x is still referencing the same object (and still
has the "attr" attribute) but its type has changed. Is that not right?

 

[Steven D'Aprano]

Python doesn't have variables.

Python has objects of various types. You can bind 0 or more
names an object.

I frequently use "variable" as a synonym for "name" when talking about
Python code. Do people think I am wrong to do so?

 

[Robert Kern]

I frequently use "variable" as a synonym for "name" when talking about
Python code. Do people think I am wrong to do so?

It depends on context and audience. If you're talking about Python code
with other relatively experienced Pythonistas, no I don't think it's
wrong. When you're talking about Python versus other languages where
"variable" corresponds with "a possibly typed memory location", or
you're talking with someone who is coming from such a language, then
it's probably best to talk about names and objects. Such pedantry is
useful in the latter cases but not so much in the former.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Aahz]

I frequently use "variable" as a synonym for "name" when talking about
Python code. Do people think I am wrong to do so?

Wrong? No. Bad idea? Possibly, depending on context. I'm often using
"variable" in casual conversation -- it's hard to break the habit of
thirty years of programming! But I try very hard to stick with "name"
when I'm doing formal instruction.

 

[Diez B. Roggisch]

Neat link.

Can you expand on this:




Especially what's going on here:



... pass
...


... pass
...


1

It looks to me like x is still referencing the same object (and still
has the "attr" attribute) but its type has changed. Is that not right?

So what? That the flexibility of python allows for such a hack has
nothing to do with x being totally unaware of the type of the object it
points to.

You only access values by names pointing/refering to them. If they are
mutable, you can mutate them. If not (like strings, ints and floats),
you have to rebind the name with a new value. But none of these changes
what x is - and what not. Its a name, pointing to a value, and knows
nothing about what it is actually bound to.


Regards,

Diez

 

[sjdevnull]

....
So what? That the flexibility of python allows for such a hack has
nothing to do with x being totally unaware of the type of the object it
points to.

I'm still not understanding, maybe my question was unclear (and was
related to the writeup that was linked, I wasn't saying anything about
the relationships of names and objects).

I'm wondering what is meant by "you cannot change the type", and
whether I'm misunderstanding what is going on in my example when I say
"x.__class__=a". It looks to me like the type of the object that "x"
is referencing changes, but the URL implies that something else might
actually be happening. I'm not understanding the distinction.

 

[Fredrik Lundh]

Neat link.

Can you expand on this:

the page was written before the "type/class unification" in Python 2.2,
at a time where the word "type" had a stricter meaning (referring to C-
level types, not user-level classes).

in CPython 2.2 and later, you can in fact change the type under some
circumstances, as long as the internal structure (the "C-level type") is
identical. the types involved must (to quote the checkin messages):

- have the same basic size
- have the same item size
- have the same dict offset
- have the same weaklist offset
- have the same GC flag bit
- have a common base that is the same except for maybe the
dict and weaklist (which may have been added separately at
the same offsets in both types)
- both be heap types

this basically limits the feature to classes defined at the Python level
(just like before the unification); most attempts to use arbitrary types
will fail. e.g.
Traceback (most recent call last):
.... pass
....Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __class__ assignment: 'a' object layout differs from 'c'

I suppose it's time to add a footnote to the objects page...

</F>

 

[Tom Anderson]

Is it really a good idea to say that objects have names? Isn't it cleaner
to describe objects without any reference to names or variables or
whatnot, then introduce names, namespaces and references as tools for
working with objects? You go on to explain this clearly, but it's a bit of
a confusing way to start!

tom

PS Sorry to be following up to a message other than the one i'm actually
replying to - the original, i'm afraid, is an ex-message.

 

[sjdevnull]

the page was written before the "type/class unification" in Python 2.2,
at a time where the word "type" had a stricter meaning (referring to C-
level types, not user-level classes).

Gotcha. Thanks.

That writeup is definitely on my required reading list for new Python
programmers.