Using eval, or something like it...

[r0g]

Hi There,

I know you can use eval to dynamically generate the name of a function
you may want to call. Can it (or some equivalent method) also be used to
do the same thing for the variables of a class e.g.

class Foo():
bar = 1
gum = 2

mylist = ['bar','gum']

a = Foo()
for each in mylist:
a.eval(each) = 999
If so, what is the proper syntax/method for this.

Regards,

Roger.

[George Sakkis]

On Nov 20, 6:54*pm, r0g <aioe....@techn icalbloke.comwr ote:

It would seem from this setattr function that the proper term for these
is 'attributes'. That for many years I have considered pretty much any
named thing that may vary a 'variable' might be at the root of the
problem here as it's a very un-specific term...

Exactly, refrain from using the term "variable", or "value" for that
matter, in Python context as they are notorious for causing more
trouble than they deserve..

So I gather you are saying that the fragments of state within a class
are so distinct from ordinary common or garden variables that it is
incorrect to think of them, or describe them, as variables, much like
quarks should not really be regarded as distinct particles, and they
should only be thought of and described as 'attributes' to avoid confusion?

Is this correct enough for me to avoid the aforementioned bug pile?

No, a class can have attributes just like a instance can, and you can
use setattr() to set an attribute for a class just like you do it for
instances:

class Foo():
bar = 1
gum = 2

>>setattr(Foo , 'bar', 3)
Foo.bar

3

George

[Steven D'Aprano]

On Thu, 20 Nov 2008 11:12:56 +1000, James Mills wrote:

DON'T USE eval!

If you're going to make a sweeping generalization like that, at least
offer some alternatives, and explain why eval should be avoided.
Otherwise your advice is just cargo-cult programming.

eval is not inherently bad, it does have its uses. The timeit module, for
instance, uses eval. But in general, there are better, faster ways of
doing things than eval.

In my own testing, I find that eval('code') causes a serious speed hit:
it's about ten times slower than just executing code directly.

eval also is a security risk, if you can't trust the code you are passing
to it. You can *try* to mitigate those risks by filtering the string, and
by setting the globals and locals arguments to eval, but you can't
entirely remove the risk. The best way to remove the risk is to never use
eval on untrusted code.

--
Steven

[r0g]

Scott David Daniels wrote:

r0g wrote:

>...
A class is like a template which combines a complex data type (made from
a combination of other data types) and the methods that operate on that
data type.

You generally don't work with classes directly but you make instances of
them, each instance has it's own internal state and methods, initially
these are the same as the templates but can be changed or overridden
without affecting the state of any other instances you might have.

Take the tutorial and do experiments.
The attribute lookup checks the class _and_ the instance (with the
instance over-riding the class). Make sure you can explain the output
from this:

class Demo(object):
non_template = 43

d = Demo()
print d.non_template
Demo.non_templa te = 44
print d.non_template
d.non_template = 45
print d.non_template
Demo.non_templa te = 46
print d.non_template

Once you can do that, explain this:
class Demo2(object):
holder = []

e = Demo2()
print e.holder
Demo2.holder.ap pend(44)
print e.holder
e.holder.append (45)
print e.holder
Demo2.holder.ap pend(46)
print e.holder

# clue:
print d.holder is Demo.holder

Well that all makes sense what with Pythons' 'only copy explicity' and
lists being mutable and indeed, as you intuited, I did run into issues
with this within days of starting to learn Python! Ever since I have
been using copy.deepcopy() when I need to get the results described
above i.e. to ensure each instance is fully independent of all the others.

I hadn't really appreciated the consequences of this till now though
e.g. that an instance might do a = a + 1 without affecting it's siblings
but that b.append("fish" ) would affect b for everyone. I don't know if I
will find any uses for that kind of behaviour but it doesn't hurt to
understand it :-)

Isn't Python's behaviour a little peculiar in this respect though,
compared to classes in other languages? i.e. Are instances in other OO
languages like Smalltalk, C++ fully independent copies or do their
attribute names just point to one common object until reassigned like in
python? (Or have I still not it at all?!)

