[Python-Dev] Declaring setters with getters
I've come up with a relatively unobtrusive pattern for defining
setters. Given the following definition:
def propset(prop):
assert isinstance(prop, property)
def helper(func):
return property(prop.__get__, func, func, prop.__doc__)
return helper
we can declare getters and setters as follows:
class C(object):
_encoding = None
@property
def encoding(self):
return self._encoding
@propset(encoding)
def encoding(self, value=None):
if value is not None:
unicode("0", value) # Test it
self._encoding = value
c = C()
print(c.encoding)
c.encoding = "ascii"
print(c.encoding)
try:
c.encoding = "invalid" # Fails
except:
pass
print(c.encoding)
I'd like to make this a standard built-in, in the hope the debate on
how to declare settable properties.
I'd also like to change property so that the doc string defaults to
the doc string of the getter.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
Guido> I've come up with a relatively unobtrusive pattern for defining
Guido> setters. Given the following definition:
...
I'm a pretty naive user of properties, so can you explain to me how what you
propose is better than
class C(object):
def __init__(self):
self._encoding = None
def get_encoding(self):
return self._encoding
def set_encoding(self, value):
if value is not None:
unicode("0", value) # Test it
self._encoding = value
encoding = property(get_encoding, set_encoding)
?
Guido> I'd also like to change property so that the doc string defaults
Guido> to the doc string of the getter.
How about defaulting it to the first argument to property() which has a doc
string?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
At 10:08 AM 10/31/2007 -0700, Guido van Rossum wrote: >I've come up with a relatively unobtrusive pattern for defining >setters. Given the following definition: > >def propset(prop): > assert isinstance(prop, property) > def helper(func): > return property(prop.__get__, func, func, prop.__doc__) > return helper Shouldn't that be property(prop.fget, func, prop.fdel, prop.__doc__), and have a matching propdel decorator? Apart from those extremely small nits, a big +1, and I expect to swipe this idea more or less immediately. :) >I'd also like to change property so that the doc string defaults to >the doc string of the getter. +1 also; I thought it did this already, but am now disappointed to find it doesn't. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
> I'd like to make this [propset] a standard built-in, +1 -- I find this to be an attractive syntax > I'd also like to change property so that the doc > string defaults to the doc string of the getter. +1 -- This should also be done for classmethod, staticmethod, and anything else that wraps functions. Alternatively, the doc string could be made a little more informative: __doc__ = 'property of function %s: %s' % (f.__name__, f.__doc__) Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (10/24/07 - 10/31/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1320 open (+25) / 11530 closed (+20) / 12850 total (+45) Open issues with patches: 418 Average duration of open issues: 681 days. Median duration of open issues: 773 days. Open Issues Breakdown open 1316 (+25) pending 4 ( +0) Issues Created Or Reopened (45) ___ py3k: file.truncate() changes the file position 10/24/07 CLOSED http://bugs.python.org/issue1323created amaury.forgeotdarc patch r58034 breaks building _ctypes with the upstream libffi. 10/25/07 CLOSED http://bugs.python.org/issue1324created doko patch zipimport.zipimporter.archive undocumented and untested 10/25/07 http://bugs.python.org/issue1325created exarkun "internal" zipimport.zipimporter feature untested10/25/07 http://bugs.python.org/issue1326created exarkun Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmcl 10/25/07 http://bugs.python.org/issue1327created eanxgeek feature request: force BOM option10/25/07 http://bugs.python.org/issue1328created jgsack Different 3.0a1 exit behavior10/25/07 CLOSED http://bugs.python.org/issue1329created MrJean1 Fix truncate on Windows, this time for real 10/26/07 CLOSED http://bugs.python.org/issue1330created tiran py3k, patch More fixes for Windows 10/26/07 CLOSED http://bugs.python.org/issue1331created tiran py3k, patch threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi10/26/07 http://bugs.python.org/issue1332created delwarl merge urllib and urlparse functionality 10/26/07 http://bugs.python.org/issue1333created techtonik IDLE - Fix several highlighting bugs 10/26/07 http://bugs.python.org/issue1334created taleinat patch bytesiterator patch 10/26/07 CLOSED http://bugs.python.org/issue1335created tiran subprocess.Popen hangs when child writes to stderr 10/26/07 http://bugs.python.org/issue1336created jba Tools/msi/msi.py does not work with PCBuild8 10/26/07 http://bugs.python.org/issue1337created kevinwatters pickling bytes? 10/26/07 http://bugs.python.org/issue1338created gvanrossum py3k smtplib starttls() should ehlo() if it needs to 10/26/07 http://bugs.python.org/issue1339created fenner correction for test_tempfile in py3k on Windows 10/28/07 CLOSED http://bugs.python.org/issue1340reopened gvanrossum correction for test_fileinput in py3k on Windows 10/26/07 CLOSED http://bugs.python.org/issue1341created amaury.forgeotdarc patch Crash on Windows if Python runs from a directory with umlauts10/27/07
Re: [Python-Dev] Declaring setters with getters
> and have a matching propdel decorator? -1. That would be a complete waste of builtin space. Put stuff in when it is really needed. Ideas are not required to automatically propagate from the commonly used cases to the rarely used cases. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > I'd like to make this [propset] a standard built-in, > > +1 -- I find this to be an attractive syntax > > > I'd also like to change property so that the doc > > string defaults to the doc string of the getter. > > +1 -- This should also be done for classmethod, > staticmethod, and anything else that wraps functions. With this level of support, it could be implemented by this afternoon! (and backported to 2.4 within a week. ;-) > Alternatively, the doc string could be made a little > more informative: > > __doc__ = 'property of function %s: %s' % (f.__name__, f.__doc__) Hm, not clear that helps. It's not a property of the function. We should just teach users to write docstrings that read well for this use case. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
Guido van Rossum schrieb: > I'd like to make this a standard built-in, in the hope the debate on > how to declare settable properties. +1. I'm waiting for the obligatory cry for @propdel though :) > I'd also like to change property so that the doc string defaults to > the doc string of the getter. I may be misunderstanding, but isn't that what patch #1434038 already implemented in 2.5? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> I've come up with a relatively unobtrusive pattern for defining
> Guido> setters. Given the following definition:
>
> ...
>
> I'm a pretty naive user of properties, so can you explain to me how what you
> propose is better than
>
> class C(object):
> def __init__(self):
> self._encoding = None
>
> def get_encoding(self):
> return self._encoding
>
> def set_encoding(self, value):
> if value is not None:
> unicode("0", value) # Test it
> self._encoding = value
> encoding = property(get_encoding, set_encoding)
>
> ?
Mostly so it's easy to add a setter to a property that originally had
only a getter. For read-only properties, using
@property
def name(self):
return
is preferred over
def get_name(self):
return
name = property(get_name)
> Guido> I'd also like to change property so that the doc string defaults
> Guido> to the doc string of the getter.
>
> How about defaulting it to the first argument to property() which has a doc
> string?
I considered that briefly, but decided against it -- it could lead to
odd results if the getter has no docstring and the setter's docstring
is about setting only.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > > I'd like to make this a standard built-in, in the hope the debate on > > how to declare settable properties. > > +1. I'm waiting for the obligatory cry for @propdel though :) propdel: just say no. > > I'd also like to change property so that the doc string defaults to > > the doc string of the getter. > > I may be misunderstanding, but isn't that what patch #1434038 already > implemented in 2.5? D'oh, you're right. I tested this with 2.4 (which is the default Python at Google). +1 on this proposal then. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:08 AM 10/31/2007 -0700, Guido van Rossum wrote: > >I've come up with a relatively unobtrusive pattern for defining > >setters. Given the following definition: > > > >def propset(prop): > > assert isinstance(prop, property) > > def helper(func): > > return property(prop.__get__, func, func, prop.__doc__) > > return helper > > Shouldn't that be property(prop.fget, func, prop.fdel, prop.__doc__), Of course. (Though my code works too. :-) > and have a matching propdel decorator? Yes, though I think that if prop.fdel is None, we could use func in both slots. > Apart from those extremely small nits, a big +1, and I expect to > swipe this idea more or less immediately. :) Be my guest. I should patent this; it's apparently non-obvious. :-) (I can't recall why I didn't think of this sooner, and why nobody else did.) > >I'd also like to change property so that the doc string defaults to > >the doc string of the getter. > > +1 also; I thought it did this already, but am now disappointed to > find it doesn't. :) Patch for 2.6 anyone? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
At 11:09 AM 10/31/2007 -0700, Guido van Rossum wrote: >Yes, though I think that if prop.fdel is None, we could use func in >both slots. Eh? Isn't prop.fdel supposed to be a single-argument function? ISTM that C is the only place where fset and fdel are the same thing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Special file "nul" in Windows and os.stat
On Oct 30, 2007 4:10 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > >> My question now is what specific kernel32 functions Python 2.4 > >> calls to determine that NUL is a file; before that question > >> is sufficiently answered, I don't think any action should be > >> taken. > >> > > > > os.path.exist() in win32 just calls os.stat() and decides it doesn't > > exist if an error is returned. os.stat() uses the vcrt stat()in 2.4, > > but 2.5 implements it directly in terms of win32 api to deal with > > limitations in the vcrt implementation. > > That doesn't really answer the question, though - you merely state > that Python 2.4 calls the CRT, but then my question is still what > kernel32 functions are called to have stat on NUL succeed. > I'm not 100% (it calls it through a function pointer and I'm not sure I tracked it down correctly), but I think it calls it through the C stat() function. In other words, it doesn't use any kernel32 functions directly, it calls the stat() that's exported from the MSVCRT. > > Interestingly, plain old GetFileAttributes() works, and returns > > FILE_ATTRIBUTE_ARCHIVE for them. > > What about the other attributes (like modification time, size, etc)? > GetFileAttributes() doesn't return those, just the FAT filesystem attributes. GetFileSize and GetFileTime fail. > Regards, > Martin > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
Guido van Rossum wrote: > I'd like to make this a standard built-in, in the hope the debate on > how to declare settable properties. +0.75 It's still not as good as the C# way to create a property but it's so simple and obvious that it's ingenious again. Every other implementation would either require support from the parser or some metaclass magic. Your KISS approach rocks! :) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ctypes and libffi
The ctypes sources contain the source code for libffi, in Modules/_ctypes/libffi. These sources were pulled from GCC cvs some time ago, and a new configure system was written by Perky iirc. Now, it seems that these sources are showing their age and a newer libffi version should be used instead. There are issues on certain platforms like mips64, arm, armeabi; also on other systems to correctly use the c_longdouble data type that I added recently. See also http://bugs.python.org/issue1292. Pythons configure command has a --with-system-ffi option that, if specified, uses a system installed libffi package (if present). By default, the bundled sources are used. The cleanest way to fix this problem probably would be to remove the outdated libffi sources from Python svn (in trunk and py3k), and require a system installed libffi for building ctypes. However, I have no idea if there are libffi packages available for systems like solaris, BSD, or OS X (to name a few that come to mind). Another way would be to leave the sources in place, and only use them when no system libffi installation is present - in other words to change the default of the --with-system-ffi option. Matthias Klose has already committed a change to configure.in that sets --with-system-ffi="yes" for Linux/arm* systems. This would be a third way: do this for all systems that require newer libffi. Any thoughts? Thanks, Thomas PS: As a test, I changed setup.py (in branches/ctypes-branch) so that always a system installed libffi is used, and manually triggered the build on the bots that failed or even crashed before: ppc Debian unstable, and S-390 Debian. PPS: The above does not apply for Windows; the windows libffi suorces work fine and are in different subdirectories. Also, configure is not used on Windows. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:09 AM 10/31/2007 -0700, Guido van Rossum wrote: > >Yes, though I think that if prop.fdel is None, we could use func in > >both slots. > > Eh? Isn't prop.fdel supposed to be a single-argument function? ISTM > that C is the only place where fset and fdel are the same thing. Given how rarely supporting deletions matters enough to write extra code, we can just say that *when using @propset* your setter function needs to have a default value for the argument or otherwise support being called with one or two arguments. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
Guido van Rossum wrote:
> @property
> def encoding(self):
> return self._encoding
>
> @propset(encoding)
> def encoding(self, value=None):
> if value is not None:
> unicode("0", value) # Test it
> self._encoding = value
That's reasonably nice, although I'm not sure about the
name "propset" -- it sounds like a repair kit for an
aircraft. Maybe something like "setproperty" would be
better.
But there's something that bothers me about the whole
propery mechanism -- there's no straightforward way for
a property accessor to call the inherited version from
a base class.
Wrapping property accessors up in decorators makes this
worse. At least when the accessors are declared as separate
functions you have a chance of grabbing an inherited one
and calling it. But if they're buried inside property
descriptors with no other reference to them, it's a lot
harder to get hold of one.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > @property
> > def encoding(self):
> > return self._encoding
> >
> > @propset(encoding)
> > def encoding(self, value=None):
> > if value is not None:
> > unicode("0", value) # Test it
> > self._encoding = value
>
> That's reasonably nice, although I'm not sure about the
> name "propset" -- it sounds like a repair kit for an
> aircraft. Maybe something like "setproperty" would be
> better.
I'm open for a naming contest.
> But there's something that bothers me about the whole
> propery mechanism -- there's no straightforward way for
> a property accessor to call the inherited version from
> a base class.
Isn't there? You can just use super() ISTR, though I haven't had the
need myself and don't recall the exact syntax.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
Guido van Rossum wrote: > Isn't there? You can just use super() ISTR, That may work, now that I come to think about it. However, super() is not a complete solution, because it doesn't let you choose which inherited method to call in a multiple inheritance situation. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
At 12:06 PM 11/1/2007 +1300, Greg Ewing wrote: >Guido van Rossum wrote: > > Isn't there? You can just use super() ISTR, > >That may work, now that I come to think about it. > >However, super() is not a complete solution, because >it doesn't let you choose which inherited method >to call in a multiple inheritance situation. Er, TheRightBase.propname.fget(self)? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Isn't there? You can just use super() ISTR, > > That may work, now that I come to think about it. > > However, super() is not a complete solution, because > it doesn't let you choose which inherited method > to call in a multiple inheritance situation. Yes, that's the point of super(). if you want more control, you can just get the property object out of the class you want -- super() doesn't have supernatural powers, all it does is pick the class for you. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
> I'm not sure about the name "propset" ... >Maybe something like "setproperty" would be better. I think not. Saying "setproperty" has too many ambiguous mental parsings. When does "set" take place -- assigning a value to a property is different defining the property itself. Is "set" a verb so that we're talking about a property of sets/frozensets. Is "set" a completed action so that the property has been set. Let's stick with "propset" which has precedent as an svn action and serves as a short, simple mnemonic to the functionality. Also, I find that these unique words are easier to search for. I once co-owned a magazine called Know Your Boston and it was very difficult for clients to find using Google. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On Thu, Nov 01, 2007, Greg Ewing wrote: > > But there's something that bothers me about the whole propery > mechanism -- there's no straightforward way for a property accessor to > call the inherited version from a base class. > > Wrapping property accessors up in decorators makes this worse. At > least when the accessors are declared as separate functions you have > a chance of grabbing an inherited one and calling it. But if they're > buried inside property descriptors with no other reference to them, > it's a lot harder to get hold of one. That's why the property delegates to a normal method. (Kudos to Martelli for the idea.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On Oct 31, 2007, at 4:28 PM, Guido van Rossum wrote: > Given how rarely supporting deletions matters enough to write extra > code, we can just say that *when using @propset* your setter function > needs to have a default value for the argument or otherwise support > being called with one or two arguments. It's definitely unusual, but the logic is typically very different; conflating the method in Python doesn't really feel "right" to me. I've been using Philipp von Weitershausen's "rwproperty" quite happily: http://pypi.python.org/pypi/rwproperty/ It uses the names "getproperty", "setproperty", and "delproperty", which feel reasonable when I use them (always referenced using the module), like so: class Thing(object): @rwproperty.setproperty def attribute(self, value): # ... If I had to choose built-in names, though, I'd prefer "property", "propset", "propdel". Another possibility that seems reasonable (perhaps a bit better) would be: class Thing(object): @property def attribute(self): return 42 @property.set def attribute(self, value): self._ignored = value @property.delete def attribute(self): pass -Fred -- Fred Drake ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 31, 2007, at 2:14 PM, Guido van Rossum wrote: > On 10/31/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> I'd like to make this [propset] a standard built-in, >> >> +1 -- I find this to be an attractive syntax >> >>> I'd also like to change property so that the doc >>> string defaults to the doc string of the getter. >> >> +1 -- This should also be done for classmethod, >> staticmethod, and anything else that wraps functions. > > With this level of support, it could be implemented by this afternoon! > (and backported to 2.4 within a week. ;-) I know you're joking about the backporting. Neal, no sneaking this into 2.5.2 now! :) BTW, +1 on this. I like Fred's suggestion of property.set(). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRyk4kHEjvBPtnXfVAQJ5SQP/Z4uofrSz0L5hgHvaC5MmGlFqxO2O/i8q pZUurzbcRENCXhKSat5+qymyfOWyeO9rCgUbHq81af5tyUIDt9uo+6JxtBwVniEN Fcc3qMmjNhBi9if1Rn1S8jTG0AC3KEHuL4qZmghAY7Lz4/8jOjtQmAWubJ+LmQlE hxN+sdYqkm8= =gA2F -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote: > If I had to choose built-in names, though, I'd prefer "property", > "propset", "propdel". Another possibility that seems reasonable > (perhaps a bit better) would be: > >class Thing(object): > >@property >def attribute(self): >return 42 > >@property.set >def attribute(self, value): >self._ignored = value > >@property.delete >def attribute(self): >pass +1 on this spelling if possible. Though based on Guido's original recipe it might have to be written as:: @property.set(attribute) def attribute(self, value): self._ignored = value STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |> I'm not sure about the name "propset" ... | >Maybe something like "setproperty" would be better. | | I think not. Saying "setproperty" has too many ambiguous mental parsings. When does "set" take place -- assigning a value to a property is different defining the property itself. Is "set" a verb so that we're talking about a property of sets/frozensets. Is "set" a completed action so that the property has been set. | | Let's stick with "propset" which has precedent as an svn action and serves as a short, simple mnemonic to the functionality. | | Also, I find that these unique words are easier to search for. I once co-owned a magazine called Know Your Boston and it was very difficult for clients to find using Google. 'propset' would have the virtue of following 'property' in the alpha listing of functions in the manual. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Declaring setters with getters
As long as we're all tossing out ideas here, my 2¢. I vastly prefer this: On 02:43 am, [EMAIL PROTECTED] wrote: On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote: @property.set def attribute(self, value): self._ignored = value to this: @property.set(attribute) def attribute(self, value): self._ignored = value since I don't see any additional expressive value in the latter, and it provides an opportunity to make a mistake. The decorator syntax's main value, to me, is eliminating the redundancy in: def foo(): ... foo = bar(foo) eliminating the possibility of misspelling "foo" one of those three times. and removing a lot of finger typing. The original proposal here re-introduces half of this redundancy. I think I can see why Guido did it that way - it makes the implementation a bit more obvious - but decorators are already sufficiently "magic" that I wouldn't mind a bit more to provide more convenience, in what is apparently just a convenience mechanism. And, since everyone else is sharing their personal current way of idiomatically declaring dynamic properties, here's mine; abusing the "class" statement instead of decorators: from epsilon.descriptor import attribute class Stuff(object): class foo(attribute): "you can put a docstring in the obvious place" def set(self, value): print 'set foo!' self._foo = value + 4 def get(self): return self._foo + 3 s = Stuff() s.foo = 0 print 's.foo:', s.foo I'd be glad of a standard, accepted way to do this though, since it's really just a spelling issue and it would be nice to reduce the learning curve between all the different libraries which define dynamic attributes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
