Alex Martelli wrote:
> On Feb 18, 2006, at 12:38 AM, Georg Brandl wrote:
>
>> Guido van Rossum wrote:
>>> WFM. Patch anyone?
>>
>> Done.
>> http://python.org/sf/1434038
>
> I reviewed the patch and added a comment on it, but since the point
> may be controversial I had better air it here for d
On Feb 18, 2006, at 12:38 AM, Georg Brandl wrote:
> Guido van Rossum wrote:
>> WFM. Patch anyone?
>
> Done.
> http://python.org/sf/1434038
I reviewed the patch and added a comment on it, but since the point
may be controversial I had better air it here for discussion: in 2.4,
property(fset=
Guido van Rossum wrote:
> WFM. Patch anyone?
Done.
http://python.org/sf/1434038
Georg
> On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>> Alex Martelli wrote:
>> > Maybe we could fix that by having property(getfunc) use
>> > getfunc.__doc__ as the __doc__ of the resulting property object
>>
WFM. Patch anyone?
On 2/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > Maybe we could fix that by having property(getfunc) use
> > getfunc.__doc__ as the __doc__ of the resulting property object
> > (easily overridable in more normal property usage by the doc=
> > argumen
Alex Martelli wrote:
> Maybe we could fix that by having property(getfunc) use
> getfunc.__doc__ as the __doc__ of the resulting property object
> (easily overridable in more normal property usage by the doc=
> argument, which, I feel, should almost invariably be there).
+1
--
Ian Bicking / [E
On 2/17/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Ian Bicking wrote:
>
> >> Unfortunately, a @property decorator is impossible...
> >
> > It already works! But only if you want a read-only property. Which is
> > actually about 50%+ of the properties I create. So the status quo is
> > not rea
Ian Bicking wrote:
>> Unfortunately, a @property decorator is impossible...
>
> It already works! But only if you want a read-only property. Which is
> actually about 50%+ of the properties I create. So the status quo is
> not really that bad.
I have abused it this way too and felt bad ever
>> it has been proposed before, but there was no conclusive answer last
>> time: is there any chance for 2.5 to include commonly used decorators
>> in a module?
Georg> No interest at all?
I would think the decorators that allow proper introspection (func_name,
__doc__, etc) shoul
Georg Brandl wrote:
> Hi,
>
> it has been proposed before, but there was no conclusive answer last time:
> is there any chance for 2.5 to include commonly used decorators in a module?
One peculiar aspect is that decorators are a programming technique, not
a particular kind of functionality. So
Georg Brandl wrote:
> Hi,
>
> it has been proposed before, but there was no conclusive answer last time:
> is there any chance for 2.5 to include commonly used decorators in a module?
No interest at all?
Georg
___
Python-Dev mailing list
Python-Dev@py
+1, and we could maybe include tail_call_optimized?
http://littlelanguages.com/2006/02/tail-call-optimization-as-python.html
On 2/11/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> it has been proposed before, but there was no conclusive answer last time:
> is there any chance for 2.5 to inc
Georg Brandl <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> Unfortunately, a @property decorator is impossible...
>
It all depends what you want (and whether you want the implementation to be
portable to other Python implementations). Here's one possible but not
exactly portable exampl
On Fri, Feb 10, 2006 at 10:32:23PM +0100, Georg Brandl wrote:
> Unfortunately, a @property decorator is impossible...
Depends. You can do, e.g.,
def propertydef(propertydesc):
data = propertydesc()
if not data:
raise ValueError, "Invalid property descriptors"
getter, setter,
Hi,
it has been proposed before, but there was no conclusive answer last time:
is there any chance for 2.5 to include commonly used decorators in a module?
Of course not everything that jumps around should go in, only pretty basic
stuff that can be widely used.
Candidates are:
- @decorator. Thi
Hi,
it has been proposed before, but there was no conclusive answer last time:
is there any chance for 2.5 to include commonly used decorators in a module?
Of course not everything that jumps around should go in, only pretty basic
stuff that can be widely used.
Candidates are:
- @decorator. Thi
15 matches
Mail list logo
