Re: [Tutor] @property for old style classes vs new style classes

[monik...@netzero.net]

I figured out why you have var in instance __dict__. 
It was after you added it. But why var is in class __dict__?
Does @property make it a class attribute?
Thank you
Monika

-- Original Message --
From: Steven D'Aprano 
To: tutor@python.org
Subject: Re: [Tutor] @property for old style classes vs new style classes
Date: Fri, 16 Sep 2016 02:57:12 +1000

On Thu, Sep 15, 2016 at 04:40:22AM +, monik...@netzero.net wrote:

> Could somebody please explain what is going on for old style classes for the 
> below code:

The important part is that the descriptor protocol doesn't get used for 
old style classes. If that statement means something to you, that's 
great, otherwise please ask. So in an old-style class:


> class GetSet():
> 
> def __init__(self, value):
> self.attrval = value
> 
> @property
> def var(self):
> print "getting the var attribute"
> return self.attrval
> @var.setter 
> def var(self,value):
> print "setting the var attribute"
> self.attrval = value

At this point, you have a class GetSet, with a class attribute:

GetSet.var

which is a property object. Now let's make an instance:

> me = GetSet(5)
> me.var = 1000

At this point, the instance now has an instance attribute:

me.var

which is the int 1000. So there are now TWO attributes called "me", 
living in different scopes:

me.__dict__['var'] = 1000  # in the instance

GetSet.__dict__['var'] = property object


Remember that attribute look-ups normally look in the instance __dict__ 
before the class __dict__.


> print me.var
> del me.var
> print me.var

The first print looks for 'var' in the instance, finds it, and prints 
1000. Then the del command looks for 'var' in the instance, finds it, 
and deletes it. Then finally the second print looks for 'var' in the 
instance, *doesn't* find it there (because it has been deleted), so it 
looks in the class, and finds GetSet.__dict__['var'] which is a property 
object.

At this point, things get a bit mysterious. According to the 
documentation, Python ought to print something like:



since the descriptor protocol doesn't run for old-style classes. But 
apparently it does *partly* run, because the property object's __get__ 
method is invoked, which calls the getter method that you defined.


> Output:
> 1000
> getting the var attribute
> 5


So there is a part mystery here. As far as I can tell, the documentation 
suggests that the output should be:

1000


rather than what you got.




-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


15 Actors Who Are Gay - No. 12 Will Shock Women
trendytribune.com
http://thirdpartyoffers.netzero.net/TGL3241/57db177b8815a177b1d3dst03duc
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] @property for old style classes vs new style classes

[monik...@netzero.net]

For both old and new classes I have var only in GetSet class, but not in 
instance me. Why?
print me.__dict__
print GetSet.__dict__

{'attrval': 5}

{'__weakref__': , '__doc__': None, 
'__module__': '__main__', '__init__': , 
'__dict__': , 'var': }
>>> 

Thank you very much
Monika

-- Original Message --
From: Steven D'Aprano 
To: tutor@python.org
Subject: Re: [Tutor] @property for old style classes vs new style classes
Date: Fri, 16 Sep 2016 02:57:12 +1000

On Thu, Sep 15, 2016 at 04:40:22AM +, monik...@netzero.net wrote:

> Could somebody please explain what is going on for old style classes for the 
> below code:

The important part is that the descriptor protocol doesn't get used for 
old style classes. If that statement means something to you, that's 
great, otherwise please ask. So in an old-style class:


> class GetSet():
> 
> def __init__(self, value):
> self.attrval = value
> 
> @property
> def var(self):
> print "getting the var attribute"
> return self.attrval
> @var.setter 
> def var(self,value):
> print "setting the var attribute"
> self.attrval = value

At this point, you have a class GetSet, with a class attribute:

GetSet.var

which is a property object. Now let's make an instance:

> me = GetSet(5)
> me.var = 1000

At this point, the instance now has an instance attribute:

me.var

which is the int 1000. So there are now TWO attributes called "me", 
living in different scopes:

me.__dict__['var'] = 1000  # in the instance

