Passing arguments to function - (The fundamentals are confusing me)

[Gregory Piñero]

Re: Passing arguments to function - (The fundamentals are confusingme)

Thanks everyone. I understand now. Everything is a reference, all
that matters is whether I can go inside the "cubbyhole" and change
something. Immutables don't allow this.

So what if I do want to share a boolean variable like so:
<code>
sharedbool=True
class cls1:pass
cl=cls1()
cl.sharedbool1= sharedbool

sharedbool=Fals e
[color=blue][color=green]
>>cl.sharedbool 1[/color][/color]
True #but I wanted false!
</code>

My guess having read this threat would be to make a simple wrapper
class for a boolean so I'm changing something inside the object
instead of reassigning it?
<code>
class bigbool:
/t def __init__(self,t f):
/t/t self.val=tf
/t def setval(self,tf) :
/t/t self.val=tf
</code>
Is there an easier way?


-Greg

On 8/9/05, Rocco Moretti <roccomoretti@h otpop.com> wrote:[color=blue]
> Christopher Subich wrote:[color=green]
> > Rocco Moretti wrote:
> >[color=darkred]
> >> Variables in Python are names. They aren't the cubbyholes into which
> >> you put values, they are sticky notes on the front of the cubby hole.[/color]
> >
> >
> > +1 MOTW (Metaphor of the Week)[/color]
>
> Thanks, but please note it's not really mine - I've seen it somewhere
> else before. I thought it was from the website I linked earlier[1], but
> now I'm a little embarrased to find out that isn't, and I have no clue
> where it's from.
>
> [1] http://starship.python.net/crew/mwh/...jectthink.html
> --
> http://mail.python.org/mailman/listinfo/python-list
> [/color]


--
Gregory Piñero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com)

[Christopher Subich]

Re: Passing arguments to function - (The fundamentals are confusingme)

Gregory Piñero wrote:[color=blue]
> So what if I do want to share a boolean variable like so:[/color]

Well, the easiest way is to wrap it in a list:

mybool = [True]
mybool[0] = False
mybool[0] = True

and so on.

Alternately, what is this boolean attached to that's so significant?
Sharing an arbitrary boolean, without any context, is rather strange --
perhaps it would be best to include both the boolean and associated
context in a single, larger object.

Also, remember that Python functions can return more than one value,
through implicit tuple packing and unpacking. This greatly reduces the
need for C-like result = function(&other _result) - isms.

def myfunc():
return 1,2,3
(a,b,c) = myfunc()
a == 1
b == 2
c == 3

[Terry Reedy]

Re: Passing arguments to function - (The fundamentals are confusingme)


"Christophe r Subich" <spam.csubich+b lock@block.subi ch.spam.com> wrote in
message news:0S5Ke.5236 $3p.2192@bignew s3.bellsouth.ne t...[color=blue]
> Dennis Lee Bieber wrote:[color=green]
>> In a more simplistic view, I'd reverse the phrasing... The name
>> "x" is assigned to the object "y" (implying it is no longer attached to
>> whatever used to have the name)[/color][/color]

I agree that this is the more useful way to see it. I intentionally said
'useful' rather than 'correct' since I consider the former to be the way to
judge viewpoints. And I base the usefullness view on an informal (and yes,
unscientific) mental tabulation of newbie confusions posted to c.l.p over
several years. But better data could revise my judgment..
[color=blue]
> No, because that'd imply that the object 'y' somehow keeps track of the
> names assigned to it,[/color]

I disagree with your implication and see it the other way. To me, 'the
object is bound to a name' implies that the object can only be bound to
one name while the name could have many objects bound to it, which is the
opposite of the case.

Analogy: in an elementary school, students are assigned to (bound to) a
room. The name=>room binding is recorded in a list (the 'namespace',
alphabetical for lookup of names) in the principal's office. The rooms do
not have to have a list of the students assigned to them, even though one
could be derived from the master list, as one could

Put another way: 'the name is bound' implies pretty clearly that the name
is acted up, and it is that acting upon that makes the object a (new)
property of the name. Nothing need be done to the object itself. This is
even clearer if 'bound' is expanded to 'associated with object-fetch
information'. So 'x = y' means "associated name 'x' with the object-fetch
information that name 'y' is currently associated with."
[color=blue]
>The object is the property of the name, not vice versa.[/color]

I agree, and see the binding of the name (to the object, as explained
above) as that which sets the property.

Terry J. Reedy

[Terry Reedy]

Re: Passing arguments to function - (The fundamentals are confusingme)


