storing references instead of copies in a dictionary

castironpi castironpi at gmail.com
Fri Jul 18 08:26:24 CEST 2008


On Jul 17, 7:36 pm, bgeddy <bge... at home.havin.a.break> wrote:
> bgeddy wrote:
> > castironpi wrote:
> >> On Jul 17, 10:05 am, mk <mrk... at gmail.com> wrote:
> >>>> 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,dictionary,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.



More information about the Python-list mailing list