GetSet.__dict__['var'] = property object


Remember that attribute look-ups normally look in the instance __dict__ 
before the class __dict__.


> print me.var
> del me.var
> print me.var

The first print looks for 'var' in the instance, finds it, and prints 
1000. Then the del command looks for 'var' in the instance, finds it, 
and deletes it. Then finally the second print looks for 'var' in the 
instance, *doesn't* find it there (because it has been deleted), so it 
looks in the class, and finds GetSet.__dict__['var'] which is a property 
object.

At this point, things get a bit mysterious. According to the 
documentation, Python ought to print something like:



since the descriptor protocol doesn't run for old-style classes. But 
apparently it does *partly* run, because the property object's __get__ 
method is invoked, which calls the getter method that you defined.


> Output:
> 1000
> getting the var attribute
> 5


So there is a part mystery here. As far as I can tell, the documentation 
suggests that the output should be:

1000


rather than what you got.




-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


Do This Before Bed Tonight to Burn Belly Flab All Night Long
Flat Belly Overnight
http://thirdpartyoffers.netzero.net/TGL3241/57db0db4a9dedb31f3bst04duc
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] @property for old style classes vs new style classes

[monik...@netzero.net]

Thank you both for your explanations but they were too difficult for me to 
understand.
What is descriptor protocol? Can you please explain? 
I checked for var in both instance and class __dict__ but it was only in class, 
not in the instance. I checked for it after I instantiated me, before deletion. 
So now the post explaining it to me does not make a full sense.
So it seem to me that the class on udemy did not explain very well how this 
@property works (they talked only about new classes). Now after reading the 
posts several times I feel I understand less how it works. 
Could somebody please explain how @property works in new classes? What is going 
on behind the scenes? And then how in comparison with old classes? I will 
reread the posts again and maybe I will understand it better. Please explain in 
simple English. :)
Thank you very much
Monika
-- Original Message --
From: Steven D'Aprano 
To: tutor@python.org
Subject: Re: [Tutor] @property for old style classes vs new style classes
Date: Fri, 16 Sep 2016 02:57:12 +1000

On Thu, Sep 15, 2016 at 04:40:22AM +, monik...@netzero.net wrote:

> Could somebody please explain what is going on for old style classes for the 
> below code:

The important part is that the descriptor protocol doesn't get used for 
old style classes. If that statement means something to you, that's 
great, otherwise please ask. So in an old-style class:


> class GetSet():
> 
> def __init__(self, value):
> self.attrval = value
> 
> @property
> def var(self):
> print "getting the var attribute"
> return self.attrval
> @var.setter 
> def var(self,value):
> print "setting the var attribute"
> self.attrval = value

At this point, you have a class GetSet, with a class attribute:

GetSet.var

which is a property object. Now let's make an instance:

> me = GetSet(5)
> me.var = 1000

At this point, the instance now has an instance attribute:

me.var

which is the int 1000. So there are now TWO attributes called "me", 
living in different scopes:

me.__dict__['var'] = 1000  # in the instance

GetSet.__dict__['var'] = property object


Remember that attribute look-ups normally look in the instance __dict__ 
before the class __dict__.


> print me.var
> del me.var
> print me.var

The first print looks for 'var' in the instance, finds it, and prints 
1000. Then the del command looks for 'var' in the instance, finds it, 
and deletes it. Then finally the second print looks for 'var' in the 
instance, *doesn't* find it there (because it has been deleted), so it 
looks in the class, and finds GetSet.__dict__['var'] which is a property 
object.

At this point, things get a bit mysterious. According to the 
documentation, Python ought to print something like:



since the descriptor protocol doesn't run for old-style classes. But 
apparently it does *partly* run, because the property object's __get__ 
method is invoked, which calls the getter method that you defined.


> Output:
> 1000
> getting the var attribute
> 5


So there is a part mystery here. As far as I can tell, the documentation 
suggests that the output should be:

1000


rather than what you got.




-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor


Do This Before Bed Tonight to Burn Belly Flab All Night Long
Flat Belly Overnight
http://thirdpartyoffers.netzero.net/TGL3241/57db10cd7d30310cd7bb9st01duc
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] global interpreter lock