"Gregory Piñero" <gregpinero@gma il.com> wrote in message
news:312cfe2b05 080909324b1929d b@mail.gmail.co m...[color=blue]
>Ahh, so it's a mutable thing. That makes sense that I can't change a
>mutable object and thus can't affect it outside of the function.[/color]

You of course meant immutable, but this is still confused. It is a
name-binding versus object mutation thing.
[color=blue]
> Does that mean Python functions aren't always byref,
> but are sometimes byval for nonmutables?[/color]

No, neither. Python functions calls are always by name binding. See my
first response. You are only about the 1000th or maybe 10000th person
confused by trying to apply inapplicable concepts to Python.

Terry J. Reedy

[Dennis Lee Bieber]

Re: Passing arguments to function - (The fundamentals are confusing me)

On Tue, 09 Aug 2005 13:39:08 -0500, Rocco Moretti
<roccomoretti@h otpop.com> declaimed the following in comp.lang.pytho n:
[color=blue]
> Christopher Subich wrote:[color=green]
> > Rocco Moretti wrote:
> >[color=darkred]
> >> Variables in Python are names. They aren't the cubbyholes into which
> >> you put values, they are sticky notes on the front of the cubby hole.[/color]
> >
> >
> > +1 MOTW (Metaphor of the Week)[/color]
>
> Thanks, but please note it's not really mine - I've seen it somewhere
> else before. I thought it was from the website I linked earlier[1], but
> now I'm a little embarrased to find out that isn't, and I have no clue
> where it's from.[/color]

I may not have been the first, but I've been using the simile of
Post-It Notes for Python for years now (since I typically run
X-NoArchive=Yes, Google won't have me -- though now that I've upgraded
to Agent 3.0 and nothing works the same, who knows)

The one time I didn't use that comparison, I got dinged (see
above where I discussed reversing the phrasing, so names "get assigned
to" object; to me that is putting the note ON the object, not that the
object suddenly knows about another name).
--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.ne tcom.com/> <[/color]

[Dennis Lee Bieber]

Re: Passing arguments to function - (The fundamentals are confusing me)

On Tue, 9 Aug 2005 15:18:39 -0400, Gregory Piñero <gregpinero@gma il.com>
declaimed the following in comp.lang.pytho n:

[color=blue]
> So what if I do want to share a boolean variable like so:
> <code>
> sharedbool=True
> class cls1:pass
> cl=cls1()
> cl.sharedbool1= sharedbool
>
> sharedbool=Fals e
>[/color]

[color=blue][color=green][color=darkred]
> >>cl.sharedbool 1[/color][/color]
> True #but I wanted false!
> </code>
>[/color]
Without the context for /why/ you want to share it, it is
difficult to guess...

Especially since, in your example, "cl.sharedbool1 " is an
INSTANCE variable -- instance variables are, by definition, supposed to
be unique to each instance.

If you want /all/ instances of cls1 to share a variable, you
make it a class variable. If you just want the class to be able to
access something outside of itself, you might use "global" declarations.

If you're going that route, you might also want to define the
class to have the shared variable as a property, so retrieval and
setting correctly access the shared item.

-=-=-=-=-=-=-=-=
sharedBoolean = False

class Sharing(object) :
def __init__(self):
pass
def _getSB(self):
global sharedBoolean
return sharedBoolean
def _setSB(self, nv):
global sharedBoolean
sharedBoolean = nv
return None
sharedBoolean = property(_getSB , _setSB)

s1 = Sharing()
s2 = Sharing()

print "Initial values"
print "sharedBool ean: ", sharedBoolean
print "s1: ", s1.sharedBoolea n
print "s2: ", s2.sharedBoolea n

sharedBoolean = True

print "Changed sharedBoolean itself"
print "sharedBool ean: ", sharedBoolean
print "s1: ", s1.sharedBoolea n
print "s2: ", s2.sharedBoolea n

s1.sharedBoolea n = "Not a Boolean!"

print "Changed s1.sharedBoolea n"
print "sharedBool ean: ", sharedBoolean
print "s1: ", s1.sharedBoolea n
print "s2: ", s2.sharedBoolea n
-=-=-=-=-=-=-=-=-=
Initial values
sharedBoolean: False
s1: False
s2: False
Changed sharedBoolean itself
sharedBoolean: True
s1: True
s2: True
Changed s1.sharedBoolea n
sharedBoolean: Not a Boolean!
s1: Not a Boolean!
s2: Not a Boolean!

You could also use the property() mode to make instances access
a class variable (probably need to give it a different name), and not
need the global declarations.
--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.ne tcom.com/> <[/color]