PEP 343 has been updated on python.org.
Highlights of the changes:
- changed the name of the PEP to be simply The 'with' Statement
- added __with__() method
- added section on standard terminology (that is, contexts/context managers)
- changed generator context decorator name to
On and off, I've been looking for an elegant way to handle properties using
decorators.
It hasn't really worked, because decorators are inherently single function,
and properties span multiple functions.
However, it occurred to me that Python already contains a construct for
grouping multiple
class Demo(object):
@def_property
class test:
This is a test property
def get(self):
print Getting attribute on instance
def set(self, value):
print Setting attribute on instance
def delete(self):
On Oct 16, 2005, at 9:56 AM, Nick Coghlan wrote:
On and off, I've been looking for an elegant way to handle
properties using
decorators.
This isn't my idea, and it might have been brought up here in the
past to the same sorts of screams of horror to which you refer later,
but I use the
On 10/16/05, Nick Coghlan [EMAIL PROTECTED] wrote:
PEP 343 has been updated on python.org.
Highlights of the changes:
- changed the name of the PEP to be simply The 'with' Statement
- added __with__() method
- added section on standard terminology (that is, contexts/context
On 10/16/05, Nick Coghlan [EMAIL PROTECTED] wrote:
On and off, I've been looking for an elegant way to handle properties using
decorators.
It hasn't really worked, because decorators are inherently single function,
and properties span multiple functions.
However, it occurred to me that
PEP 343 has been updated on python.org.
Highlights of the changes:
- changed the name of the PEP to be simply The 'with' Statement
Do you mean PEP 346, perchance? PEP 343 is something else entirely.
___
Python-Dev mailing list
On 10/16/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/16/05, Nick Coghlan [EMAIL PROTECTED] wrote:
On and off, I've been looking for an elegant way to handle properties using
decorators.
It hasn't really worked, because decorators are inherently single function,
and properties
On 10/14/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/11/05, Eyal Lotem [EMAIL PROTECTED] wrote:
locals()['x'] = 1 # Quietly fails!
Replaced by:
frame.x = 1 # Raises error
What about the possibility of making this
On 10/16/05, Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/16/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Nick, and everybody else trying to find a solution for this
problem, please don't. There's nothing wrong with having the three
accessor methods explicitly in the namespace, it's
Tony Nelson wrote:
Umm, 0 (NUL) is a valid output character in most of the 8-bit character
sets. It could be handled by having a separate exceptions string of the
unicode code points that actually map to the exception char.
Yes. But only U+ should normally map to 0. It could be
Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/14/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/11/05, Eyal Lotem [EMAIL PROTECTED] wrote:
locals()['x'] = 1 # Quietly fails!
Replaced by:
frame.x = 1 # Raises error
On 10/16/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/14/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Calvin Spealman [EMAIL PROTECTED] wrote:
On 10/11/05, Eyal Lotem [EMAIL PROTECTED] wrote:
locals()['x'] = 1 # Quietly
On 10/15/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote:
Martin Blais wrote:
On 10/3/05, Michael Hudson [EMAIL PROTECTED] wrote:
Martin Blais [EMAIL PROTECTED] writes:
How hard would that be to implement?
import sys
reload(sys)
sys.setdefaultencoding('undefined')
Hmmm any
Guido van Rossum wrote:
Nick, and everybody else trying to find a solution for this
problem, please don't.
Denying that there's a problem isn't going to make it
go away. Many people, including me, have the feeling that
the standard way of defining properties at the moment leaves
something to
Greg Ewing wrote:
class C:
foo = overridable_property('foo', The foo property)
def get_foo(self):
...
def set_foo(self, x):
...
This has the advantage that the accessor methods can be
overridden in subclasses with the expected effect.
This is a
[Guido]
Nick, and everybody else trying to find a solution for this
problem, please don't.
[Greg Ewing]
Denying that there's a problem isn't going to make it
go away. Many people, including me, have the feeling that
the standard way of defining properties at the moment leaves
something to
We all know Guido likes Python. But the real question is do pythons like Guido?
http://python.org/neal/
n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Nick Coghlan wrote:
Having module attribute access obey the descriptor protocol (__get__, __set__,
__delete__) sounds like a pretty good option to me.
It would even be pretty backwards compatible, as I'd be hardpressed to think
why anyone would have a descriptor *instance* as a top-level
Guido van Rossum wrote:
To which Tim Delaney responded, have a look at my response here:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713
I looked at that, and now I believe it's actually *better* to mention
the property name twice, at least compared to Tim' s approach.
I
On 10/10/05, Neal Norwitz [EMAIL PROTECTED] wrote:
There's a problem with genexp's that I think really needs to get
fixed. See http://python.org/sf/1167751 the details are below. This
code:
foo(a = i for i in range(10))
I agree with the bug report that the code should either raise a
21 matches
Mail list logo