[khalil zakaria Zemmoura]

Basically, what that said is the global interpreter lock is something that
allows only one thread at a time to be executed when you launch a python
program in opposition of executing multiple threads at the same time
(parallelism). when you launch a python program it create a process in
memory. because of the GIL you cannot do parallelism in an efficient way,
but if you are not using threads, you shouldn't care about.
The GIL was relevant when we had one processor in our machine and honestly
it facilitate the development of the core maintainers of the CPython. Now
we have multicore processor, it start to be restrictive for some people,
not all but some of them who need to compute data and want to use all the
power they have.

Instead of giving you some examples I'll give you a link of some great
presentations made by David Beazly

Understanding the GIL:
https://m.youtube.com/watch?v=Obt-vMVdM8s

Embracing the GIL:
https://m.youtube.com/watch?v=fwzPF2JLoeU

Concurrency from the ground:
https://m.youtube.com/watch?v=MCs5OvhV9S4

This guy will explain to you better than I I'll do.

Hope that helps.
Regards.

Le 15 sept. 2016 09:18, "anish singh"  a
écrit :

> Can someone explain global interpreter lock with
> some source code examples?
>
> I didn't understand explanation offered here:
> https://docs.python.org/3/glossary.html#term-global-interpreter-lock
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] global interpreter lock

[Joaquin Alzola]

> Can someone explain global interpreter lock with some source code examples?

Watch this youtube video.

Gilectomy
https://www.youtube.com/watch?v=fgWUwQVoLHo

--
Joaquin

This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] @property for old style classes vs new style classes

[Steven D'Aprano]

On Thu, Sep 15, 2016 at 04:40:22AM +, monik...@netzero.net wrote:

> Could somebody please explain what is going on for old style classes for the 
> below code:

The important part is that the descriptor protocol doesn't get used for 
old style classes. If that statement means something to you, that's 
great, otherwise please ask. So in an old-style class:


> class GetSet():
> 
> def __init__(self, value):
> self.attrval = value
> 
> @property
> def var(self):
> print "getting the var attribute"
> return self.attrval
> @var.setter 
> def var(self,value):
> print "setting the var attribute"
> self.attrval = value

At this point, you have a class GetSet, with a class attribute:

GetSet.var

which is a property object. Now let's make an instance:

> me = GetSet(5)
> me.var = 1000

At this point, the instance now has an instance attribute:

me.var

which is the int 1000. So there are now TWO attributes called "me", 
living in different scopes:

me.__dict__['var'] = 1000  # in the instance

GetSet.__dict__['var'] = property object


Remember that attribute look-ups normally look in the instance __dict__ 
before the class __dict__.


> print me.var
> del me.var
> print me.var

The first print looks for 'var' in the instance, finds it, and prints 
1000. Then the del command looks for 'var' in the instance, finds it, 
and deletes it. Then finally the second print looks for 'var' in the 
instance, *doesn't* find it there (because it has been deleted), so it 
looks in the class, and finds GetSet.__dict__['var'] which is a property 
object.

At this point, things get a bit mysterious. According to the 
documentation, Python ought to print something like:



since the descriptor protocol doesn't run for old-style classes. But 
apparently it does *partly* run, because the property object's __get__ 
method is invoked, which calls the getter method that you defined.


> Output:
> 1000
> getting the var attribute
> 5


So there is a part mystery here. As far as I can tell, the documentation 
suggests that the output should be:

1000


rather than what you got.




-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] @property for old style classes vs new style classes

