Re: storing references instead of copies in a dictionary

[mk]

Calvin Spealman wrote:

To your actual problem... Why do you wanna do this anyway? If you want
to change the function in the dictionary, why don't you simply define
the functions you'll want to use, and change the one you have bound to
the key in the dictionary when you want to change it? In other words,
define them all at once, and then just d['1'] = new_f1. What is wrong
with that?

Well, basically nothing except I need to remember I have to do that.

Suppose one does that frequently in a program. It becomes tedious. I
think I will define some helper function then:

>>def helper(fundict, newfun):

.... fundict[newfun.func_nam e] = newfun
....

_If_ there were some shorter and still "proper" way to do it, I'd use
it. If not, no big deal.

For completeness:

def new_f1(arg):
return "NEW f1 " + arg
f1.func_code = new_f1.func_cod e

Don't use that unless you really have to and I nearly promise that you don't.

I promise I won't use it. :-) It seems like a 'wrong thing to do'.

[bgeddy]

mk wrote:

Calvin Spealman wrote:

>To your actual problem... Why do you wanna do this anyway? If you want
to change the function in the dictionary, why don't you simply define
the functions you'll want to use, and change the one you have bound to
the key in the dictionary when you want to change it? In other words,
define them all at once, and then just d['1'] = new_f1. What is wrong
with that?

Well, basically nothing except I need to remember I have to do that.

Suppose one does that frequently in a program. It becomes tedious. I
think I will define some helper function then:

>>def helper(fundict, newfun):

... fundict[newfun.func_nam e] = newfun
...

_If_ there were some shorter and still "proper" way to do it, I'd use
it. If not, no big deal.

>For completeness:

def new_f1(arg):
return "NEW f1 " + arg
f1.func_code = new_f1.func_cod e

Don't use that unless you really have to and I nearly promise that you
don't.

I promise I won't use it. :-) It seems like a 'wrong thing to do'.

Well it's probably totally "non pythonic" but this does what you want:

def f2(arg):
return "f2 "+arg

def f1(arg):
return "f1 "+arg

a={"1":"f1","2" :"f2"}
print [eval(x[1])(x[0]) for x in a.items()]
def f2(arg):
return "New f2 "+arg
print [eval(x[1])(x[0]) for x in a.items()]

Don't know if this is any use to you..

[mk]

def f2(arg):
return "f2 "+arg

def f1(arg):
return "f1 "+arg

a={"1":"f1","2" :"f2"}
print [eval(x[1])(x[0]) for x in a.items()]
def f2(arg):
return "New f2 "+arg
print [eval(x[1])(x[0]) for x in a.items()]

Neat trick, if probably dangerous in some circumstances. Anyway, thanks,
I didn't think of that.

Don't know if this is any use to you..

At least I learned something. :-)

[castironpi]

On Jul 17, 10:05*am, mk <mrk...@gmail.c omwrote:

def f2(arg):
* * return "f2 "+arg

def f1(arg):
* * return "f1 "+arg

a={"1":"f1","2" :"f2"}
print [eval(x[1])(x[0]) for x in a.items()]
def f2(arg):
* * return "New f2 "+arg
print [eval(x[1])(x[0]) for x in a.items()]

Neat trick, if probably dangerous in some circumstances. Anyway, thanks,
I didn't think of that.

Don't know if this is any use to you..

At least I learned something. :-)

You want consistent access to a changing variable. Wrap it in an
object:

>>a= Blank( )
a.ref= 'X'
a.ref

'X'

>>b= a
b.ref

'X'

>>a.ref= 'Y'
b.ref

'Y'

>>>

[bgeddy]

castironpi wrote:

On Jul 17, 10:05 am, mk <mrk...@gmail.c omwrote:

>>def f2(arg):
return "f2 "+arg
def f1(arg):
return "f1 "+arg
a={"1":"f1"," 2":"f2"}
print [eval(x[1])(x[0]) for x in a.items()]
def f2(arg):
return "New f2 "+arg
print [eval(x[1])(x[0]) for x in a.items()]

Neat trick, if probably dangerous in some circumstances. Anyway, thanks,
I didn't think of that.

>>Don't know if this is any use to you..

At least I learned something. :-)

You want consistent access to a changing variable. Wrap it in an
object:

>>>a= Blank( )
a.ref= 'X'
a.ref

'X'

>>>b= a
b.ref

'X'

>>>a.ref= 'Y'
b.ref

'Y'

My "old fashioned" programing paradigms think of this in terms of
"pointers", a throw back to my schooling in 'C'. I find this general
form of problem to be common across languages and in some ways hard to
express in python. The whole idea of labels bound to objects is quite
alien to traditional terminology. I find one of the main attractions of
python is this new mindset that the language makes you adopt - a
different set of tools are at hand for the old school programmer.

castironpi - please give an example of what you are thinking as I find
this interesting. preferably post some brief example code.

[bgeddy]

bgeddy wrote:

castironpi wrote:

>On Jul 17, 10:05 am, mk <mrk...@gmail.c omwrote:

>>>def f2(arg):
return "f2 "+arg
def f1(arg):
return "f1 "+arg
a={"1":"f1", "2":"f2"}
print [eval(x[1])(x[0]) for x in a.items()]
def f2(arg):
return "New f2 "+arg
print [eval(x[1])(x[0]) for x in a.items()]
Neat trick, if probably dangerous in some circumstances. Anyway, thanks,
I didn't think of that.

Don't know if this is any use to you..
At least I learned something. :-)

You want consistent access to a changing variable. Wrap it in an
object:

>>>>a= Blank( )
a.ref= 'X'
a.ref

'X'

>>>>b= a
b.ref

'X'

>>>>a.ref= 'Y'
b.ref

'Y'

My "old fashioned" programing paradigms think of this in terms of
"pointers", a throw back to my schooling in 'C'. I find this general
form of problem to be common across languages and in some ways hard to
express in python. The whole idea of labels bound to objects is quite
alien to traditional terminology. I find one of the main attractions of
python is this new mindset that the language makes you adopt - a
different set of tools are at hand for the old school programmer.

castironpi - please give an example of what you are thinking as I find
this interesting. preferably post some brief example code.

castironpi - please forgive the double post but my newsreader didn't
display your code correctly.. Doh !! Anyway - a nice way of addressing
the problem. However the OP's post revolved around having a rewritable
set of "labels" - which could be recorded at one time and when re
referenced the new definitions of those labels would be used. For
example a "collection " (list,dictionar y,tuple) could be made of these
"labels" and then the underlying code accessed by the labels changed. If
the code was now ran indirectly by referencing the list then the new
code would be ran. These building blocks are how parsers are built and
the basis of language.
I can see how you form two ways of addressing the variable but can't
figure how this fits the original problem. Please elaborate for my
ignorance.

EdH.

[John Machin]

On Jul 18, 10:36 am, bgeddy <[e-mail] vin.a.breakwrot e:
[snip]

the OP's post revolved around having a rewritable
set of "labels" - which could be recorded at one time and when re
referenced the new definitions of those labels would be used. For
example a "collection " (list,dictionar y,tuple) could be made of these
"labels" and then the underlying code accessed by the labels changed. If
the code was now ran indirectly by referencing the list then the new
code would be ran.

This notion is as dangerous and ludicrous as the COBOL ALTER verb.

These building blocks are how parsers are built and
the basis of language.

Huh?

[castironpi]

On Jul 17, 7:36*pm, bgeddy <[e-mail] vin.a.breakwrot e:

bgeddy wrote:

castironpi wrote:

On Jul 17, 10:05 am, mk <mrk...@gmail.c omwrote:
def f2(arg):
* * return "f2 "+arg
def f1(arg):
* * return "f1 "+arg
a={"1":"f1"," 2":"f2"}
print [eval(x[1])(x[0]) for x in a.items()]
def f2(arg):
* * return "New f2 "+arg
print [eval(x[1])(x[0]) for x in a.items()]
Neat trick, if probably dangerous in some circumstances. Anyway, thanks,
I didn't think of that.

>>Don't know if this is any use to you..
At least I learned something. :-)

You want consistent access to a changing variable. *Wrap it in an
object:

>>>a= Blank( )
a.ref= 'X'
a.ref
'X'
b= a
b.ref
'X'
a.ref= 'Y'
b.ref
'Y'

