Re: [Python-Dev] inplace operators and __setitem__

Ok, so I took a closer look at the documentation and tried a few things to understand better what you said and I have some remark ... Phillip J. Eby a ecrit : > At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote: > >> Regularly, you see questions about augmented assignment on Python-tut

[Python-Dev] release24-maint is UNFROZEN. 2.4.3 around March or so.

So no brown-paper-bag bugs have been reported that I've seen, so let's unfreeze the release24-maint branch. Note that there will be at least a 2.4.3, probably around Feb-March next year (around the time of 2.5a1, as currently vaguely planned). I might also cut a final 2.4.4 after 2.5 final is o

Re: [Python-Dev] RFC: readproperty

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 Python-D

Re: [Python-Dev] RFC: readproperty

At 01:34 PM 9/29/2005 +1200, Greg Ewing wrote: >Guido van Rossum wrote: > > I think we need to be real careful with chosing a name > >In Eiffel, the keyword "once" is used for something >analogous -- a method that is called once the first >time it's referenced, and the return value cached. > >So pe

Re: [Python-Dev] RFC: readproperty

Guido van Rossum wrote: > I think we need to be real careful with chosing a name In Eiffel, the keyword "once" is used for something analogous -- a method that is called once the first time it's referenced, and the return value cached. So perhaps this could be called a "once_property". -- Greg

Re: [Python-Dev] RFC: readproperty

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 > >>>

Re: [Python-Dev] RFC: readproperty

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 > > a

Re: [Python-Dev] RFC: readproperty

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 u

Re: [Python-Dev] RFC: readproperty

Oleg Broytmann wrote: >It seems many people reinvent this particular wheel. Which is > understandable. > >propertytools.py, anyone? "import magic" ;) Cheers, Nick. P.S. Such a module may actually be a good idea, if it reduces the variation in metaclass and descriptor hacks across some

Re: [Python-Dev] RFC: readproperty

At 05:28 PM 9/28/2005 +, Žiga Seilnacht wrote: >You can use something like this to find a descriptor's name: > 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 subject

Re: [Python-Dev] Active Objects in Python

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 >

Re: [Python-Dev] RFC: readproperty

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

Re: [Python-Dev] RFC: readproperty

Michael Hudson python.net> writes: > > "Phillip J. Eby" 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 cla

Re: [Python-Dev] inplace operators and __setitem__

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 stan

Re: [Python-Dev] inplace operators and __setitem__

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: > > http://www.python.

Re: [Python-Dev] RFC: readproperty

Jim Fulton wrote: > A common use of read descriptors is for lazily computed data: > >class readproperty(object): >"Create a read descriptor from a function" > >def __init__(self, func): >self.func = func > >def __get__(self, inst, class_): >if ins

Re: [Python-Dev] inplace operators and __setitem__

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: http://www.python.org/2.0/new-python.html#SECTION0007000

Re: [Python-Dev] inplace operators and __setitem__

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

Re: [Python-Dev] inplace operators and __setitem__

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 o

Re: [Python-Dev] inplace operators and __setitem__

Phillip J. Eby wrote: >>A case where this matters is here: http://python.org/sf/1306777 > > I've closed it as invalid; the behavior is as-defined. > > In principle, there *could* be an optimization to avoid rebinding the > lvalue in the case where the __i*__ form did return self. But using it

Re: [Python-Dev] RFC: readproperty

"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 ret

Re: [Python-Dev] RFC: readproperty

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. >

Re: [Python-Dev] RFC: readproperty

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 de

Re: [Python-Dev] inplace operators and __setitem__

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]

[Python-Dev] RFC: readproperty

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 readprope

Re: [Python-Dev] inplace operators and __setitem__

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 > >

Re: [Python-Dev] PEP 350: Codetags

On Monday 26 September 2005 05:35 pm, Micah Elliott wrote: > Please read/comment/vote. This circulated as a pre-PEP proposal > submitted to c.l.py on August 10, but has changed quite a bit since > then. I'm reposting this since it is now "Open (under consideration)" > at

[Python-Dev] inplace operators and __setitem__

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 inplac

[Python-Dev] RELEASED Python 2.4.2 (final)

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 squi

Re: [Python-Dev] PEP 350: Codetags

Terry Hancock wrote: > On Monday 26 September 2005 05:35 pm, Micah Elliott wrote: > >>Please read/comment/vote. This circulated as a pre-PEP proposal >>submitted to c.l.py on August 10, but has changed quite a bit since >>then. I'm reposting this since it is now "Open (under consideration)" >>at

Re: [Python-Dev] Active Objects in Python

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 = yie