[Steven D'Aprano]

On Thu, Sep 15, 2016 at 02:08:12PM +, eryk sun wrote:

> Getting attributes also prefers the instance dict. However, to support
> bound methods (e.g. __init__), it falls back on a class lookup and
> calls the descriptor __get__ method if defined. 

Is that documented anywhere? When was it introduced?

Because I can see that in Python 2.4 and higher, function objects have a 
__get__, and old-style classes appear to call __get__ methods. But going 
back to Python 1.5 function objects DON'T have a __get__ and attribute 
lookup ignores __get__ even if designed.

>>> class MyDescriptor:
... def __get__(self):
... print "calling descriptor __get__"
... return lambda self: "the getter"
...
>>> class X:
... desc = MyDescriptor()
...
>>> X.desc
<__main__.MyDescriptor instance at 82d1940>


Some time between Python 1.5 and 2.4, the behaviour of old-style classes 
was changed to *half* support the descriptor protocol. As far as I can 
see, that's not mentioned in the Descriptor HowTo guide:

https://docs.python.org/2/howto/descriptor.html

and it contradicts the comment here:

https://docs.python.org/2/reference/datamodel.html#invoking-descriptors

Quote:

Note that descriptors are only invoked for new style objects or 
classes (ones that subclass object() or type()).




-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] @property for old style classes vs new style classes

[eryk sun]

On Thu, Sep 15, 2016 at 4:40 AM, monik...@netzero.net
 wrote:
> class GetSet():
>
> def __init__(self, value):
> self.attrval = value
>
> @property
> def var(self):
> print "getting the var attribute"
> return self.attrval
> @var.setter
> def var(self,value):
> print "setting the var attribute"
> self.attrval = value
>
> @var.deleter
> def var(self):
> print "deleting the var attribute"
> self.attrval = None
>
> me = GetSet(5)
> me.var = 1000

A classic instance has both a type (`instance`) and a __class__ (e.g.
GetSet). The type defines how getting, setting, and deleting
attributes works, and the hard-coded classic behavior for calling the
class __getattr__, __setattr__, and __delattr__ methods.

If the class doesn't define __setattr__ and __delattr__, the instance
type sets and deletes attributes directly in the instance dict. Unlike
new-style classes, a data descriptor defined by the class gets ignored
here.

Getting attributes also prefers the instance dict. However, to support
bound methods (e.g. __init__), it falls back on a class lookup and
calls the descriptor __get__ method if defined. Unintentionally, it
happens that this partially supports the property descriptor. But
since there's no data descriptor support, it's only useful for
read-only properties.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] automatic setting of class property when another one changes

[Steven D'Aprano]

On Thu, Sep 15, 2016 at 12:30:34PM +0200, ingo wrote:

> Rather stuck with this one, I'd like to automatically (re)set the 
> propery "relaystate" when one of the others (Tm, Tset, Th) is set, 
> regardless of wether their value has changed.

The obvious way is to make Tm, etc properties, and have their setter 
method reset the relaystate property. Since they relay state cannot be 
calculated during __init__ until all of the properties have been set, 
simply bypass the properties in the __init__. See below.


> My code so far:

Thanks for showing your code, but you shouldn't drown us in masses of 
irrelevant code that has nothing to do with your problem. We don't care 
about the logging code you show. Take it out. In fact, the best way to 
demo code is to cut it down to the barest minimum demonstrating the 
problem:


class Thermostat(object):
def __init__(self, Tm):
self._Tm = Tm
self.reset_relay()

@property
def Tm(self):
return self._Tm
@Tm.setter
def Tm(self, value):
self.reset_relay()
self._Tm = value

def reset_relay():
self.relaystate = None


About a dozen lines, versus seventy for your code.

See also this for more information:
http://sscce.org/


-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] automatic setting of class property when another one changes

[Peter Otten]

ingo wrote:

> Rather stuck with this one, I'd like to automatically (re)set the
> propery "relaystate" when one of the others (Tm, Tset, Th) is set,
> regardless of wether their value has changed.

The easiest way to achieve your goal seems to be a read-only property:

# this creates a class that should be shared by all RelayState instances;
# therefore it belongs on the module level
RelayState = namedtuple('RelayState', ['heat', 'cool'])

# the states are immutable and can safely be defined outside the method
HEAT = rlstate(1, 0)
COOL = rlstate(0, 1)
OFF = rlstate(0, 0)

class Thermostat():
...

