Greg Ewing wrote:
Nick Coghlan wrote:
PEP 342's yield expressions can probably be used to help address that
problem,
though:
class SomeAO(ActiveObject):
def processSomeMessage(self):
msg = yield
# Do something with the message
next_msg = yield
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.4.2 (final).
Python 2.4.2 is a bug-fix release. See the release notes at the
website (also available as Misc/NEWS in the source distribution) for
details of the more than 60 bugs
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |= set([1])
Do we want lst.__setitem__ to be called in the second
On Sep 28, 2005, at 9:12 AM, Reinhold Birkenfeld wrote:
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |=
Read descriptors (defining only __get__) and data descripttors have
(defining __get__ and __set__) different semantics. In particular,
read descriptors are overridden by instance data, while data
descriptors are not. A common use of read descriptors is for lazily
computed data:
class
At 03:12 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
Hi,
a general question. Consider:
class A(list):
def __setitem__(self, index, item):
# do something with index and item
return list.__setitem__(self, index, item)
lst = A([1,set()])
lst[0] |= 1
lst[1] |= set([1])
On 9/28/05, Jim Fulton [EMAIL PROTECTED] wrote:
Read descriptors (defining only __get__) and data descripttors have
(defining __get__ and __set__) different semantics. In particular,
read descriptors are overridden by instance data, while data
descriptors are not. A common use of read
At 10:16 AM 9/28/2005 -0400, Jim Fulton wrote:
I do this often enough that I think it would be useful to include it
in python, either as a builtin (like property) or in the library. (Or
possibly by adding an option to property to generate a read
descriptor.) I'd be happy to add this for 2.5.
Phillip J. Eby [EMAIL PROTECTED] writes:
Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice
if there were a descriptor hook __bind__(cls,name) that was called by
classes during cls.__new__ or assignment to a class attribute, and which
you could define to return a
Phillip J. Eby a écrit :
At 03:12 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
[...]
Yes. See:
http://www.python.org/2.0/new-python.html#SECTION00070
The purpose of the augmented assignment forms is to allow for the
possibility that the item's __i*__ method may or may
At 05:15 PM 9/28/2005 +0200, Reinhold Birkenfeld wrote:
Okay. I assume that we must accept that
s = set()
t = (s,)
t[0] |= set([1])
changes s in spite of raising TypeError.
There are lots of operations that can be partially completed before raising
an error, so I'm not sure why this case would
At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
Rather than closing this as invalid, it would be wiser to update the
documentation before ! Nothing corresponds to the current behavior.
I got my information from here:
Phillip J. Eby a écrit :
At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
Rather than closing this as invalid, it would be wiser to update the
documentation before ! Nothing corresponds to the current behavior.
I got my information from here:
At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
Regularly, you see questions about augmented assignment on Python-tutor
mailing list, I often have question in my lab because of problems ...
most of the time people learn to avoid these operators in the end ! And
my look in the
Michael Hudson mwh at python.net writes:
Phillip J. Eby pje at telecommunity.com writes:
Unfortunately, finding out a descriptor's name is non-trivial; it'd be nice
if there were a descriptor hook __bind__(cls,name) that was called by
classes during cls.__new__ or assignment to a
On Wed, Sep 28, 2005 at 10:16:12AM -0400, Jim Fulton wrote:
class readproperty(object):
[skip]
I do this often enough
I use it since about 2000 often enough under the name CachedAttribute:
http://cvs.sourceforge.net/viewcvs.py/ppa/qps/qUtils.py
(The current maintainer of the code is
Bruce Eckel wrote:
Since the enqueuing process serializes all requests to active objects,
and since each message-task runs to completion before the next one
starts, the problem of threads interfering with each other is
eliminated. Also, the enqueuing process will always happen, so even if
the
At 05:28 PM 9/28/2005 +, iga Seilnacht wrote:
You can use something like this to find a descriptor's name:
snip
The given code fails if the same property appears under more than one name
or is used in more than one class. It also requires the property object to
be mutable, and is
On Wed, 2005-09-28 at 10:16, Jim Fulton wrote:
When we ask for the eggs attribute the first time, we call the
descriptor, which calls the eggs function. The function sets the eggs
attribute, overriding the descriptor. The next time the eggs attribute
is accessed, the saved value will be used
It doesn't work that way for new-style classes.
On 9/28/05, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2005-09-28 at 10:16, Jim Fulton wrote:
When we ask for the eggs attribute the first time, we call the
descriptor, which calls the eggs function. The function sets the eggs
attribute,
At 06:23 PM 9/28/2005 -0400, Barry Warsaw wrote:
I /must/ be missing something. Why not just use property as a
decorator?
class C:
@property
def eggs(self):
print 'in eggs'
self.eggs = 7
return self.eggs
c = C()
c.eggs
in eggs
7
c.eggs
7
Because it
On Wed, 2005-09-28 at 19:14, Phillip J. Eby wrote:
Because it only works in classic classes due to a bug in descriptor handling:
Blah. ;)
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
22 matches
Mail list logo
