How do I declare global vars or class vars in Python ?

[Linuxguy123]

How do I do this in Python ?

#############################
declare A,B

function getA
return A

function getB
return B

function setA(value)
A = value

function setB(value)
B = value

main()
getA
getB
dosomething
setA(aValue)
setB(aValue)
############################

The part I don't know to do is declare the variables, either as globals
or as vars in a class. How is this done in Python without setting them
to a value ?

Thanks

 

[alex23]

The part I don't know to do is declare the variables, either as globals
or as vars in a class.  How is this done in Python without setting them
to a value ?

Generally, you can use the object None to indicate that something has
no value:

class Something(object):
def __init__(self, a=None, b=None):
self.a, self.b = a, b
def dosomething(self):
# manipulate self.a & self.b here

def main():
s = Something("value1", "value2")
s.dosomething()

 

[Bruno Desthuilliers]

Nick Craig-Wood a écrit :
(snip)

Note that in python we don't normally bother with getA/setA normally,
just use self.A, eg

class Stuff(object):
def __init__(self):
self.A = None
self.B = None
def main(self):
print self.A
print self.B
# dosomething
self.A = "aValue"
self.B = "aValue"
print self.A
print self.B


If you need (later) A to be a computed value then you turn it into a
property, which would look like this. (Note the main method is
identical to that above).

class Stuff(object):
def __init__(self):
self._A = None

Note that while you *can* do direct access to the implementation
attribute (here, '_A' for property 'A'), you don't *need* to so (and
usually shouldn't - unless you have a very compelling reason).

 

[Paddy O'Loughlin]

Note that while you *can* do direct access to the implementation attribute
(here, '_A' for property 'A'), you don't *need* to so (and usually shouldn't
- unless you have a very compelling reason).

Interesting. Why shouldn't you?
I haven't used the property() function before and probably have no
call to, but when you say "usually shouldn't", what is there against
it?

 

[Bruno Desthuilliers]

Paddy O'Loughlin a écrit :

Interesting. Why shouldn't you?
I haven't used the property() function
s/function/object/

before and probably have no
call to, but when you say "usually shouldn't", what is there against
it?

The case is that the whole point of using a computed attribute is to
perform some computation on the value. IOW, except for a couple corner
cases, only the accessors should directly access the implementation(s)
attributes(s).

And of course, like for any other GoldenRule(tm), it's not meant to be
blindly followed. It's just that most of the times, going thru the
accessors is really what you want - even from within the class code.

 

[Paddy O'Loughlin]

s/function/object/

Nice try, but what I wrote was what I intended to say:
http://docs.python.org/library/functions.html#property

For all I know I could have used property objects several times in modules

The case is that the whole point of using a computed attribute is to perform
some computation on the value. IOW, except for a couple corner cases, only
the accessors should directly access the implementation(s) attributes(s).

And of course, like for any other GoldenRule(tm), it's not meant to be
blindly followed. It's just that most of the times, going thru the accessors
is really what you want - even from within the class code.

Hmm, it doesn't seem to me like it's much of a big deal, for it to
described as anything like a "GoldenRule" or to advise against its
overuse.
You use it when its appropriate and don't use it when you it's not,
like any other feature.

Paddy

 

[Bruno Desthuilliers]

Paddy O'Loughlin a écrit :

Nice try, but what I wrote was what I intended to say:
http://docs.python.org/library/functions.html#property

Check by yourself:
['__class__', '__delattr__', '__delete__', '__doc__', '__get__',
'__getattribute__', '__hash__', '__init__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__set__', '__setattr__', '__str__',
'fdel', 'fget', 'fset']

Hmm, it doesn't seem to me like it's much of a big deal, for it to
described as anything like a "GoldenRule"

One could say the same for each and any of the usual GoldenRules(tm).

 

[Paddy O'Loughlin]

Check by yourself:

False

Using this, every single builtin function returns False. That's a
pretty limited definition to be being pedantic over, especially when
they are in the "Built-in Functions" section of the manual.

<property object at 0xb7cbc144>

I never said that calling it didn't return a property object
<type 'property'>

So it's a type.
I think I didn't make such a bad error on my part. My intent in what I
was saying was to indicate that I hadn't created a property type. It's
fair enough to consider type constructors as functions given how they
are listed as such by the python documentation.
I don't think that your correction was much help, unless you just want
to say that everything is an object. Maybe you'd be right, but it's
not much use to use the term that way, imo

['__class__', '__delattr__', '__delete__', '__doc__', '__get__',
'__getattribute__', '__hash__', '__init__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__set__', '__setattr__', '__str__', 'fdel',
'fget', 'fset']

Doesn't prove a whole lot. So types have attributes...
So do functions:.... pass
....['__call__', '__class__', '__delattr__', '__dict__', '__doc__',
'__get__', '__getattribute__', '__hash__', '__init__', '__module__',
'__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__',
'__setattr__', '__str__', 'func_closure', 'func_code',
'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name']

One could say the same for each and any of the usual GoldenRules(tm).

Not really. To do so would be over-generalising and not useful to discussion
I guess it's your pedantry that I'm questioning.
Something like "don't use goto's" works as a GoldenRule because it's
been observed that without it, people start using goto statements in
places where it's not really appropriate.
When you said that "[you] usually shouldn't [use properties] - unless
you have a very compelling reason", your tone implied that properties
are easy to misuse and tend to be.
Not being familiar with properties and seeing them as being pretty
harmless, I was intrigued by this, which is why I asked for an
explanation.
Your explanation seems to show that your tone was likely to be more
personal bias than any real issue with properties.

Paddy