My "old fashioned" programing paradigms think of this in terms of
"pointers", a throw back to my schooling in 'C'. I find this general
form of problem to be common across languages and in some ways hard to
express in python. The whole idea of labels bound to objects is quite
alien to traditional terminology. I find one of the main attractions of
python is this new mindset that the language makes you adopt - a
different set of tools are at hand for the old school programmer.

castironpi - please give an example of what you are thinking as I find
this interesting. preferably post some brief example code.

castironpi *- please forgive the double post but my newsreader didn't
display your code correctly.. Doh !! Anyway - a nice way of addressing
the problem. However the OP's post revolved around having a rewritable
set of "labels" - which could be recorded at one time and when re
referenced the new definitions of those labels would be used. For
example a "collection " (list,dictionar y,tuple) could be made of these
"labels" and then the underlying code accessed by the labels changed. If
the code was now ran indirectly by referencing the list then the new
code would be ran. These building blocks are how parsers are built and
the basis of language.
I can see how you form two ways of addressing the variable but can't
figure how this fits the original problem. Please elaborate for my
ignorance.

EdH.

In the OP's post, we have:

def f1(): print 'f1'
def f2(): print 'f2'
funs= [ f1, f2 ]
def f1(): print 'new f1'

They wanted funs[ 0 ] to contain this new function / new definition
too.

Another language might permit:
def funs[ 0 ](): print 'new f1'

Python allows:

def f1(): print 'new f1'
funs[ 0 ]= f1

and

@rebind( funs, 0 )
def f1(): print 'new f1'

and

@rebind_named( funs, 'funA' )
def f1(): print 'new f1'

in the case funs was a dictionary or class or class instance.
Functions remain to be first class objects; their definition syntax is
merely restricted over normal assignments.

To access "whatever 'f1' is pointing to right now", the only way is
with eval, which you showed.

Spealman's solution can accomplish redefinition, but only provided
calling signature and closure, among others, don't change. If they
do, you have to reassign those, too, and possibly more:

>>dir( f )

[snip]
'func_closure', 'func_code', 'func_defaults' , 'func_dict', 'func_doc',
'func_globals', 'func_name'

Roughly the same in 3.0. It's an option.

These building blocks are how parsers are built and
the basis of language.

To address this, I observe altered references are easy for computers.
Suppose:

#--NOT PYTHON--
def f1(): print 'f1'
008902 f1: 0x008934
def f1(): print 'new f1'
008902 f1: 0x008938

'f1()' calls the function the address of which is stored at 008902 in
each case: f1 (at 008934) in the first case, and new f1 (at 008938) in
the second.

Python eliminates that combination from the syntax, which strengthens
object-name identity, at the cost of a slightly longer workaround
(a.ref= f1) for keeping names but changing objects. In this sense,
the only 'pointer' per se is the string name of an object, scoped by a
namespace-- eval( 'f1', spaceA ).

I delicately ask for an example in natural language and daily life in
which we change what object a name refers to, or hold that Python
conforms to natural language better than computer-native mutable
pointers and references.

[John Machin]

On Jul 18, 4:26*pm, castironpi <castiro...@gma il.comwrote:

I delicately ask for an example in natural language and daily life in
which we change what object a name refers to,

her, him, it, ... i.e. any pronoun

[bruno.desthuilliers]

On 17 juil, 15:56, mk <mrk...@gmail.c omwrote:

Calvin Spealman wrote:

To your actual problem... Why do you wanna do this anyway? If you want
to change the function in the dictionary, why don't you simply define
the functions you'll want to use, and change the one you have bound to
the key in the dictionary when you want to change it? In other words,
define them all at once, and then just d['1'] = new_f1. What is wrong
with that?

Well, basically nothing except I need to remember I have to do that.

Suppose one does that frequently in a program. It becomes tedious. I
think I will define some helper function then:

>>def helper(fundict, newfun):

... fundict[newfun.func_nam e] = newfun
...

_If_ there were some shorter and still "proper" way to do it, I'd use
it.

You're halfway there.

from functools import partial

callbacks = {}
register_callba ck = partial(helper, callbacks)

@register_callb ack
def f1(arg):
print "f1", arg

callbacks['f1']('ok')

@register_callb ack
def f1(arg):
print "new f1", arg

callbacks['f1']('ok')