@property
def relaystate(self):
logger.debug("GETTER relaystate")
lower = self.Tset - self.Th
upper = self.Tset + self.Th
if self.Tm < lower:
return HEAT
elif self.Tm > upper:
return COOL
else:
return OFF


If that doesn't work (because you want to operate an actual relay, say) you 
probably have to trigger a change in the TXXX setters:

class Thermostat():

def __init__(self, Tm=20, Tset=20, Th=0.3):
self._relaystate = None
self.Tm = Tm
self.Tset = Tset
self.Th = Th

def update_relaystate(self):
try:
state = self.calculate_relaystate()
except AttributeError:
pass
else:
self.relaystate = state

@property
def Tm(self):
logger.debug("GETTER Tm")
return self._Tm

@Tm.setter
def Tm(self, value):
logger.debug("SETTER Tm")
self._Tm = value
self.update_relaystate()

...

@property
def relaystate(self):
logger.debug("GETTER relaystate")
return self._relaystate

@relaystate.setter
def relaystate(self, value):
if value != self.relaystate:
logger.debug(
"SWITCHING relaystate from %s to %s", 
self.relaystate, value)
self._relaystate = value

def calculate_relaystate(self):
lower = self.Tset-self.Th
upper = self.Tset+self.Th
if self.Tm < lower:
return HEAT
elif self.Tm > upper:
return COOL
else:
return OFF



> 
> Ingo
> 
> My code so far:
> 
> from collections import namedtuple
> import logging
> 
> logger = logging.getLogger()
> logger.setLevel(logging.DEBUG)
> stream_handler = logging.StreamHandler()
> stream_handler.setLevel(logging.DEBUG)
> formatter = logging.Formatter(
>  '[%(levelname)-8s] %(asctime)s (%(name)-8s) - %(message)s',
>  '%Y-%m-%d %H:%M:%S',
> )
> stream_handler.setFormatter(formatter)
> logger.addHandler(stream_handler)
> 
> 
> class Thermostat():
>  def __init__(self, Tm=20, Tset=20, Th=0.3):
>  logger.debug("__INIT__")
>  self.Tm = Tm
>  self.Tset = Tset
>  self.Th = Th
>  self.relaystate = None
> 
>  @property
>  def Tm(self):
>  logger.debug("GETTER Tm")
>  return self._Tm
>  @Tm.setter
>  def Tm(self, value):
>  logger.debug("SETTER Tm")
>  self._Tm = value
> 
>  @property
>  def Tset(self):
>  logger.debug("GETTER Tset")
>  return self._Tset
>  @Tset.setter
>  def Tset(self, value):
>  logger.debug("SETTER Tset")
>  self._Tset = value
> 
>  @property
>  def Th(self):
>  logger.debug("GETTER Th")
>  return self._Th
>  @Th.setter
>  def Th(self, value):
>  logger.debug("SETTER Th")
>  self._Th = value
> 
>  @property
>  def relaystate(self):
>  logger.debug("GETTER relaystate")
>  return self._relaystate
>  @relaystate.setter
>  def relaystate(self, value):
>  logger.debug("SETTER relaystate")
>  #on init while setting Tm, Tset and Th are not known
>  #so relaystate can not be calculated
>  try:
>  lower = self.Tset-self.Th
>  upper = self.Tset+self.Th
>  except AttributeError as e:
>  logger.debug("SETTER relaystate : %s", e)
>  self._relaystate = None
>  rlstate = namedtuple('relaystate', ['heat', 'cool'])
>  if self.Tm < lower:
>  value = rlstate(1,0)
>  elif self.Tm > upper:
>  value = rlstate(0,1)
>  elif self.Tm > lower and self.Tm < upper:
>  value = rlstate(0,0)
>  self._relaystate = value
> 
> 
> if __name__ == "__main__":
> 
>  TS1 = Thermostat()
>  TS1.Tset = 44
>  print("heat : ",TS1.relaystate.heat,"cool : ",TS1.relaystate.cool)
> 
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:

[Tutor] automatic setting of class property when another one changes

[ingo]