>Is this correct enough for me to avoid the aforementioned bug pile?

Also then, what _is_ an "instance variable" ?

Well, when you use the term variable, I suspect that you think it
represents storage. OK, it kind of does, but only in the sense

Well you used the term "instance variable" in your reply so I was just
asking if there _is_ an actual thing known as "an instance variable" in
Python and if so what it is/does.

Thanks for your reply and examples BTW (I think) they are helping me
clarify my understanding of python classes and the language used to
describe them.
Roger.

--Scott David Daniels
Sc***********@A cm.Org

[Joe Strout]

On Nov 21, 2008, at 8:58 AM, r0g wrote:

I hadn't really appreciated the consequences of this till now though
e.g. that an instance might do a = a + 1 without affecting it's
siblings
but that b.append("fish" ) would affect b for everyone. I don't know
if I
will find any uses for that kind of behaviour but it doesn't hurt to
understand it :-)

Yes, it's critical to understanding any OOP language.

Isn't Python's behaviour a little peculiar in this respect though,
compared to classes in other languages?

No, it's exactly the same.

i.e. Are instances in other OO
languages like Smalltalk, C++ fully independent copies or do their
attribute names just point to one common object until reassigned
like in
python? (Or have I still not it at all?!)

You're still a little confused, perhaps. But I think this will clear
it up:

<http://www.strout.net/info/coding/valref/>

I wrote this to help people in exactly your situation, so please do
give me feedback and let me know how it did or didn't help.

Thanks,
- Joe

[Scott David Daniels]

I forgot to include a few cases:

(1) Inspired by your calling the class attributes "templates" :
class Demo3(object):
pass

d = Demo3()
print d.non_template # raises exception
d.non_template = 45
print d.non_template
print Demo3.non_templ ate # raises exception
Demo3.non_templ ate = 44
print d.non_template
print Demo3.non_templ ate # raises exception
del d.non_template
print d.non_template
del d.non_template # raises exception
print d.non_template
del Demo3.non_templ ate
print d.non_template # raises exception

All the above to demonstrate the class storage and instance storage
are separate.

(2) Trickier stuff involving sharing:
class Demo4(object):
common = []

g = Demo4()
h = Demo4()
g.common.append ('a')
print g.common, h.common, Demo4.common
g.common = g.common
Demo4.common = Demo4.common + ['b']
h.common = h.common
x = Demo4()
g.common.append ('c')
h.common.append ('d')
x.common.append ('e')
print g.common, h.common, Demo4.common, x.common

Thanks for your reply and examples BTW (I think) they are helping me
clarify my understanding of python classes and the language used to
describe them.

They are meant to point out that you need to read language definitions
carefully, or you will breeze by thinking you understand something you
really do not understand. Python provides a great way to experiment
with things you think you get; try "corner cases" to make sure you
know what is going on.

--Scott David Daniels
Sc***********@A cm.Org

[r0g]

Scott David Daniels wrote:

I forgot to include a few cases:

(1) Inspired by your calling the class attributes "templates" :

I did no such thing, I likened classes to templates and as far as I can
tell they are _like_ templates albeit dynamic ones.

class Demo3(object):
All the above to demonstrate the class storage and instance storage
are separate.

I see that.

(2) Trickier stuff involving sharing:
class Demo4(object):

Yeah no s*** that's trickier! Still haven't quite wrapped my head round
it yet even after reading the 'language definitions carefully' (well
http://www.python.org/doc/2.5.2/tut/node11.html at least) although I am
a bit clearer about the difference between class attributes and instance
variables. Time to go rewrite some crappy old code!

They are meant to point out that you need to read language definitions
carefully, or you will breeze by thinking you understand something you
really do not understand.

One of the things I love about Python is how it allows you to just
breeze by on intuition alone! It makes it immediately (and
incrementally) useful in the real world and I've been ableto built up a
great little library of scripts as I've learned. Having said that I
appreciate bigger projects require a deeper understanding which is why I
hang out here and occasionally ask dumb questions. Thankfully from time
to time clever bods like you will spot and point out the gaps in my
knowledge.

Cheers,

Roger.