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,
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 discussion: in
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
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 the
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) should be
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 every
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 really that bad.
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 /
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.
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.
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,
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 example:
+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 include
13 matches
Mail list logo