Rather stuck with this one, I'd like to automatically (re)set the 
propery "relaystate" when one of the others (Tm, Tset, Th) is set, 
regardless of wether their value has changed.


Ingo

My code so far:

from collections import namedtuple
import logging

logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
stream_handler = logging.StreamHandler()
stream_handler.setLevel(logging.DEBUG)
formatter = logging.Formatter(
'[%(levelname)-8s] %(asctime)s (%(name)-8s) - %(message)s',
'%Y-%m-%d %H:%M:%S',
)
stream_handler.setFormatter(formatter)
logger.addHandler(stream_handler)


class Thermostat():
def __init__(self, Tm=20, Tset=20, Th=0.3):
logger.debug("__INIT__")
self.Tm = Tm
self.Tset = Tset
self.Th = Th
self.relaystate = None

@property
def Tm(self):
logger.debug("GETTER Tm")
return self._Tm
@Tm.setter
def Tm(self, value):
logger.debug("SETTER Tm")
self._Tm = value

@property
def Tset(self):
logger.debug("GETTER Tset")
return self._Tset
@Tset.setter
def Tset(self, value):
logger.debug("SETTER Tset")
self._Tset = value

@property
def Th(self):
logger.debug("GETTER Th")
return self._Th
@Th.setter
def Th(self, value):
logger.debug("SETTER Th")
self._Th = value

@property
def relaystate(self):
logger.debug("GETTER relaystate")
return self._relaystate
@relaystate.setter
def relaystate(self, value):
logger.debug("SETTER relaystate")
#on init while setting Tm, Tset and Th are not known
#so relaystate can not be calculated
try:
lower = self.Tset-self.Th
upper = self.Tset+self.Th
except AttributeError as e:
logger.debug("SETTER relaystate : %s", e)
self._relaystate = None
rlstate = namedtuple('relaystate', ['heat', 'cool'])
if self.Tm < lower:
value = rlstate(1,0)
elif self.Tm > upper:
value = rlstate(0,1)
elif self.Tm > lower and self.Tm < upper:
value = rlstate(0,0)
self._relaystate = value


if __name__ == "__main__":

TS1 = Thermostat()
TS1.Tset = 44
print("heat : ",TS1.relaystate.heat,"cool : ",TS1.relaystate.cool)

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] @property for old style classes vs new style classes

[monik...@netzero.net]

Hi:
Im studying @property, @var.setter and @var.deleter.
I understand how they work in new style classes. Even though I do not use old 
style classes it would be interesting to understand what is going on behind the 
scenes. I can try to make assumptions but I do not want to because they might 
be incorrect. 
Could somebody please explain what is going on for old style classes for the 
below code:
class GetSet():

def __init__(self, value):
self.attrval = value

@property
def var(self):
print "getting the var attribute"
return self.attrval
@var.setter 
def var(self,value):
print "setting the var attribute"
self.attrval = value

@var.deleter
def var(self):
print "deleting the var attribute"
self.attrval = None

me = GetSet(5)
me.var = 1000
print me.var
del me.var
print me.var

Output:
1000
getting the var attribute
5
>>>


Same code but with new style classes (this one I understand):
class GetSet(object):

def __init__(self, value):
self.attrval = value

@property
def var(self):
print ("getting the var attribute")
return self.attrval
@var.setter
def var(self,value):
print ("setting the var attribute")
self.attrval = value

@var.deleter
def var(self):
print ("deleting the var attribute")
self.attrval = None

me = GetSet(5)
me.var = 1000
print (me.var)
del me.var
print (me.var)

Output:
setting the var attribute
getting the var attribute
1000
deleting the var attribute
getting the var attribute
None

Thank you very much
Monika

Unlock Visions (Sponsored by Content.Ad)
1 Odd Method 'Restores' Your 20/20 Vision. Try This
http://thirdpartyoffers.netzero.net/TGL3241/57da2673b610726731820st03duc
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] global interpreter lock

[anish singh]

Can someone explain global interpreter lock with
some source code examples?

I didn't understand explanation offered here:
https://docs.python.org/3/glossary.html#term-global-interpreter-lock
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor