Hrvoje Niksic writes:
> m...@distorted.org.uk (Mark Wooding) writes:
>
>>> So even if the globals() dictionary is custom, its __setitem__ method is
>>> *not* called.
>>
>> Fascinating. Thank you.
>
> In case it's not obvious, that is because CPython assumes the type for
> many of its internal or
On 11/16/2010 9:12 AM, Arnaud Delobelle wrote:
> Hrvoje Niksic writes:
>
>> m...@distorted.org.uk (Mark Wooding) writes:
>>
So even if the globals() dictionary is custom, its __setitem__ method is
*not* called.
>>>
>>> Fascinating. Thank you.
>>
>> In case it's not obvious, that is bec
m...@distorted.org.uk (Mark Wooding) writes:
>> So even if the globals() dictionary is custom, its __setitem__ method is
>> *not* called.
>
> Fascinating. Thank you.
In case it's not obvious, that is because CPython assumes the type for
many of its internal or semi-internal structures, and calls
Arnaud Delobelle writes:
> >>> exec "a=2" in d
> assigning 2 to 'a'
> >>> d['a']
> 2
>
> >>> exec "global a; a = 3" in d
> >>> d['a']
> 3
Oooh, now isn't that an interesting wrinkle? I've been careful (without
drawing attention) to restrict my arguments to variables inside
functions, largely be
Steven D'Aprano writes:
> > def foo():
> > l = []
> > for i in xrange(10):
> > (lambda j: l.append((lambda: i, lambda: j)))(i)
> > print [(f(), g()) for f, g in l]
>
> Here's a slightly less condensed version that demonstrates the same
> behaviou
Steve Holden writes:
> On 11/14/2010 8:29 AM, Emile van Sebille wrote:
> [...]
>> We all know that _everything_ is a disguised method call and we call the
>> disguised method call that resembles a statement where the LHS is
>> separated from the RHS by a single equals sign assignment.
>
> I think
On Sun, 14 Nov 2010 12:23:03 -0800, Steve Holden wrote:
> What method of a does the statement
>
> a = something
>
> call? I ask in genuine ignorance, and in the knowledge that you may
> indeed be able to point me to such a method.
I know the question wasn't directed at me, but here's my 2 c
On 11/14/2010 12:23 PM Steve Holden said...
On 11/14/2010 8:29 AM, Emile van Sebille wrote:
[...]
We all know that _everything_ is a disguised method call and we call the
disguised method call that resembles a statement where the LHS is
separated from the RHS by a single equals sign assignment.
Op 2010-11-14 21:23, Steve Holden schreef:
> What method of a does the statement
>
> a = something
>
> call? I ask in genuine ignorance, and in the knowledge that you may
> indeed be able to point me to such a method.
It wouldn't call a method of a. I'm not an expert in these matters, but
I
On 11/14/2010 8:29 AM, Emile van Sebille wrote:
[...]
> We all know that _everything_ is a disguised method call and we call the
> disguised method call that resembles a statement where the LHS is
> separated from the RHS by a single equals sign assignment.
I think your elided attempt to reconcile
On 11/13/2010 3:28 PM Mark Wooding said...
Steven D'Aprano writes:
On Sat, 13 Nov 2010 20:01:42 +, Mark Wooding wrote:
Some object types are primitive, provided by the runtime system;
there are no `internal' variables to be assigned in these cases.
You seem to be making up your own term
Dennis Lee Bieber writes:
> On Sat, 13 Nov 2010 23:14:22 +, Arnaud Delobelle
> declaimed the following in gmane.comp.python.general:
>
>
>> Two occurences of the name "a" belong to the same namespace
>>
> Pardon? By definition, any given namespace can have only one
> occurence of a
Steven D'Aprano wrote:
> Right website, wrong page :)
>
> http://effbot.org/zone/call-by-object.htm
D'oh. Thanks for the catch :)
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, 13 Nov 2010 22:22:00 +, Mark Wooding wrote:
> Challenge: explain the following code using only those concepts.
("those concepts" being name and value/object)
> def foo():
> l = []
> for i in xrange(10):
> (lambda j: l.append((lambda: i, lambda:
Steven D'Aprano writes:
> On Sat, 13 Nov 2010 21:42:03 +, Mark Wooding wrote:
>
> > Dave Angel writes:
> >
> >> No, an (=) assignment is always an assignment.
> >
> > No. In `foo[0] = bar' it's a method call in disguise.
>
> How does that imply that can't also be an assignment?
Is `splat
Dennis Lee Bieber writes:
> def swapFunc(a, b):
> return b, a
That's not what a `swap' function should do.
> > Alas, Python is actually slightly confusing here, since the same
> > notation `=' sometimes means assignment and sometimes means mutation.
>
> "=" means just one thing, a r
Steven D'Aprano writes:
> On Sat, 13 Nov 2010 20:01:42 +, Mark Wooding wrote:
> > Some object types are primitive, provided by the runtime system;
> > there are no `internal' variables to be assigned in these cases.
>
> You seem to be making up your own terminology here, or at least using
>
m...@distorted.org.uk (Mark Wooding) writes:
> Arnaud Delobelle writes:
>> I think I understand Python programs correctly using only the notions
>> of "name" and "value" (or object).
>
> Challenge: explain the following code using only those concepts.
>
> def foo():
> l = []
>
On Sat, 13 Nov 2010 14:37:44 -0800, Dennis Lee Bieber wrote:
> On Sat, 13 Nov 2010 16:29:19 +, m...@distorted.org.uk (Mark Wooding)
> declaimed the following in gmane.comp.python.general:
>
>
>> to a function argument /never/ affects the caller in Python. It's
>> simply not possible to writ
On Sat, 13 Nov 2010 21:42:03 +, Mark Wooding wrote:
> Dave Angel writes:
>
>> No, an (=) assignment is always an assignment.
>
> No. In `foo[0] = bar' it's a method call in disguise.
How does that imply that can't also be an assignment?
Of course, you're correct that it's not *necessaril
On Sat, 13 Nov 2010 20:01:42 +, Mark Wooding wrote:
> Terry Reedy writes:
>
>> On 11/13/2010 11:29 AM, Mark Wooding wrote:
>>
>> > Alas, Python is actually slightly confusing here, since the same
>> > notation `=' sometimes means assignment and sometimes means mutation.
>>
>> I disagree some
Arnaud Delobelle writes:
> m...@distorted.org.uk (Mark Wooding) writes:
>
> > Assignment /never/ binds. There is syntactic confusion here too,
> > since Python interprets a simple assignment in a function body -- in
> > the absence of a declaration such as `global' to the contrary -- as
> > indi
Dave Angel writes:
> No, an (=) assignment is always an assignment.
No. In `foo[0] = bar' it's a method call in disguise.
> It changes the item on the left hand side to refer to a new object.
Not necessarily. It could do anything at all depending on the type of
the recipient object.
-- [m
On Sat, 13 Nov 2010 05:50:40 -0800, alex23 wrote:
> Tracubik wrote:
>> why the integer value doesn't change while the list value do?
>
> http://effbot.org/pyfaq/why-are-default-values-shared-between-
objects.htm
Right website, wrong page :)
http://effbot.org/zone/call-by-object.htm
See also
m...@distorted.org.uk (Mark Wooding) writes:
> Assignment /never/ binds. There is syntactic confusion here too,
> since Python interprets a simple assignment in a function body -- in
> the absence of a declaration such as `global' to the contrary -- as
> indicating that the variable in question s
On Sat, Nov 13, 2010 at 5:46 AM, Tracubik wrote:
> hi all,
> i've this on python 2.6.6:
>
> >>> def change_integer(int_value):
> ... int_value = 10
> ...
> ... def change_list(list):
> ... list[0] = 10
> ...
> ... a = 1
> ... l = [1,1,1]
> ...
> ... change_integer(a)
> ... change_list(l)
On 2:59 PM, Mark Wooding wrote:
Tracubik writes:
def change_integer(int_value):
... int_value = 10
...
Alas, Python is actually slightly confusing here, since the same
notation `=' sometimes means assignment and sometimes means mutation.
You can tell which is which by looking at the l
On Sat, Nov 13, 2010 at 5:46 AM, Tracubik wrote:
> hi all,
> i've this on python 2.6.6:
>
def change_integer(int_value):
> ... int_value = 10
> ...
> ... def change_list(list):
> ... list[0] = 10
> ...
> ... a = 1
> ... l = [1,1,1]
> ...
> ... change_integer(a)
> ... change_list(l)
>
Terry Reedy writes:
> On 11/13/2010 11:29 AM, Mark Wooding wrote:
>
> > Alas, Python is actually slightly confusing here, since the same
> > notation `=' sometimes means assignment and sometimes means mutation.
>
> I disagree somewhat. An object is mutated by an internal assignment.
Some object
On 11/13/2010 11:29 AM, Mark Wooding wrote:
Alas, Python is actually slightly confusing here, since the same
notation `=' sometimes means assignment and sometimes means mutation.
I disagree somewhat. An object is mutated by an internal assignment.
"ll[0] = 1" assigns 1 to the 0 slot of ll.
"o.
Tracubik writes:
> >>> def change_integer(int_value):
> ... int_value = 10
> ...
> ... def change_list(list):
> ... list[0] = 10
[...]
> why the integer value doesn't change while the list value do?
Because in the first case you changed a variable local to the function,
and that v
alex23 writes:
> Tracubik wrote:
>> why the integer value doesn't change while the list value do?
>
> http://effbot.org/pyfaq/why-are-default-values-shared-between-objects.htm
Not the issue here.
The reason the OP sees a difference that there is only one way to pass
parameters in python. Ther
Tracubik wrote:
> why the integer value doesn't change while the list value do?
http://effbot.org/pyfaq/why-are-default-values-shared-between-objects.htm
--
http://mail.python.org/mailman/listinfo/python-list
33 matches
Mail list logo
