To start a new thread, I'm always trying to keep a list of some common
"gotchas" that beginning students run across when using Python, or
things that teachers should keep in mind when teaching with the
language. I have in mind commands that do not generate runtime errors,
but are likely to lead to
On Mon, Mar 28, 2011 at 3:23 PM, Michael H. Goldwasser wrote:
>
>
> Note well that the issue has changed since the original post. The
> question at the time concerned the following code
>
>
Not to quibble, but the issue of the *original* post had to do with
assignments (such as those below) dynam
In a message of Tue, 29 Mar 2011 13:27:20 +1300, Carl Cerecke writes:
>Yes. You are right. But so was I (on the second time around):
>
>a=1
>b=1
>
>a and b could refer to the same object or different objects with the same
>value. It depends on implementation details. I agree here.
>
>a=1
>b=a
>
>a
On Monday March 28, 2011, Laura Creighton wrote:
>In a message of Tue, 29 Mar 2011 09:59:40 +1300, Carl Cerecke writes:
>>Well, not really. Although I see what you are trying to say.
>
>>numbers (like strings) are immutable. There can ever be only one number 1
>>You can't ch
At the risk of boring the other readers
Yes. You are right. But so was I (on the second time around):
a=1
b=1
a and b could refer to the same object or different objects with the same
value. It depends on implementation details. I agree here.
a=1
b=a
a and b refer to the *same* object here
On Mon, Mar 28, 2011 at 5:02 PM, Laura Creighton wrote:
> Incorrect, I think. When I am talking about 'the same 'one' object',
> what I mean is not some sort of philosophical one-ness, some Platonic
> ideal of one, which like all the numbers, is a singleton, wherever it
> occurs in the univers
In a message of Tue, 29 Mar 2011 11:49:08 +1300, Carl Cerecke writes:
>--20cf307abcff67e7bc049f92c049
>Content-Type: text/plain; charset=ISO-8859-1
>
>Yes. Laura, you're correct. I'll try again:
>
>Massimo was trying to say that after:
>a = 1
>b = a
>
>b and a refer to *different* 'one's because ch
Yes. Laura, you're correct. I'll try again:
Massimo was trying to say that after:
a = 1
b = a
b and a refer to *different* 'one's because changing one of them (b += 2)
doesn't change the other.
This isn't true. They refer to the same 'one' object (regardless of python
implementation). b += 2 doe
In a message of Tue, 29 Mar 2011 09:59:40 +1300, Carl Cerecke writes:
>Well, not really. Although I see what you are trying to say.
>numbers (like strings) are immutable. There can ever be only one number 1
>You can't change a number to something else. If add 5 to 3, the number 3
>doesn't change,
On 29 March 2011 08:28, Massimo Di Pierro wrote:
>
> primitive types like integers behave differently
>
> >>> a = 1
> >>> b = a # b and a are two different 1s
> >>> b+=2
> >>> print a
> 1
>
>
>
Well, not really. Although I see what you are trying to say.
numbers (like strings) are immutable. Th
On Mon, Mar 28, 2011 at 1:29 PM, Laura Creighton wrote:
> In a message of Mon, 28 Mar 2011 11:19:45 PDT, kirby urner writes:
> >--===091573==
> >Content-Type: multipart/alternative; boundary=20cf303b3f9bfa4ea5049f8efcd
>
> >What I less understand is why g isn't just a *snap shot*
In a message of Mon, 28 Mar 2011 11:19:45 PDT, kirby urner writes:
>--===091573==
>Content-Type: multipart/alternative; boundary=20cf303b3f9bfa4ea5049f8efcd
>What I less understand is why g isn't just a *snap shot* of what was global
>at the time globals( ) ran.
Because you didn't
Good hearing from you John.
It's interesting to compare globals( ) with dir( ). That latter is affected
by
the new names in a for loop but doesn't reflect these changes until
later, whereas globals( ) raises an exception.
The globals dict seems an unusual beast. Interesting recursivity too.
>>
In python variables assigned to dict and list are always references.
>>> a = {}
>>> b = a # b and a point to the same dictionary
>>> b['key'] = 'value'
>>> print a['key']
value
primitive types like integers behave differently
>>> a = 1
>>> b = a # b and a are two different 1s
>>> b+=2
>>> pri
Hello,
Isn't the issue here simply that globals does not return a copy of the globals
dictionary, it returns THE actual globals dictionary. It's not some sort of
callable, it is the globals dictionary, period. There is no such thing as a
static dictionary, they are mutable, and this one changes
One of my Python students alerted me to this state of affairs.
I understand that what globals( ) returns will fluctuate as new names come
and go.
What I less understand is why g isn't just a *snap shot* of what was global
at the time globals( ) ran.
Now it's just a dictionary like any other (and
16 matches
Mail list logo
